In my last post I argued that the engineer’s job has shifted from writing code to deciding whether the code is right. The place that shift hurts most, right now, is code review. When a few agents are opening pull requests all day, the queue stops being a formality and becomes the thing that decides how fast — and how safely — your team ships.
The data backs up the squeeze. One analysis of the bottleneck found AI-assisted PRs wait several times longer for review pickup and get accepted far less often — around a third of the time, versus over 80% for human-authored PRs — even as branch throughput climbs year over year. The generation got cheap. The reviewing didn’t. So here’s what teams who are ahead of this are actually doing, how well it works, and how to set it up.
Automate everything a human shouldn’t be reading
The first move is to get human eyes off anything a machine can check. Formatting, linting, type errors, dependency and secret scanning, known-vulnerability patterns, and the test suite all belong in CI as required gates, not in a reviewer’s head. GitHub’s own guidance on reviewing agent PRs makes the same point: push the mechanical checks to automation so the human can spend attention on whether the change solves the right problem.
This isn’t new advice. The volume is what makes it non-optional — at one PR an hour, you cannot afford to be the linter.
Setup: required status checks on the branch; the PR fails on lint, types, tests, and security scan before a human is even pinged.
Put an AI reviewer in front — but watch the noise
The fastest-growing layer is an AI reviewer that does a first pass before any human looks: CodeRabbit, Greptile, Graphite’s Diamond, Cursor’s bug bot, GitHub’s own. They post inline comments on the diff, and they genuinely catch things. Teams running an AI review layer report meaningfully faster merges and fewer post-merge defects — one set of numbers put it near 30% faster merges and roughly a quarter fewer defects than human-only review.
The honest part is the tradeoff between catch rate and noise. In one 2026 benchmark, the higher-recall tools caught far more bugs but produced several times as many false positives. That matters more than it sounds. A reviewer that cries wolf gets muted, and a muted reviewer is worse than none — because now people are rubber-stamping past its comments. The metric I’d actually watch isn’t bugs-caught, it’s fix rate: what fraction of its comments lead to a real change. A tool whose flags mostly get acted on is doing its job; one you scroll past is just latency.
Setup: start with one tool, tuned conservative, and treat it as a first pass — never the gate. Pick for your tolerance: precision-first if your team is small and can’t afford noise; full-repo-index recall if you have a large codebase where changes cascade and you’ll triage the false positives.
Make the PRs small — this is the biggest lever
None of the above saves you if the agent hands you a 1,500-line diff. The single highest-leverage change is also the oldest piece of review wisdom: small PRs. An analysis of 1.5 million pull requests found changes in the 200–400-line range had about 40% fewer defects and were approved roughly three times faster than larger ones.
The technique that’s surged for this is stacked PRs — breaking one big change into a chain of small, focused, independently reviewable layers that merge together. Graphite popularized it; GitHub shipped native stacked PRs in 2026, and you can teach your agents to produce stacks instead of monoliths from the start. If I could make only one change, this would be it, because it makes every other strategy work better — small diffs are where both AI reviewers and humans are accurate.
Setup: adopt Graphite or GitHub’s native stacks; set a soft line-count budget; instruct your agents (in CLAUDE.md or its equivalent) to split work into stacked PRs from the beginning of a task.
Keep the human on intent
Here’s the part you can’t automate, and it’s the actual job. When an agent opens a PR, you get a finished diff with no decision trail — none of the “I tried X, it broke, so I did Y” you’d get from a human author. As GitHub’s guidance puts it, an agent is a literal, pattern-following contributor with zero context about your incident history or your team’s edge-case lore, and judgment requires context only you have.
So human review stops being “is this code correct line by line” — the bot helps there — and becomes “does this solve the right problem, fit the architecture, and respect the things the agent couldn’t know.” One concrete habit worth stealing: agents reach for a new helper rather than the one that already exists, which quietly piles up redundancy and debt (a January 2026 study found agent-generated code carries more duplication per change than human code). For every new utility in an agent’s PR, do a quick search for an existing equivalent and require consolidation before merge.
Setup: require a PR description that states intent and links the plan or ticket, and review against that — not just the diff.
Catch it before the PR exists
The best review is the one you don’t have to do. Most of the bad PRs clogging a queue are ones the agent could have caught itself, if you’d given it a way to. Verification loops upstream — tests, type-checks, a preview the agent runs and reads before it ever opens the PR — keep a whole class of broken changes out of review entirely. It’s the same shift-left idea I keep coming back to: the cheapest place to catch a problem is closest to where it was made.
And for the changes that are genuinely consequential — anything touching data, money, or customers — tier them. Let the cheap, reversible work merge on green checks, and reserve real human attention for the parts where a mistake is expensive. That’s the dual-review instinct applied to the queue: not every change deserves the same scrutiny, and pretending otherwise is how the important ones get rushed.
What actually works
If you take one thing from this: the teams keeping up aren’t the ones with the cleverest review bot. They’re the ones who fixed the process around it — automate the mechanical, shrink the diffs, keep humans on intent, push verification upstream — and then added a tool to amplify it. A bot sitting on top of 1,500-line PRs with no CI gates just generates more noise, faster.
Which is the same lesson the rest of this shift keeps teaching. The bottleneck moved from writing code to trusting it, and trust is engineered, not generated. Code review just quietly became one of the highest-leverage pieces of system design you do.
