The code review bottleneck: why AI made it worse

For most of software history the asymmetry ran one way: writing code took longer than reading it. Assistants flipped that. A model can now produce a plausible feature faster than a person can meaningfully understand and verify it. The typing got cheap. The reading didn't. So the queue backs up at the one step you can't automate away, which is a human deciding whether the change is actually correct.

That's the code review bottleneck. This post is about why it forms, why AI made it more acute rather than less, and what to change. Short version up front: the lever is process discipline, and the tools only help once that's in place.

AI moved the constraint, it didn't remove it

The 2025 DORA report on AI-assisted software development is the clearest data on this. Its headline finding is that AI's main effect is to amplify what an organization already has, and that the biggest returns come from the surrounding system rather than the tool. One of the systems it points at directly is review. DX, summarizing the same research in its walkthrough of the DORA findings, puts the mechanism plainly: AI dramatically speeds up authoring while review capacity stays flat, so the constraint moves downstream and review becomes the dominant limit on throughput.

You can watch this happen on your own board. Generated code arrives verbose and confident, often in larger diffs than a human would have hand-written. More changes, bigger changes, all landing on the same finite pool of reviewer attention. Cycle time doesn't improve the way the authoring speedup suggested it would, because the work just piled up one step later. The same DX write-up notes teams with faster code reviews see roughly 50% better software delivery performance, which is the flip side of the same coin: review latency is where a lot of delivery performance is won or lost.

AI is an amplifier, so fix the process first

The amplifier framing is worth taking literally. As the DORA authors put it, AI is an amplifier of the things you already have in your organization. Point it at a team with small changes, fast review turnaround, and authors who verify their own work, and it makes a good loop faster. Point it at a team with giant MRs, one overloaded reviewer, and a habit of merging on vibes, and it makes that dysfunction bigger and more visible.

DX's Laura Tacho makes the same argument about foundations. Her point is that the speed of code generation doesn't translate on its own into higher-quality software, and that architecture, security, and maintainability still need direct attention. In her piece on whether AI is a paradigm shift or just another dev tool, the through-line is that the fundamentals of software engineering are what determine whether AI helps you. If review is already your weak spot, adding an assistant to the authoring side doesn't relieve it. It loads it.

The practical read: don't buy your way out of a review bottleneck before you've fixed the review process. A tool laid over a broken loop amplifies the breakage. A tool laid over a healthy loop compounds the gains.

The two ways review breaks under load

Michaela Greiler, who has studied code review practices for years, describes two failure modes that show up specifically with fast AI-assisted development. She calls them surrender and exploitation, and they're a useful diagnosis because they fail differently.

Surrender is the capacity failure. Reviewers still value review, but they can, in her words, no longer meaningfully keep up with the volume and pace of submitted changes. The queue wins. Approvals turn into rubber stamps because the alternative is becoming the bottleneck everyone blames. The review still happens on paper; it stops happening in practice.

Exploitation is the responsibility failure. When an author leans on a model and doesn't do their own understanding and verification first, that work doesn't disappear. It lands on the reviewer, who now has to reconstruct intent and confirm correctness the author never established. Review was designed as a second check on top of a first one. When the first one is skipped, the reviewer is quietly doing both jobs.

Both get worse with volume, and both are process problems, not tooling problems. Greiler's own conclusion is not to abandon review but to make author-side responsibility visible before a change reaches a reviewer. That's the hinge for the fixes below.

What to actually change

None of these need a purchase order. They're the foundational habits AI amplifies when they're present and punishes when they're missing.

• Shrink the change. A 200-line MR gets a real review; an 800-line one gets skimmed. This matters more with generated code, which trends large. Splitting work into smaller merge requests is the single most effective move against surrender, because it keeps each review inside a human attention budget.
• Make authors show their work. The antidote to exploitation is a description that says what changed, why, how it was tested, and what the author is unsure about. If a model wrote the code, the author still owns the verification. A reviewer reconstructing all of that from scratch is the tax you're trying to remove.
• Make the queue visible. A review sitting for two days should be obvious to the team, not discoverable only by opening GitLab and going looking. Stale reviews cost twice, because the reviewer has to reload context the author has already forgotten.
• Spread the load deliberately. Round-robin assignment or review pairs beat the default, where requests orbit one trusted name until that person is a single point of failure with a calendar. Juniors review slower; that's how they stop being juniors.
• Measure review latency, then attack it. Time-to-first-review and time-to-merge are the numbers that track the bottleneck. If faster reviews correlate with better delivery, latency is a metric worth a standing place on your dashboard.

Where AI genuinely helps

None of this is an argument against AI in review. A model can summarize a diff, flag an obvious null-pointer path, or catch a style regression before a human looks, which clears low-value noise off the reviewer's plate. That's real. The caveat is that it works as a first pass under a human decision, not as the decision. An assistant that approves its own generated code closes the loop with nobody actually in it, which is surrender with extra steps. Use AI to make the human review cheaper, and keep a human on the accountable end.

Bottom line

The bottleneck moved from writing code to reviewing it, and AI is the reason. Treating that as a tooling gap is the trap, because AI amplifies whatever process it lands on. Fix the loop first: smaller changes, authors who verify their own work, a queue nobody can ignore, and load spread on purpose. Then any tool you add, ours included, compounds a healthy process instead of magnifying a broken one.