AI Made Coding Fast. Delivery Didn't Get Faster.
AI made writing code far faster, but cycle time barely moved. Amdahl's Law, DORA data and my own numbers on why, and where to aim AI to speed up delivery.
A team I worked with cut the time to author a pull request from about two days to about two hours.
Real improvement, honestly measured, not a vendor case study. Everyone could feel it. Engineers were happier. The demo to leadership was excellent.
Their cycle time, commit to production, did not move. At all. And their review queue roughly tripled.
When we sat down to work out why, the answer was embarrassing in how obvious it was. They had made one stage of the pipeline five times faster. That stage was about a fifth of the elapsed time. Everything downstream ran at exactly the speed it always had, and now had five times as much arriving at it.
They hadn't built a faster pipeline. They'd built a faster machine feeding a queue.
I think this is the single most common mistake in enterprise AI adoption right now, and it isn't a mistake about AI. It's a mistake about systems, and manufacturing solved it forty years ago.
Coding was never the constraint
Here's the uncomfortable question I now ask every team that tells me AI transformed their productivity: what fraction of your calendar time between "we decided to build this" and "a customer can use it" was spent with fingers on keys writing the implementation?
Nobody has the number. But everyone's estimate, once they actually walk it through, comes in far lower than they expected. Requirements and clarification. Design and decision-making. Coding. Code review. Testing and QA. Security and compliance review. Release and deployment. Then rework, because something was wrong.
The commonly cited figure is that coding is about 20% of the lifecycle. I'd treat that number carefully: it gets repeated widely and sourced thinly, and the honest version is that it varies enormously by organisation. But I've never seen a team where implementation was the majority of elapsed time, and I've seen plenty where it was well under a quarter. Waiting is most of software delivery. Waiting for a decision, waiting for a reviewer, waiting for a test environment, waiting for a release window.
So we took the most powerful productivity tool of my career and pointed it squarely at the minority of the timeline. Then we were surprised.
The arithmetic, done plainly
This is Amdahl's Law, which you may remember from parallel computing, applied to an organisation instead of a processor. The speedup of a system is limited by the fraction you didn't speed up.
If coding is 20% of your elapsed time and you make it 5x faster:
- That 20% becomes 4%.
- The other 80% is unchanged.
- Total: 84% of the original.
- Net improvement: 16%.
Make coding infinitely fast (free, instant, perfect) and you still only get 20%. That's the ceiling. Not 20% per year: 20%, total, forever.
Do it with your own numbers. Estimate what fraction of your delivery time is implementation, and that fraction is the absolute maximum improvement available from making implementation faster. For most teams it's a disappointing number, and it's disappointing before you account for the part that makes it worse.
The part that makes it worse
Amdahl's Law says you get less than you hoped. Queueing theory says you might get nothing at all.
When you accelerate a stage that feeds a slower stage, you don't just fail to improve throughput. You increase work in progress: the amount of unfinished work sitting in the system. And WIP is not a neutral quantity. It's the thing that makes cycle time longer.
Every unreviewed PR is inventory. It's work you paid for that has delivered no value, and it decays: it accumulates merge conflicts, its author forgets the context, and it makes every other PR in the queue harder to review because they now overlap.
DORA's research has been picking this up for two years. Their 2024 report estimated that a 25% increase in AI adoption was associated with a 7.2% decrease in delivery stability and a 1.5% decrease in throughput, even while individual productivity and satisfaction went up. That is a correlation in survey data, not proof of cause, but the direction is hard to ignore. That combination is the whole story in one sentence: developers felt faster, the system got less stable, and delivery didn't improve.
The framing DORA settled on in its 2025 report is the right one: AI is an amplifier, magnifying the strengths of high-performing organisations and the dysfunctions of struggling ones. Teams with strong review capacity, good tests, and clean deployment got faster. Teams with a review bottleneck got a bigger review bottleneck. The tool doesn't fix your process; it multiplies whatever your process already is, including the parts you don't like.
There's a specific reason AI-generated changes are harder to absorb than human ones, and it isn't quality. It's that review depends on trust that doesn't scale with generation.
When a colleague sends me a 200-line PR, I'm not reading every line. I'm reading the shape, checking the risky parts, and relying on the fact that they thought about it. If I'm unsure, I ask "why did you do it this way" and get a real answer that reflects real reasoning. With an agent-generated PR, the diffs are larger, the author has less context than usual because they didn't write it, and "why did you do it this way" returns a plausible reconstruction rather than a memory of a decision. So the reviewer has to actually read it. Every line.
That's not a quality problem. It's a bandwidth problem, and it lands entirely on the stage that was already your constraint.
Why each other stage didn't speed up
Requirements. AI writes a specification in ninety seconds. It does not get the specification signed. The constraint here was never document production: it was stakeholder alignment and decision latency. Three people needing to agree, one of whom is on leave. That's a calendar problem, and no model touches it. Teams that "accelerated requirements with AI" mostly produced more documents, faster, that sat waiting for the same approvals.
Review. Covered above. This is now the scarce resource in most organisations, and it's scarce in a way that's hard to buy your way out of, because reviewing well requires context about this codebase and these users.
Testing. This one is subtle and worth being precise about. AI writes tests eagerly and enthusiastically. It writes assertions poorly. You get high coverage of tests that verify the code does what the code does: which is tautological and catches nothing.
I have a live example. Three tools on this site shipped with real bugs, and the most instructive one was a calculator where every individual function was correct and unit-tested, but the comparison between two correct functions was meaningless. No amount of function-level test generation catches that, because the bug wasn't in a function. Coverage went up. Confidence should not have.
Security, compliance, release. Gated by process and by people. Almost entirely untouched so far. If your release window is fortnightly, your cycle time has a fortnightly floor regardless of how fast anything upstream runs.
What actually moves delivery time
The prescriptive half. This is the part I'd argue is worth acting on this quarter.
Measure end-to-end cycle time, and measure WIP. If you take one thing from this post: stop measuring per-stage speed and start measuring idea-to-production, plus how much unfinished work is in flight. Lines of code, PRs merged, and "time saved per developer" are all stage metrics, and optimising stage metrics is exactly how you end up here. A team whose PR authoring time halved while cycle time held flat has a number that went the right way and a system that didn't.
I hold my own numbers to the same test. When I moved my work onto agents, my merged PRs rose about 10x and median PR cycle time fell from 2.0 hours to 0.7 hours. Those are real, and they are also stage metrics. That cycle time runs from first commit to merge. It says nothing about how long work waited before the first commit, or after the merge before a customer saw it. Part of the drop is agents removing waits between people, not reviews getting faster. Agent-made PRs are also smaller, which inflates the count. That is why I give a range of 4x to 10x rather than the headline number.
Find your actual constraint, and write it down. Not "we should be faster." A specific named stage: reviews wait an average of 31 hours for pickup, or the average feature waits 9 days for a product decision. If you can't name it with a number, you're guessing about where to spend, and the default guess for the last three years has been "coding," which is why we're all here.
Then point AI at the constraint, not at coding. Concretely:
- If review is the constraint: AI pre-review passes that catch the mechanical issues before a human looks, automatic PR summaries explaining intent, risk-scoring so trivial changes route differently from dangerous ones.
- If testing is the constraint: generate test cases from requirements rather than test code from implementation. Assertions derived from what the feature is supposed to do, not from what the code currently does.
- If requirements are the constraint: turn ambiguous requests into explicit acceptance criteria and, more usefully, into a list of the decisions that need a human, surfaced early rather than discovered mid-sprint.
- If deployment is the constraint: verification, rollback confidence, automated release notes.
Reduce batch size, and defend it. Smaller PRs are the single highest-leverage unglamorous fix for a review bottleneck, and they always have been. What's new is that AI makes large PRs cheap to produce, so the natural drift is toward bigger batches at exactly the moment you can least afford them. This now needs active defence: a size limit, enforced, that people will complain about.
Move the human from author to editor deliberately, and staff for it. If your engineers are now primarily reviewing rather than writing, that's a different job with different skills, and pretending otherwise is how you get rubber-stamped approvals. Review is currently the highest-value activity in most engineering organisations and is almost universally treated as an interruption to the real work. That's backwards now.
Two honest counterarguments
First: some of the gain is real but invisible in cycle time.
Throughput is not the only thing that matters. Less fatigue on tedious work. Faster onboarding. And most importantly: scope that would never have been attempted at all. The refactor nobody would have budgeted, the internal tool that was never worth a sprint, the test suite for the legacy module. Those don't show up in cycle time because they weren't in the plan. They show up as capability that didn't exist.
I think that's genuinely underweighted in the sceptical take, including in most of the DORA discourse. A team that ships the same amount but ships things it previously couldn't attempt has gained something real that no delivery metric captures.
Second: the bottleneck moves.
Fix review and the constraint relocates: to requirements, to deployment, to product decision latency. Someone will read this post, spend a quarter fixing review, and find their cycle time barely moved because the constraint went somewhere else.
That's not failure. That's what the Theory of Constraints actually says: you identify the constraint, you elevate it, and then you go find the new one. It's a loop, not a project. Anyone selling a single permanent fix, including anyone selling AI as one, doesn't understand the shape of the problem.
The question to actually ask
The industry spent three years asking "how much faster does AI make my developers?" It's a measurable question with an encouraging answer, which is why it got asked so much.
It's also the wrong question, because it's a stage question, and stages aren't what customers experience.
The right one is harder and less flattering: what is my constraint, and did I just spend a year and a large budget making a different stage faster?
In my experience most teams have not asked it once. The ones that improve delivery are the ones that aim the tool they already have at the part of the system that is actually holding them back.
The tool was never the problem. The aim was.
Related Reading
Enjoying this article?
Get posts like this in your inbox. No spam, unsubscribe anytime.
