Code Was Never the Bottleneck

April 26, 2026

Here is the pattern to look for in your own team. Every engineer reports that the tools make them faster. The roadmap does not move faster. And the first number that changes is not deployment frequency - it is how long a change waits before someone reviews it.

If that describes your last few quarters, nothing has gone wrong with your adoption. You are watching a constraint reveal itself.

Writing code was never the bottleneck. It was the most visible part of the work, so we mistook it for the constraint - and then we automated it and found out.

Individually Faster, Organizationally Slower#

The evidence for individual speedup is genuinely mixed, and worth being careful about, because it is the number everyone reaches for.

In early 2025, researchers timed experienced open-source developers working with AI assistants and found them 19% slower, while the developers themselves estimated they had been 20% faster. A follow-up run late that year, by the same lab, largely reversed the headline: returning developers measured around 18% faster, though the confidence interval was wide enough to span everything from a large speedup to a slight slowdown, and developers new to the study showed almost no effect. The lab also notes that its recruiting systematically misses the developers most enthusiastic about AI, so it treats its own estimate as a likely lower bound¹².

Sit with what that means. The single most-cited measurement of AI’s effect on developer productivity moved almost forty points in twelve months and still has error bars you could drive a roadmap through.

That is not a reason to distrust the researchers. They did the unusual and admirable thing of publishing the reversal. It is a reason to stop building strategy on individual coding speed, because it is a small, noisy, contested quantity - and it is not the one your company feels.

The number that has been stable is the organizational one. In 2024, the largest ongoing study of software delivery found teams adopting AI shipping less and breaking more. A year later the shipping speed had recovered. The instability had not³.

DORA’s own summary is the honest one: “AI doesn’t fix a team; it amplifies what’s already there.”

Individually faster but organizationally flat is not a paradox. It means the constraint sits downstream of the keyboard.

The question is not whether your engineers feel faster. It is where their output piles up.

The Queue Moved to Review#

The waiting did not disappear. It moved.

It is not in the writing now. It is in the pile of changes nobody has read yet, and the shape of that pile is now well documented. Across 8.1 million pull requests from 4,800 teams, AI-assisted changes wait 4.6 times longer to be picked up by a reviewer than unassisted ones. For fully agentic changes it is 5.3 times longer - seventeen hours against three. They arrive 2.6 times larger at the 75th percentile: 408 lines against 157. And 32.7% make it through review unmodified, against 84.4% of human-written changes⁴.

Bigger changes, arriving faster, needing more correction, at a number of reviewers that did not change.

The same crunch shows up outside companies. The curl project ended its bug bounty in early 2026 after AI-generated vulnerability reports flooded in. The share of submissions that turned out to be real had run above 15% for years; in 2025 it fell below 5%. Every false one still cost a human hours to read, reproduce, and close⁵.

Cheap generation does not remove work. It moves the work onto whoever has to decide whether the output is true.

The Team Can Only Digest So Much#

There is a second cost, slower and quieter.

A team can only absorb so much new code. Read it. Question it. Connect it to what already exists. Learn to trust it. That digestion is the part AI did not speed up.

You can see what happens when it is skipped. Across 211 million changed lines, duplicated code blocks rose eightfold during 2024, while refactored code - the work of folding new code into the existing structure - fell from roughly a quarter of changed lines in 2021 to under a tenth⁶.

The point is not that generated code is worse. Held to the same standard, reviewed by the same people, it frequently is not. The point is that a third of it arrives needing changes and it arrives faster than anyone can make them, so the correcting work gets deferred - and deferred correction is how code that nobody has fully connected to anything accumulates.

Almost-right code that nobody folds back into the system is not an asset yet. It is inventory.

A codebase filling with code that no one truly understands produces exactly what unmanaged technical debt always produced: engineers who hesitate before every change⁷.

The Absorption Test#

None of this is an argument to slow down. It is an argument to invest where the constraint actually is.

Measure at the main branch, not at the keyboard. How long does a change sit before someone reviews it? How often does a merged change break something? How often does it get redone? None of that is visible from an editor, which is why the tools feel better than the quarter looks. If waiting time is climbing while delivery is flat, the diagnosis is already made: you bought generation without buying absorption.

Treat review capacity as a budget. Count the people who can actually review a change in your codebase. That is your budget, and it does not grow when generation does. Cap the size of AI-assisted changes - if the industry’s 75th percentile is now over 400 lines, a cap somewhere near it is not bureaucracy, it is solvency. Small changes were always the fastest path⁸; now they are the whole game.

Make the author explain it back. Before merging an AI-assisted change, its author should be able to say what it does, what it duplicates, and what breaks if it is wrong. The author, not the model. If nobody can answer, nobody owns that code - and unowned code is the debt that shows up as instability two quarters later.

Run this as an actual audit. Five questions, and the answer that should worry you:

Do it once a quarter, per team, and write the answers down. The trend matters more than any single reading.

All three of these cost something, and it is worth being honest about what. Size caps mean more overhead per unit of work, and engineers who finally felt fast will feel throttled by a rule that exists to protect someone else’s afternoon. The explain-it-back requirement slows merges, and delivered carelessly it reads as distrust of the engineer rather than of the tool. The audit itself is an hour per team per quarter that nobody will thank you for. You are deliberately trading individual throughput for organizational throughput, which is exactly the trade that looks wrong to everyone whose own throughput just went down.

One question sits under all of it: can your team absorb everything it can now produce? If not, more generation is not an investment. It is inventory you have not paid for.

Closing#

Every technology shift exposes what was scarce all along.

Compilers made machine code cheap and exposed design. Open source made components cheap and exposed integration. Cloud made servers cheap and exposed architecture.

AI made code cheap. What it exposed is that the scarce thing was always understanding: knowing what to build, whether it works, and what it will cost to live with.

Typing was the cheapest part of the job, and we automated it.

What remains is the job.

References#