Code Review Is the New Bottleneck

Published: at 08:24 PM

Table of contents

Open Table of contents

The constraint moved, and nobody updated the process

Every system has a bottleneck. Speed up any other part and you don’t get a faster system — you get a bigger pile in front of the constraint.

For most of my career, the constraint in software teams was writing the code. Review was an afterthought bolted onto the side: a quick scan, a couple of nitpicks, approve. It worked, because code arrived at a human pace. A senior engineer could absorb three or four PRs a day without breaking stride.

That world is gone. I wrote earlier this year that the prompt is the new pull request — that generating a change went from days to minutes. What I underestimated was the second-order effect: when code gets cheap, review becomes the most expensive thing your team does. The pile didn’t disappear. It moved in front of the reviewers.

The uncomfortable math

Here’s the arithmetic nobody wants to do. One engineer running a couple of agents can comfortably open six or eight PRs a day. A team of five does that, and you’re looking at thirty-plus PRs daily — against a review capacity that hasn’t moved since 2022.

I watched this happen on my own team. In one month, our merged-PR count roughly tripled. Our median time-to-merge got worse. Not because anyone slowed down — because everything queued in review. We had built a machine that produces faster than it can inspect, which is another way of saying we had built a warehouse, not a pipeline.

And the failure mode is sneakier than a visible queue. When reviewers drown, they don’t usually say “I’m drowning.” They start skimming. Approvals speed up, scrutiny quietly drops, and the review becomes theatre — a green checkmark that certifies nothing. The dangerous version of the bottleneck isn’t slow reviews. It’s fast, empty ones.

A review queue that’s too long doesn’t stay long. It becomes shallow. That’s worse.

You’re reviewing at the wrong altitude

The instinctive response is “we need to review faster.” That’s the wrong lesson. Reading AI-generated code line by line, at the pace it’s produced, is a losing race — and it was always the least valuable way for a senior engineer to spend attention.

Line-level review made sense when the lines were the risk: a human typed each one, and each one carried human error. Agent-written code fails differently. The syntax is usually fine. The conventions are usually fine. What goes wrong is the intent — the change solves a slightly different problem than the one you had, handles the case you didn’t mention by inventing a behaviour, or quietly weakens an invariant nobody wrote down.

So the review has to move up a level. I’ve argued that engineers are shifting from author to orchestrator, and review is where that shift bites hardest. The questions worth human attention are:

Let the machine review the machine

The layers below that — style, conventions, obvious bugs, missed edge cases — shouldn’t reach human eyes at all. This is exactly the work agents are good at, and exactly the work that burns reviewer attention on things that don’t need judgment.

Our current setup: every PR gets an agent review pass before a human is ever assigned. It checks the diff against our conventions, hunts for the mechanical bug classes, verifies the tests actually exercise the change, and — critically — writes a summary of what the change does and why, which the human reviews first. Types and CI already stand guard underneath all of it. By the time a person looks, the mechanical layer is clean and the question on the table is the only one that needs a human: is this the right change?

That cut our human review time roughly in half, and the reviews got better, not worse — because the attention that used to be spent spotting an unused import now goes to the design.

The caveat

Let me be clear about what I’m not saying. I’m not saying trust the agent’s review and rubber-stamp the rest. An agent pre-review is a filter, not an absolution — and accountability for what merges stays with a human, full stop.

Trust here has to be calibrated, not given. New codebase, new failure domain, high blast radius: the human review stays deep, and you should expect to reject things. Well-worn territory with strong guardrails and a track record: the review can legitimately live at the spec-and-proof level. The mistake is running one undifferentiated process for both — that’s how you end up simultaneously too slow and too careless.

Treat review capacity as a first-class constraint

The practical shift is this: stop measuring how fast your team can produce changes and start measuring how fast it can safely absorb them. Put review latency and review depth on the same dashboard as deployment frequency. Staff for it. Build the agent pre-review layer. Review specs before code exists. Tier scrutiny by blast radius.

Because the teams that win with AI won’t be the ones that generate the most code — generation is a commodity now. They’ll be the ones that built a verification pipeline that matches it, so that outcomes actually ship instead of queueing. That’s not a chore to endure. It’s an engineering problem — one of the highest-leverage ones in my whole AI Engineering practice right now.

The constraint always moves. This time it moved to review — and it deserves the same engineering rigor as anything else in your pipeline.