AI freed capacity, delivery stayed flat. The demand-side leak is invisible to cycle time and DORA metrics — here's what to measure to catch it.
An analytics leader in a 6,000-person organisation described something to me recently that I hadn't measured, hadn't looked for, and couldn't have found with the instruments I was using.
His teams got faster. Delivery accelerated. And because delivery accelerated, the organisation started asking for more — more documentation, more of everything that scales with the volume of what ships. Productivity went up. Net output stayed where it was.
Nothing leaked in his pipeline. It leaked on the way in.
I'd spent months measuring the other thing — value dying in review queues, in rework, in coordination — and had come to think of the AI delivery problem as fundamentally a flow problem. He'd found a version where flow is fine and the number is flat anyway.
These look identical from the executive dashboard and require opposite responses.
The pipeline leak is work that entered the system as value and lost most of it in transit. Our own field study measured a 14% gain in implementation time, of which only about 6% survived to delivery — review and rework grew enough to consume more than half. The work is in the system. It's queued, or being redone, or waiting on a reviewer. Fix: unclog the constrained step.
The demand leak is different in kind. Freed capacity never enters the pipeline as value at all, because it enters as new scope. There's no queue to find, nothing waiting, no step to unclog. The system is running clean at a higher rate and producing the same delivered outcome, because the extra rate went to work that didn't exist last quarter.
If you diagnose the second as the first, you'll optimise a review process that isn't the problem, watch the org-level number stay flat, and conclude that AI underdelivered.
I have one more instance, and it comes at the problem from the opposite direction.
An engineering director at a large IT services firm told me his developers' throughput had roughly quadrupled — and that the consequence was his backlog burning down faster than product owners and business analysts could replenish it. He'd tried pointing AI at those roles, without much success.
He's describing the same phenomenon at an earlier stage. Capacity outran the supply of well-formed work. In his case the demand side hadn't yet absorbed it, so the shortfall was visible as an empty backlog rather than as flat output. Give it a couple of quarters and the organisation will find things to fill it with. Then it looks like the first case.
Two data points is not a finding. I'm publishing this as a hypothesis, not a result, and I'd like counter-examples as much as confirmations.
Cycle time. Lead time. DORA metrics. Review latency. Deploy frequency. Every one of them measures something about work already inside the pipeline.
Scope entering the system isn't in any of them. Which means the demand leak is invisible to the entire standard toolkit, and it's invisible in a particularly unhelpful way: all your flow metrics improve, and the outcome metric doesn't move, and nothing in the data explains the gap.
There are two instruments I've come across that would catch it, both from the same practitioner and neither of them common.
Scope injection — work added to a sprint after commitment. Tracked as a first-class metric rather than noticed anecdotally, it's the direct measurement of demand absorbing capacity. Almost nobody tracks it. It's the single metric I'd steal from anyone's dashboard right now.
Committed versus completed — which optimises for predictability rather than throughput. That's a subtler choice than it looks. Throughput tells you how fast you're going; committed-versus-completed tells you whether the organisation can plan around you, which is the thing leadership actually needs. And it degrades in a legible way when demand starts eating capacity.
Both on rolling multi-sprint averages, incidentally. A single sprint is noise.
I want to be honest that this piece is much stronger on diagnosis than on cure.
Measure what enters, not just what flows. Scope injection, committed versus completed, and some sense of how much of this quarter's work didn't exist at the start of it. If capacity is being absorbed, this is where it shows.
Separate the two leaks before treating either. The diagnostic question is whether your flow metrics improved. If cycle time and review duration got better while delivered outcomes stayed flat, it's demand, not pipeline. If flow metrics got worse or stayed put, it's pipeline.
Decide what freed capacity is for, explicitly. This is the actual intervention, and it isn't a metric. Capacity released by AI gets spent on something. Absent a decision, it gets spent on whatever generates the most local pressure — usually documentation, process, and requests that were previously declined for lack of room. That may well be the right use. But it should be a choice someone made, not a thing that happened while everyone was looking at the velocity chart.
Expect the constraint to keep moving. This is the general lesson from every conversation I've had on this topic. Making one step cheaper doesn't remove the bottleneck, it relocates it to whatever is now slowest — and it keeps relocating. Demand absorption is one of the places it goes. It won't be the last.
An organisation can become genuinely, measurably faster at every step of building software, deliver exactly as much as it did before, and see the whole thing recorded as AI didn't work for us.
Every dashboard will support that conclusion. All of them will be wrong, and none of them will be lying.
