Review capacity is the new bottleneck

Pull requests in flight went up. Then stacked PRs started appearing.

That's the one that told me. Stacking is what engineers do once they've quietly stopped believing the queue will clear. Waiting is intolerable, so they build on top of unmerged work, and now you have a dependency chain parked in front of a bottleneck.

It leaves a trace in the repo. Which makes it a better early signal than any cycle-time chart, because a chart tells you review is slow. Stacking tells you people have already reorganised their working lives around review being slow.

Nobody had got worse at their job.

The team had got much faster at producing diffs and not one bit faster at deciding whether a diff was safe to ship. That's the whole pattern. It also generalises further than most people expect.

For twenty years the scarce resource in software delivery was writing. The time it took a person to type out a correct implementation. Every process, every metric, every headcount conversation assumed that constraint, usually without saying so out loud.

Agentic tools remove it. Or come close.

And a constraint doesn't disappear when you remove it. It moves to whatever was next in line, which here is review, testing, and the judgment call about whether this particular change is actually correct.

Why more output can make a team slower

Review capacity is roughly fixed. A person can carefully read and reason about only so many diffs in a day, and that number is not sensitive to how excited anyone is about tooling.

So when the arrival rate doubles, the queue doesn't grow a little. It runs away.

The system was never sized for the new rate. Same mechanics as any queue anywhere: the moment arrivals exceed service capacity, waiting time stops rising gently.

The visible symptom is a backlog. The less visible one is worse.

Reviewers under that pressure start approving faster and reading less closely, because a long queue is a constant, silent argument for skimming. Defects that would have been caught reach production instead, on a delay of a few weeks. So the connection back to "we sped up generation" is almost never made.

The org concludes it has a review-quality problem. Or a hiring problem. What it actually has is an unrebalanced pipeline, and it will spend a quarter fixing the wrong thing.

Treat the output like a very fast junior

The useful mental model isn't "code written by a senior engineer, just faster."

It's a junior with unusual range, no fatigue, and zero institutional memory. No felt sense of which shortcuts have burned this team before. No model of which parts of the codebase are load-bearing. No discomfort whatsoever about being confidently wrong.

That has a direct implication. A junior's PR gets read fully, line by line, by somebody who then owns having approved it.

Agent-authored code deserves the same. Not the lighter pass you'd give a senior colleague's change, and definitely not the "it compiled, tests passed, ship it" pass that speed pressure produces.

Tests passing is a necessary condition. It was never a sufficient one. And it's a weaker signal than usual on code nobody here has thought through.

What actually helps

Batch size discipline stops being a nice-to-have. It becomes the load-bearing policy.

Diff size used to be bounded by how fast a person could type. That bound is gone. An agent will hand you eight hundred lines in the time it took to write eighty, so the cap has to be policy rather than hope. A large diff reviewed in ten minutes isn't a fast review. It's an unreviewed change with a green checkmark on it.

Ownership stays attached to a name. Every merged change, whoever or whatever drafted it, needs one accountable human who read it, understood it, and gets paged when it breaks. Diffuse that across "the team reviewed it" and responsibility evaporates. Fastest under exactly the volume pressure this tooling creates.

Then the unglamorous half. Invest in review capacity with the same seriousness as generation capacity. Faster CI. Better coverage on the paths that actually matter. Tooling that surfaces the interesting five lines of a five-hundred-line diff rather than asking a person to go find them.

Most teams spend the entire budget on the generation side, because that's the side with a demo. The review side doesn't have one. It's exactly as important.

Agents reviewing agents, which is where I've actually landed

Two obvious responses to the queue. I've rejected both.

Slowing generation gives back the thing you just bought. Adding human reviewers is expensive, slow to arrange, and doesn't scale against a generation rate with no ceiling.

What I run instead is a machine first pass, before any human sees the change. It runs the tests, checks the diff against house conventions, looks for the obvious categories (unhandled errors, missing migrations, a change reaching somewhere it shouldn't), and rejects or annotates before anything lands in a person's queue.

What that buys isn't judgment. It's filtering.

The human stops spending attention on the class of problem a machine finds reliably. They spend it on the class it can't: is this the right change, does it fit where we're going, what does it do to the thing sitting next to it.

Getting there took vendor trials and a few false starts. The failure modes were consistent enough to name in advance.

Review agents that are far too verbose, burying the one real comment under thirty procedural ones. And review agents that don't follow house coding standards, which is the same gap that makes context files worth maintaining, arriving from a different direction.

Two honest caveats, because this is the least settled part of my own practice.

The machine pass has a known blind spot. An agent reviewing agent-authored code shares many of the same assumptions, so it's good at mechanical correctness and poor at noticing the whole approach is wrong.

And the accountability rule doesn't move. A human still reads it. Still approves it. Still carries the pager. The machine pass shortens the queue, it doesn't take anyone's name off the change.

I'd expect to revise this within a year. Current answer to a fast-moving constraint, not a principle.

The actual question

The question worth asking before you expand this tooling isn't how much faster you can generate.

It's what your review capacity is, and whether it grows with this. If the answer is no, you aren't buying speed. You're buying a longer queue with a faster front door, and the bill turns up later, attached to something else's name.