Writing Code Was Never the Bottleneck

AI is very good at making one part of software development faster, which is writing the code. The trouble is that writing code was rarely the slowest part of getting a change into production. If everything that happens after the keyboard - review, testing, integration, release still moves at its old pace, faster code generation doesn't speed the team up. It just builds a larger queue in front of the same bottleneck.

There's reasonable evidence for this now. The 2025 DORA report, which surveyed thousands of engineers, found that teams adopting AI tend to ship more software while their delivery becomes less stable, and its broader conclusion is that AI behaves as an amplifier of whatever a team already has. A separate randomised study from METR found that experienced developers working on code they knew well were around 19% slower with early-2025 AI tools, even though they felt faster. The speed people feel and the speed they actually get can come apart, and what closes the gap is the system the code has to travel through, more than the tool that writes it.

Why faster code doesn't mean faster delivery

For most teams, getting from an idea to running software is mostly waiting. A change gets written, and then it sits in a review queue. It moves to a separate testing stage, and waits again. It waits for a release window, for a sign-off, for another team to be ready. The typing itself is a small slice of the elapsed time, which is why making the typing faster does so little to the total.

When a developer using AI can produce a working change in a fraction of the old time, those waits don't shrink to match. If anything they become more visible, because the change that took an hour to write now spends a week in the queue behind everything else. The faster the writing gets, the more of that new speed you give back at the first handoff.

Continuous delivery is the part AI makes more urgent

The discipline of continuous delivery has argued the same point for about twenty years: the moment a developer commits a change, it should move towards production on its own, through whatever automated checks are needed, without a person having to stop and pass it along by hand. A manual handover is the slowest and most fragile step you can put on the road to production, and that was true long before AI arrived.

AI doesn't change that argument so much as raise the stakes on it. When the writing speeds up, far more changes arrive at each handoff, and a process that relies on people moving work along by hand begins to strain. The teams that get the most from AI tend to be the ones that had already taken those handoffs out, often years earlier. The foundation was in place, and AI gave them a reason to build the rest on top of it.

Manual QA as a separate stage becomes the queue

A common version of this is a separate, manual QA stage sitting downstream of development. A developer produces something quickly, hands it to QA to be checked, and the checking turns into the queue that everything else backs up behind. Speeding up the development in front of it only makes that queue longer.

The better approach is to fold quality into the flow itself, so that a change which passes its automated checks can move to production without a person in the middle. That means treating the pipeline which proves a feature works - the tests, the checks, the gates - as a real part of the work rather than something bolted on at the end. With AI in the picture there's an obvious place to spend some of the time it frees up, because agents can help build that pipeline too, which makes the absence of one harder to justify.

Measure the whole flow: value stream mapping

The most useful thing a leader can measure here is also one of the oldest, and it has a name: value stream mapping. You track how long a change takes to travel from the moment work starts on it to the moment it's live in production. Map that for a handful of representative changes and the picture tends to be the same. The time is dominated by waiting - in review, in QA, in approvals, in the gaps between teams - and very little of it is spent writing code. Once you can see that clearly, it becomes obvious why faster typing barely moves the number, and why fixing the flow is what moves it.

Can you go from the waterfall straight to AI?

We get asked some version of this often: can an organisation that still works in a waterfall style - everything planned in advance, broken into stories, specified, and approved through a chain - move straight to AI-native development? In our experience the honest answer is usually no, and not for any reason to do with the AI.

Waterfall assumes you can plan the work in large batches up front, write the specifications for all of it, and feed them to developers in order. AI puts pressure on that assumption from both ends. Engineers become quick enough that planning two weeks of work in advance stops making sense, because they run out of planned tasks before the plan is finished. And the work itself shifts towards people directing agents in the moment, rather than implementing a specification written weeks earlier. A planning process built for batches sits awkwardly next to a way of working that wants to pull tasks continuously, which is why the more reliable path is to fix the flow first and add AI on top of a system that can carry the extra volume.

The quality trap that makes this worse

There's a particular way this goes wrong, and it feeds straight into the instability DORA measured. When a team is handed AI tools and nothing else changes, the people who go deepest fastest are often not the most experienced ones. They're the ones who got most excited. A less experienced engineer with an enthusiastic tool can produce a single five-thousand-line change that someone now has to review - unplanned, loosely structured, and not built the way the team builds things. What you get from that is a review burden and a future maintenance cost arriving sooner than before, rather than the productivity gain it looks like.

The belief underneath the trap is that AI removes the need for engineering discipline - that you prompt it and good code comes out - and it doesn't. If a hundred developers writing code by hand need standards, review, and architecture to produce something decent, the same holds with AI in the loop. What changes is where the discipline lives. Rather than relying on people to enforce it after the fact, you can build specialised agents that apply the right practices during the work - agents that check quality, agents that validate, agents carrying the judgement a senior engineer would otherwise bring to a review. Handled that way the output is reasonably good and gets better over time, because each lesson from a human review can be written back into the agent that handles the next one.

What to fix first

If there's one thing to take from the DORA and METR findings, it's that making your engineers quicker at writing code is a weaker lever than it appears. The lever is the flow from intent to production, and AI is at its most useful sitting on top of a flow that already works.

In practice that's a short, ordered set of moves: map your value stream to find where changes really wait, take out the worst manual handoff on the way to production and then the next one, and build automated testing you trust enough to release behind. Only once that's in place is it worth pointing AI at the writing, because by then the extra volume has somewhere to go. Used on top of a flow that works, AI amplifies a system that can carry it; used the other way round, it amplifies the cracks, and the drop in stability that DORA measured is roughly what that looks like across a whole industry.

Frequently asked questions

Does AI make software developers faster? Not automatically. The 2025 DORA report found that teams adopting AI tend to ship more while becoming less stable, and a randomised METR study found experienced developers were around 19% slower on familiar code with early-2025 tools, even though they felt faster. AI speeds up writing code, which is usually not the bottleneck, so the gains depend heavily on the delivery system around it.

Why does continuous delivery matter so much for AI development? Because AI increases the number of changes flowing through a team, and any manual handoff on the way to production - a separate QA stage, a manual review gate, a release window - turns into the place everything backs up. Continuous delivery removes those handoffs, so that faster writing turns into faster shipping rather than a longer queue.

Can you adopt AI development on top of a waterfall process? Usually not effectively. Waterfall depends on planning work in large batches and writing specifications in advance, and AI undermines that by making engineers quick enough to exhaust planned work and shifting them towards directing agents in the moment. Fixing flow and moving towards continuous delivery first tends to be the more reliable path.

What's the single most useful thing to measure? How long a change takes to go from started to live in production. For most teams that time is dominated by waiting in queues and handoffs rather than by writing code, which is exactly why faster writing on its own does so little.

re:cinq helps engineering organisations build the delivery practices and platform foundations that make AI worth adopting. If you want to find out where your flow breaks before you scale AI on top of it, our free book From Cloud Native to AI Native is a good place to start.