A software team adopts an AI coding assistant and its output doubles. Pull requests pile up. Commits per developer climb. The engineering dashboard turns a satisfying shade of green. Six months later, the same number of features have reached customers as the year before. The work got faster. The product did not.
This is not a story about overhyped AI. The assistant did exactly what it promised. It is a story about where speed enters a system and where speed leaves it, and why those are rarely the same place. AI is about to make a great many slow organizations faster at the one thing that was never their problem.
The story everyone tells
Everybody talks about engineers being the bottleneck. Of course they are. They are visible, expensive, and perpetually behind. So when a technology arrives that lets each engineer produce two or three times as much code, the obvious (but wrong) conclusion is that triple output also reaches the customers.
The conclusion is wrong, and it is wrong in a way that has been measurable for decades. Engineering output is almost never the constraint on how fast validated capability reaches a customer. It is one stage in a much longer chain, and accelerating one stage in a chain does nothing for the chain unless that stage was the slowest one. In most organizations it was not.
This is not a tooling problem, but a flow problem. And flow problems do not respond to faster tools. They respond to a different way of seeing the system.
What actually moves through the system
Start with a precise question: what is the product of a product development organization? The intuitive answer is artifacts. Code, drawings, requirements, test reports. But artifacts are not where value is created. Value is created when uncertainty about what will work gets reduced, and that learning is converted into a decision that can be executed. Product development is a machine that produces validated decisions. The artifacts are just the medium that stores and transmits them.
Product development is a machine that produces validated decisions.
This reframing changes what counts as progress. A line of code that has not been integrated and shown to work has not reduced any uncertainty. It is not a delivered decision. It is inventory.
In a factory, inventory is visible. You can walk the floor and see half-built cars stacked between stations. The industry calls this work in progress, WIP, and a century of operations research has taught manufacturers to fear it. Product development has the same thing, but you cannot see it. Unresolved decisions, half-understood designs, code written but not yet proven to work in the integrated system: this is design in progress, DIP. It is real work sitting in the system, and because it has no physical form, its accumulation is easy to miss until it surfaces as a late integration failure, a wave of rework, or a missed commitment.
Here is the trap. An AI assistant is, above all else, a machine for producing DIP at high speed.
The mechanism: filling queues faster
A value stream is made of three things: stages, where specialized work happens, queues, where work waits, and handoffs, where work and responsibility transfer between stages. Most of the calendar time between a good idea and a shipped capability is not spent in the stages. It is spent in the queues. Work sits, waiting for the next stage to have capacity.
Donald Reinertsen, whose Principles of Product Development Flow is the closest thing the field has to a foundational text, put it bluntly: few developers realize that queues are the single most important cause of poor product development performance. Work waiting between stages, invisible because it has no physical form, quietly setting the pace of everything.
Queues grow for three structural reasons, and it is worth naming them because AI touches all three. Variability, because work arrives and completes unevenly, so things wait even in a system that is not full. High utilization, because as any stage approaches full capacity, small disruptions create disproportionate delay. And large batches, because work that arrives in surges leaves the next stage swinging between idle and overloaded.
AI automation backfires
Now drop an AI assistant into the first stage of this stream. Engineering output rises sharply. What happens to the queue between engineering and whatever comes next in the Velocity Loop, integration, verification, review, certification, deployment? It grows. Faster. The assistant has not removed a constraint. It has fed one. More work now arrives at the slow stage, in bigger batches, and waits longer to be pulled.
The book makes this concrete with a small example that predicts the entire AI problem. An ML team can train models faster than the integration team can evaluate them. Without a limit, models accumulate in a queue between the two. The faster team feels productive. The slower team drowns. End-to-end delivery does not move, because the integration stage, the actual constraint, has exactly the same capacity it had before. The only thing that changed is the size of the pile waiting in front of it. AI is that faster ML team, applied to your entire engineering function at once.
Little’s Law does not negotiate
If this still feels like it should net out positive, there is an equation that settles it. Little’s Law states that average cycle time equals average DIP divided by average throughput. Read it slowly, because it is one of the few iron laws in this field.
Throughput is the rate at which finished, validated items leave the stream. That rate is set by the constraint, not by how fast the first stage can produce. If AI accelerates engineering but the constraint downstream is untouched, throughput does not rise. What rises is DIP, the inventory in the system. And if DIP rises while throughput holds constant, cycle time gets longer. The math is not subtle. Adding work to a system without increasing its throughput makes every item take longer to get through, not shorter.
So the organization that doubles its code output and leaves its integration, review, and deployment capacity unchanged does not ship faster. It ships at the same rate, with far more half-finished work clogging the pipes, and each individual feature now takes longer to emerge than it did before the tool arrived. Faster input, longer lead times. That is not a paradox. It is arithmetic.
The anti-pattern: Local Efficiency Over Throughput
This failure has a name, because organizations have been walking into it for years without AI’s help. Call it Local Efficiency Over Throughput.
The pattern is seductive because every local signal looks good. Engineers are more utilized. Output per person is up. The team’s own cycle time, measured from their first commit to their handoff, may even improve. Every metric inside the engineering box turns green. And none of it touches the rate at which customers receive working product, because the engineering box was never the stage that set that rate.
The Theory of Constraints, which underpins this whole discipline, states the principle without mercy: the slowest stage sets the pace of the entire stream, and improving any stage other than the constraint does not improve system performance. A team can cut its own cycle time in half and have precisely zero effect on end-to-end delivery, as long as the real bottleneck sits untouched downstream. The same logic explains why Germany’s housing shortage is really a flow problem: pour in capital, and if the constraint is the permitting queue, nothing moves. AI is a machine for halving the cycle time of whatever stage you point it at. Point it at a non-constraint, which is where most of the easy wins appear to be, and you have spent real money to make a number go up that does not matter.
Point AI at a non-constraint, and you have spent real money to make a number go up that does not matter.
There is a related pattern worth watching for, called watermelon reporting and coined by Marc Löffler. Green on the outside, red on the inside. Projects report healthy status because activity is high and milestones are being checked off, while end-to-end flow is blocked. AI is an excellent watermelon engine. It produces a torrent of activity, every bit of it legible on a dashboard, none of it necessarily moving validated capability toward a customer any faster. The organization feels accelerated. The customer experiences no difference.
Why the misread is about to get worse
Two things make the AI version of this trap sharper than the manual one.
First, the imbalance is larger. A manual productivity improvement might lift engineering output by ten or twenty percent. An effective AI assistant can lift the raw production of code or design artifacts by a multiple. The bigger the gap between how fast the first stage runs and how fast the constraint can absorb its output, the more violently the queue grows.
Second, the new work is disproportionately the expensive kind. The Flow Framework, developed by Mik Kersten in Project to Product, divides everything a team produces into four categories: features, defects, risks, and debt:
- Features are new value the customer pulled.
- Defects are value leakage, effort spent fixing what should have worked.
- Risk is security and compliance work.
- Debt is the invisible drag that accumulates and eventually halts feature delivery entirely.
Kersten’s warning is that a team can spend eighty percent of its capacity on defects and debt and still look productive in its tooling, because the tools count artifacts, not value.
Understanding the economics
Code generated quickly, without the understanding that used to come from writing it slowly, is a reliable source of defects and debt. It must still be reviewed, integrated, secured, and maintained, and much of it arrives carrying latent problems that surface only downstream. So AI does not merely enlarge the queue at the constraint. It enriches that queue with exactly the work, defects to chase and debt to service, that consumes capacity without delivering new customer value. The flow distribution tilts toward the expensive categories at the very moment the volume spikes.
The deeper point is economic. Product development is the management of economic exposure under uncertainty. Capital sits exposed for as long as it takes to learn whether the thing will work, and the goal is to reduce that uncertainty quickly and meaningfully so that exposure stays low. Velocity, properly understood, is the rate at which relevant uncertainty falls. Producing twice as much unvalidated code does not reduce any uncertainty. The code might be wrong. It has not yet survived integration or contact with a real user. Until it does, it is exposure, not progress. Generating it faster generates exposure faster. That is the opposite of velocity, wearing velocity’s clothes.
A diagnostic you can run on Monday
There is one question that cuts through every green dashboard an AI rollout will produce. Borrow it and ask it of your own organization before the next tool contract is signed:
If your engineering stage doubled its output tomorrow, would finished, validated capability reach customers any sooner?
If the honest answer is no, then engineering output is not your constraint, and accelerating it will not accelerate your product. It will inflate your design in progress, lengthen your cycle times, and tilt your flow toward defects and debt, while every local metric assures you things are improving.
The fix is not to refuse the tool. The fix is to find the actual constraint first. Map the value stream from the customer backward, not from engineering forward. Quantify where work waits, not just where work happens. The stage with the longest queue in front of it is the one that sets your pace, and it is almost never the one that looks busiest. Then apply AI there, or apply it to widen that stage’s capacity, before you point it at the part of the system that was already fast enough.
Why this should worry every engineering leader
The seductive thing about AI is that it makes the wrong investment feel like the right one. Faster output is real. The acceleration is genuine. It simply happens at a stage that does not govern when your customer receives value, and the resulting flood of work in progress actively degrades the metric you actually care about while every proxy metric celebrates.
A slow organization that adopts AI without touching its constraint does not become a fast organization. It becomes a slow organization that produces unfinished work at high speed: more inventory between the stages, longer waits at the bottleneck, more defects and debt to absorb, and a dashboard glowing green over a value stream that delivers at exactly the rate it did before. The work accelerated. The product did not. And the gap between those two facts is now hidden behind a wall of activity that looks, for all the world, like progress.
The question was never how fast your engineers can produce. It was always how fast your system can turn uncertainty into capability a customer can use. AI answers the first question loudly. It is silent on the second. Make sure you know which one you are buying.
English
German