Output Went Up, Review Capacity Didn't

A team adopted coding agents and PR volume roughly doubled within a couple of months. Review capacity did not, because review is a human activity that got no faster. The queue grew, review quality dropped under load, and the throughput gain partly evaporated into a bottleneck one step downstream.

This is the most predictable consequence of faster generation, and it's the one teams plan for least.

Why review doesn't speed up the same way

Generating a change and verifying a change are different activities with different constraints.

Generation is now largely parallel — several changes can be in flight at once, and the agent's speed doesn't degrade with volume. Review is serial per reviewer and degrades with fatigue. A person reviewing their eighth PR of the day is not the same reviewer as at their first.

Worse, agent-written changes can be harder to review in a specific way: they're often locally correct, idiomatic, and plausible. The bugs that survive are the ones that look right — a subtly wrong assumption, a missed edge case, an interaction with something three modules away. Those take more attention per line than an obvious mistake would.

⚠️ The failure mode isn't reviewers refusing. It's reviewers approving faster with less scrutiny, which is invisible until something ships that shouldn't have.

The signals that this is happening to you

• Review latency rising while merge volume rises.
• Time-to-approve falling — the number to watch. If median review time drops while PR size holds, scrutiny is dropping.
• Approvals with no comments becoming the norm.
• A rise in defects found after merge rather than during review.
• Reviewers concentrated on one or two people who become the constraint and then the burnout risk.

What actually helps

Shrink the diffs. A large agent-written PR is the worst case for review. Constrain the unit of work so each change is small and single-purpose — one file, one behavior, one commit. This costs a little coordination and it's the highest-leverage change available.

Make the agent produce review aids, not just code. A change that arrives with the reasoning, the alternatives considered, and — most usefully — what it's least sure about is much faster to review than the same diff bare. An honest "I wasn't certain whether the retry here should be idempotent" points the reviewer directly at the risky part.

Automate everything mechanically checkable, ruthlessly. Style, lint, type checks, test coverage, schema validation, forbidden patterns. Every check a machine can perform is attention returned to the human for the part only they can do. This was always good practice; it becomes load-bearing when volume doubles.

Verify against the requirement, not against the code. ✅ The most valuable review question for agent output is "does this do the right thing?" rather than "is this well written?" Generated code is usually well written. Whether it solves the actual problem — including the parts that weren't in the ticket — is where human review earns its cost.

Cap work-in-flight. If review is the constraint, generating more changes doesn't increase throughput, it increases queue. Limiting concurrent open PRs to what the team can actually review is unglamorous and it's how the bottleneck stops growing.

💡 The uncomfortable implication

If review is the constraint and review is human, then team throughput is bounded by human review capacity regardless of how fast generation gets. Which means:

• Additional generation speed past that point buys nothing.
• The scarce resource is people who can review credibly — meaning they understand the system well enough to catch a plausible-but-wrong change.
• That ability comes from having built and debugged things, which is exactly the activity being reduced.

→ There's a real tension here without a clean resolution: the skill needed to review agent output is developed by doing the work agents now do. Teams that notice this early and deliberately keep people building — not for the output, but for the capability — are making a defensible investment. Teams that optimize purely for throughput now may find they've depleted the thing throughput depends on.

The takeaway

Faster generation moves the constraint to review, and review didn't get faster. Watch time-to-approve rather than merge volume, shrink the diffs, have agents surface their own uncertainty, automate every mechanical check, and cap work-in-flight to what can actually be reviewed. And treat the ability to review well as a capability that has to be maintained, because it's developed by exactly the work that's being automated.