Start with the number that should worry you
In a 2025 randomised controlled trial, METR followed sixteen experienced open-source developers across 246 real tasks, in codebases they knew well. With AI assistance, they were 19% slower. They had expected to be about 24% faster. After finishing the work, they still believed AI had made them roughly 20% faster.
The figure to sit with is not the productivity number. It is the perception number. People who write software for a living, working in their own repositories, misjudged the effect of AI on their own output by nearly forty points, and did so with confidence. A 2026 follow-up landed in the same territory, around eighteen percent slower.
The caveat matters, because honesty is the whole point of the argument: this was experienced engineers in mature codebases, and results for greenfield work or junior developers look different. But the finding a CTO cannot unsee is not that AI is slow. It is that the people closest to the work were badly wrong about their own speed. If the practitioners are that miscalibrated, the dashboards rolling their activity up into a board slide are unlikely to be any more accurate.
Your AI adoption metrics may be smiling while delivery quietly slows.
AI is not increasing productivity. It is increasing supply.
Coding agents now generate code, tests, documentation, refactors, and increasingly whole features. The natural conclusion is that engineers become more productive, and at the level of the individual keystroke that is true. It is also the least interesting thing happening.
The change that matters sits one level up. The potential supply of software production is rising far faster than most organisations can absorb it.
An organisation does not create value simply because more code can be generated. Every change still has to be understood, reviewed, tested, secured, integrated, deployed, observed, governed, and checked against what the business actually asked for, before it becomes anything a customer would notice or a board would count. Generating that change faster moves none of those steps on its own.
So we are really talking about two different capacities, and they are easy to confuse. There is AI production capacity, meaning how much change the machines can now generate. And there is organisational absorption capacity, meaning how much validated change the organisation can safely turn into value. The distance between the two is what I call the Absorption Gap, and it is the binding constraint of the agentic era. Most AI strategies are quietly widening it, buying more supply while leaving absorption exactly where it was.
Figure 1. The Absorption Gap. AI production capacity is outpacing the organisation's ability to safely absorb it.
The squeeze is now measurable
The premise no longer needs defending. It can be sourced.
On the supply side the shift is plain. Sonar's 2026 developer survey found engineers attributing roughly 42% of committed code to AI-assisted work, with GitHub Copilot averaging close to half of the code written across its user base. Whatever the exact figure at any one company, the direction is not in question.
Absorption has not moved with it. DORA's 2025 research, across around five thousand professionals, reached a conclusion that sounds mild and is not: higher AI adoption is associated with more delivery throughput and more delivery instability at the same time. New Relic's 2026 data puts numbers on the instability. 78% of teams report more production incidents once AI-generated code ships, and 62% of leaders admit their teams push that code without line-by-line review. Faros AI, looking at some twenty-two thousand developers, found the probability of a production incident per change more than tripling year on year.
The pattern underneath the statistics is consistent. More enters the top of the system, and proportionally less reaches the bottom safely. Speed of creation is turning into cost of correction. This is not a tooling problem. It is what happens when the intake of a system grows while its ability to absorb does not.
What this looks like on the ground
Numbers describe the shape of the problem. Watching a rollout shows you its texture.
In the rollouts I have been close to, the striking thing is how uneven the experience is. One engineer will point an agent at a large refactor spanning several codebases and land in an afternoon what used to take a fortnight. Another will burn through tokens on work nobody can quite reconstruct afterwards. And when you step back and look for the aggregate signal, the throughput and business value impact is far harder to find than the enthusiasm around the tooling would lead you to expect.
I have seen this shape before. Years ago, streamlining a delivery pipeline, we cut build and release times from weeks to minutes. It felt like an unambiguous win, right up until it became clear we had simply made it possible to ship the wrong thing faster, because the product inputs feeding the pipeline and the context around it had not improved at the same rate. Speed magnified whatever was already flowing through, good or bad.
Ungoverned AI is that same mistake at a larger scale and a much higher unit cost. A great deal of what currently gets called AI transformation is organisations spending heavily, sometimes into the millions, to produce more of what they were already producing, only faster and with less oversight. The token bill is easy to see. The value is not.
Bottlenecks do not disappear. They migrate.
Most of the 2026 commentary has settled on one answer: review and verification are the new bottleneck. That is correct, and it is also where the argument usually stops, which is the mistake.
Treating verification as the bottleneck to fix misreads the mechanism. Relieving a constraint does not remove it from the system. It relocates it to the next least scalable step. Take the pressure off coding and it reappears at verification. Scale verification and it moves to integration, then to environments, then to observability, then to operations, then to governance, and finally to the one resource that does not scale at all, human judgment.
This is why I frame the work as designing an Engineering Production System rather than fixing a single stage, and why the model reads best as a map of where the constraint sits and how it travels, not as a tidy pipeline.
Figure 2. The Engineering Production System. Relieve coding and the constraint reappears at the next least-scalable stage, then keeps moving.
The value of a map is that it tells you where to look next, not only where it hurts now. Pour more coding capacity into a system whose real constraint is integration, or observability, or judgment, and you have not added value. You have added inventory that piles up in front of the true bottleneck.
It also explains a line I keep coming back to. When code becomes cheap, architecture becomes expensive. Cheap generation raises the price of every unresolved architectural ambiguity, because agents now run into that ambiguity constantly, at volume, at all hours. AI does not remove the need for architecture. It raises the cost of not having it.
This is why the metrics mislead
Adoption and value have come apart. McKinsey's 2025 State of AI found 88% of organisations using AI in at least one function, and only around 5.5% reporting real financial returns. Adoption tells you supply went up. It says nothing about whether absorbed, validated value went up.
Lines of code, pull requests merged, commits, acceptance rate, the percentage of developers using AI: every one of these counts activity at the point of supply, which is precisely where AI inflates the numbers. They are the wrong instruments for this moment, because they climb at exactly the same time as the Absorption Gap widens. That is what I mean when I say the metrics are lying to the board. Not fraud, just instruments pointed at the wrong end of the system.
One question survives the shift. How much validated business value can my engineering system produce per unit of human intervention? Validated change over human intervention. It pulls attention away from activity and towards the economics of the system, away from how much the machines can produce and towards how much the organisation can safely convert into value. It is close to the only measure that improves when the system genuinely improves, and refuses to move when all you have done is buy more supply.
The mandate: absorption is an operating-model problem
The most useful sentence a CTO can borrow this year is DORA's own. AI is an amplifier. It does not fix a team, it exposes it. A well-designed system amplifies into throughput. A fragile one amplifies into fragility, only faster and at greater cost.
What follows from that is not a purchasing decision. It is a design one. Raising absorption capacity to match supply is a question of operating model, architecture, and governance, and none of it comes in a licence.
Verification has to become a continuous, strategic capability rather than a stage bolted on near the end, increasingly automated and increasingly autonomous. The quality organisation stops being a manual gate and becomes something closer to a verification and supervision system. AI will not eliminate testing. It will eliminate the economics of traditional testing.
Context has to be treated as production infrastructure. An agent produces only as well as the architecture, boundaries, data, and policy it works inside. The quality of the context an organisation can give its agents becomes part of that organisation's production capacity, which draws a straight line from enterprise and data architecture to how much the system can safely take on.
Roles and flows have to be redesigned around where the constraints have actually moved. Most engineering organisations were built when human production was the scarce resource, and they still carry the ceremonies, handoffs, approvals, and queues that existed to ration it. Some of that overhead should now disappear. Other controls matter far more than they used to, because the volume of change has risen. Telling those two apart is the real work.
None of this arrives in a tool. It has to be designed.
A 30-day test, and the question underneath it
The argument is testable, which is the point of making it. Take one engineering team. Before changing anything, measure human intervention, generated change, validated change, cycle time, verification effort, deployment frequency, and defects or incidents. Introduce agents into selected parts of that team's workflow. Then ask two questions.
Did the amount of validated business change the system can absorb actually rise, or did the team simply generate more? And, more revealing than the first, where did the bottleneck move?
Even if the exercise achieves nothing else, it replaces a conversation about how fast your engineers feel with evidence about what your system can absorb.
That is the shift that matters. The question is no longer how productive your engineers can become. It is how much validated business value your whole engineering system can turn out per unit of human intervention, and, when you look closely, where the bottleneck has quietly gone next.