The quarter looked like a triumph from the inside. Every engineer on the team would have told you the same thing: the work was faster, the boilerplate wrote itself, the first draft of almost anything arrived in seconds. Then someone laid the delivery dashboard next to the previous quarter’s, and the line had barely moved. Roughly the same number of features shipped. Roughly the same lead time. The team felt twice as fast and delivered at almost exactly the rate it always had. Nobody was lying, and nobody was slacking. They had run head-first into the productivity paradox.
The paradox, stated plainly
The AI productivity paradox is the gap between how fast individual developers feel — and frequently are — when writing code with AI, and how little faster the organisation actually ships. Both halves are true at once. The local speed-up is genuine; it simply happens at a step that was never the bottleneck, so it does not move the end-to-end number that the business actually feels.
The evidence has been accumulating for two years and points the same way from several directions. A randomised controlled trial by METR — not a vendor — found experienced developers working on code they knew well were measurably slower with early-2025 AI tools, even though they believed they had been sped up: a felt speed-up of around 20% sitting on top of an actual slowdown. Large-scale delivery telemetry tells the organisational half of the story: Faros AI, across thousands of developers, saw pull requests produced far faster while time-to-first-review climbed steeply and a growing share of changes merged with no review at all. And DORA’s 2025 research reframed the debate entirely — AI is an amplifier, lifting throughput while continuing to erode delivery stability unless strong delivery practices are already in place. Speed went up. Delivery did not follow.
Read the headline numbers with care. The strongest individual figures come from vendor telemetry, the controlled studies are small, and follow-up analyses have argued the early slowdown was milder than first reported. The precise magnitude is genuinely contested. The direction — felt speed exceeding delivered speed — is not.
Why the speed is real and the delivery is not
Both halves reconcile the moment you remember that writing code was never the constraint. Generation is the abundant step now; acceptance is the scarce one. When you make an abundant step faster, you do not speed up a system that was bottlenecked elsewhere — you pile inventory in front of the bottleneck. The time saved in authoring reappears, almost pound for pound, downstream: in review, in rework, and in the integration seams where AI-written code tends to break. The work is conserved. It just moves to people who were already the constraint.
| Phase | What AI does to it | Where the time reappears |
|---|---|---|
| Authoring | Collapses — first draft in seconds | — |
| Review | Expands — more code, less context on why | Senior reviewers, the scarcest people |
| Rework | Grows — plausible-but-wrong code passes a glance | The original author, a sprint later |
| Integration | Concentrates at the seams between systems | Whoever owns the boundary |
The perception gap is a management hazard
The most dangerous part of the paradox is not the flat delivery line; it is the confident feeling of speed sitting on top of it. When everyone believes they are faster, the natural response is to commit to more, sooner — and to read any shortfall as a people problem rather than a system one. The perception gap quietly turns a measurement error into a planning error, and the planning error into pressure on exactly the reviewers who were already the bottleneck.
The first month with agents looks like a miracle, and the mood agrees with it. The second quarter is where you find out whether you built an acceptance gate — or just a faster way to generate work for your best people to clean up.
How to measure your way out
The paradox dissolves the moment you stop measuring the abundant step and start measuring the scarce one. Counting AI-generated lines — or “percent faster” — measures typing, which was never the point and is now actively misleading. Measure delivery instead:
- Lead time for change and deployment frequency — does work actually reach production sooner?
- Change-failure rate and time to restore — is the faster code stable, or is speed being borrowed against future incidents?
- Rework rate — the share of the pipeline spent fixing work previously called done; the earliest warning light for unchecked AI.
- Review latency and unreviewed-merge rate — whether the saved authoring time has simply become a review queue.
These are the DORA flow-and-stability metrics plus rework, and together they answer the only question that matters: is agentic engineering making the system faster, or just the keyboard? We go deeper on the instrumentation in our piece on measuring AI engineering — the short version is that acceptance and rework, not output, are the numbers that tell you the truth.
What good looks like
The teams that escape the paradox are not the ones with the best models; DORA’s amplifier finding says the model is rarely the differentiator. They are the ones whose delivery system can absorb a sudden surplus of code without buckling — strong automated testing, fast feedback, mature version control, an explicit acceptance gate, and reviewers resourced as the genuine bottleneck rather than treated as a rubber stamp. Get that right and the individual speed-up finally shows up where it counts: at the end of the pipeline, not the start of it.
Frequently asked
- What is the AI productivity paradox?
- The gap between how much faster individual developers feel (and often are) when writing code with AI, and how little faster their organisation actually delivers. The local speed-up is real, but it occurs at the authoring step — which was not the constraint — so end-to-end throughput stays roughly flat.
- Does AI actually make developers slower?
- Sometimes, on familiar code. A controlled METR trial found experienced developers were slower with early-2025 tools on tasks they knew well, even while feeling faster. On unfamiliar or boilerplate-heavy work the speed-up is real. The honest summary: effects vary widely, the headline magnitudes are contested, and the perceived speed-up is consistently larger than the measured one.
- Why does faster coding not mean faster delivery?
- Because writing code was rarely the bottleneck. Making an abundant step faster piles work in front of the real constraint — review, rework and integration — so the time saved in authoring reappears downstream, often landing on the most senior people on the team.
- How should we measure AI’s impact on engineering?
- Measure delivery, not output. Track the DORA flow and stability metrics (lead time, deployment frequency, change-failure rate, time to restore) plus rework rate and review latency. Stop counting AI-generated lines of code — it measures typing, not value.