AI and the illusion of velocity: fixing the value stream first

AI coding has been at the forefront lately, but everyone keeps missing the elephant in the room: there is a much bigger lever to pull for productivity, that no one seems to want to pull.

Proclamations of “coding is a solved problem” has been coming in fast and heavy in the last year, attributed to the rise of AI tools like Claude Code. I hate to break it to you, coding has been a solved problem for most of the last 20 years, it was never the thing that slowed down software projects in the first place, at least not during the active career of most people now working in the industry.

The real issue facing software development productivity in 2026 are the same issues that plagued it in 2006:

• Middlemen

• Handovers

• The Accountability-authority gap

• Lack of clear goals and expected outcomes

• Development without useful feedback loops

Why are fixing these a bigger win, than AI coding? Because coding is just one part of the delivery chain. Coding faster is of no use, is you are building the wrong thing. And if you are building based on second-hand information, handed down through middle men (business analysts, proxy product owners) as tickets, without clear goals or outcomes, you are almost guaranteed to build the wrong thing.

If you spend months or years in a vacuum building, without code ever hitting real use, you won’t get the feedback to know you are building the wrong thing. If you constantly keep handing over to someone else to do some other part of the work, valuable context is lost, misunderstood and misaligned, causing rework and defects.

Finally, if a team does not have full autonomy and authority over how they work, what tools to use, and how to use them, they are set up to fail, by working with one hand behind their backs, while getting all the blame if things go wrong.

Now, let’s address these in more detail:

Middlemen: Chinese whispers for no good reason

Many organizations, in particular large ones, have a tendency to introduce roles like business analyst, or a product owner who isn’t actually an intended user of the system. It’s usually based on two motivations of dubious efficacy: firstly, the users are too busy to be bothered, therefore a proxy product owner or product manager needs to be introduced.

In a B2C environment, perhaps a heavily data-driven product manager is actually needed, but note the “data-driven” part, without this, you just have someone getting paid for guessing. In a corporate environment it’s usually a product owner, representing the interests of internal users. This too would be fine, if the product owner actually belonged to the internal user group. I’ve seen this work tremendously well where applied. The problem though is, frequently, the product owner does not belong to the intended group of internal use, therefore has no real understanding of the needs of the users or business above anyone else. In this case, you’d be better served by allowing developers speak directly to end users (heresy!).

The second role that is common is that of a business analyst. They are usually subordinates, or loosely related to the role of product owner or manager. And the justification for their jobs seems to entirely hinge on the second motivation, which is complete and utter farm-animals droppings: the notion that because developers are technical, they are somehow not equipped to speak to actual business people. If this is the motivation, that you need a middleman to convey messages from group A to group B, because you cannot have A and B talking directly to each other, I’m sorry, you are burning money on having employees that are making you less effective. This role is an utter and total waste of space and air.

So my question here would be: why do so many organizations insist on a setup whereby the purposely disallow people from talking directly to each other, and instead inject a middleman in-between to convey messages that get slightly corrupted every time they are passed? Does this not seem immensely wasteful?

Now, to be clear, I’ve worked with many excellent product owners, product managers, and business owners. However, what they all had in common was, they did not act or view their roles as a firewall and middleman between users and developers. If anything, they sought to bring the two groups together whenever possible.

It is the enforced middleman mentality in organizations that needs to be taken out back and shot. Your value stream will thank you later.

Handovers: the tax that kills time-to-market

We have already talked about one type of handover, the one driven by requirements middlemen, taking requirements from business users, interpreting them in their own way, losing some quality or precision along the way, before being handed to developers.

However, the value-stream of software engineering is littered with other types of handovers. Pull Request-driven development is the most cargo-culted approach in industry, but there are many others. And before I get screamed at by PR proponents with “do you not believe in peer review?!”, I’ll make it clear: yes I do. But peer review can take other forms than interrupting or waiting for someone else to take the time to review changes for which they lack the context or awareness. Out of all means of peer-reviewing I am aware of, Pull Requests are probably the most ineffective approach to it. But I digress.

There are other types of handovers that are much worse than PR’s. One common kind is when an organization grows, starts struggling with how to distribute work, and defaults to splitting work, and roles into functional specializations: backend-developers handover API’s to front-end developers. Developers in general handover code to a “DevOps” or “Platform” team (quotes on purpose) to deploy. Developers handing over responsibility for quality to testers. The examples are numerous.

The more insidious, corrosive part of functional silos of specialization is that it undermines ownership of outcomes. Because you are just a small cog, responsible for a tiny slice, the tendency is to care little for what happens after you are done with the work. Is this really what we want to promote?

But what is the alternative to specialized roles and functional silos? Surely, no one can be an expert at everything? My answer to that is: no, they can’t. But two things can be true: More people than we think can be T-shaped, maybe have depth in one area, but awareness and skills in many others. Sometimes it’s just a matter of letting people do it, to learn it. And frequently, allowing people to become T-shaped, also increases job satisfaction, because they can own a larger chunk of the outcome, rather than be a ticket-churning cog in the machine. Secondly, if you put together a few T-shaped people with depth and strengths in slightly different areas, you’d be surprised how they can naturally self-organize to solve the problems they are faced with. But the key here is: people need to work as a team. Not as a set of functional silos or individuals.

The Accountability-authority gap

Another common form of value-stream dysfunction is the accountability-authority gap: This is when a team is accountable, held responsible for an outcome, but they are starved of the autonomy, tools, and resources to actually deliver: they are not allowed to decide how they work, what tools they use to work, or how to deliver the work. It is the classic “setup to fail” trap: get all the blame, but have no power over ability to actually deliver.

The most typical example is again where teams are separated by functional competence, rather than aligned with the value they are creating: you have a “DevOps team”, an architecture board, a testing team etc. In practice, this means a development team has to justify decisions to people who are far divorced from the problem being solved, they have to fit their way of working inside tightly constrained, perhaps inappropriate rails for deployment, and delayed feedback from testers. There are of course other types of dysfunctions in this category, not least just “corporate standards”: libraries, patterns, languages to be used etc.

“Total freedom would be chaos!” I can hear someone object, and they’d be right. But the trick is not to try to standardize top-down, up-front for every possible situation. The solution is to align accountability and authority and shift it as far down as possible. And where standardization is desirable, provide teams with paved roads, not a locked cage. If you are not prepared to hand a team the means to achieve their outcome, don’t pretend they own it.

Lack of clear goals and expected outcomes

It’s possible this issue is the single biggest one across all of software delivery. If you have clear enough goals and expected outcomes, software engineers barely need tickets or requirements, they know what they are solving for, and will be able to do so almost autonomously (given a closed accountability-authority gap). However, absent clear goals and outcomes, the best-case scenario is a well-defined ticket factory, where engineers churn through tickets, without recognizing the contradictory nature between tickets the way usually only software engineers can. The worst, and most probable case is an environment where goals and outcomes are vague, and tickets are likewise. If goals and outcomes are not well-defined, chances are the people producing “requirements” will also be guessing wildly.

A clear goal is also the thing that lets a team say “no” with confidence. Without it, every request that comes in looks equally legitimate, because, how would you know otherwise? If you give people a real outcome, they will know when requests come in, whether it moves the needle closer to their goal or not.

A possible objection here is “but goals move, markets change, we can’t commit to an outcome!”. This is getting it exactly wrong: a fixed spec breaks the moment it comes in contact with reality or a moving goal. A clear outcome lets a team reconsider and reroute with confidence when circumstances change. An outcome can survive twelve months, a spec rarely does.

A test for whether the goals and outcome are clear is asking team members “what are we trying to achieve this quarter, and how will you know if we did?”. If you get five different answers, you’re in trouble. If you get similar answers every time, the outcome is clear.

Development without useful feedback loops

Mistakes in software have a price, but they are also unavoidable. The price of a mistake decided by how long it takes to discover. Catch a bad assumption in a review, or even in production shortly after it was made, and it is trivial to correct it. Wait nine months to find out by doing a big bang release, you might have stacked nine months worth of derivative bad assumptions on top of the first one.

Healthy software development runs on multiple feedback loops at different timeframes. Seconds: does it compile and pass tests. Minutes: does it pass CI and integrate with other developers changes. Hours or days: do stakeholders think it fits into the product? Does it work in production? Days or weeks: are real users actually using it, and are they using it as intended?

Skip or delay these loops at your own peril. Every single step compounds errors if they are delayed. And the key word in users is real. Testers or other team adjacent stakeholders testing a feature out, but not being part of the intended group is a poor substitute for rubber hitting the road.

It is all the same disease

The eagle-eyed might have already noticed: every single dysfunction mentioned above is the same underlying disease. Middlemen are a dysfunctional feedback loop with bolted on signal loss. Handovers lengthen the loop and drop context at every step. Missing goals means you can’t tell useful feedback apart from noise. The authority gap means when feedback arrives, the team isn’t allowed or equipped to handle it.

Slow, ignored or degraded feedback is the rot that underpins every dysfunction.

This is why faster coding won’t save you. Faster coding will only let you build the wrong thing faster, piling on bad assumption upon bad assumption on top of each other before anyone has time to notice. Coding was never a bottleneck, feedback and clarity of purpose were.

AI makes typing faster, but it does not reduce handovers, make your goals clearer, your team more autonomous, signal loss from Chinese whispers loose less signal, or your loops any faster.

Fix the system, typing was never the problem.