AI Code Review Is Eating the Pull Request

Open a pull request on a modern engineering team in 2026 and the first reviewer to leave a comment is increasingly not a human. It is a bot. CodeRabbit and a wave of similar tools have moved automated, context-aware feedback directly into the pull request — summarizing the diff, flagging issues, enforcing standards, and doing it within seconds of the push. AI review is fast becoming the default PR gate, and the reason is not that engineers got lazy. It is that the volume of code arriving at the review queue has exploded, and human attention has not scaled to meet it.

Why AI Review Exploded: The Volume Problem

The pull request was designed for a world where writing code was the bottleneck. A human wrote a change at human speed, another human read it at human speed, and the rhythm balanced out. That equilibrium is gone. As AI writes a steadily larger share of the code that lands in production, the volume of diffs flowing into the review queue has decoupled from the number of humans available to read them.

The headline data point comes from Anthropic, which has reported that roughly 80% of its merged production code is now Claude-authored. Whatever the precise figure means in practice — and we unpack exactly what it does and does not measure in our analysis of Claude writing 80% of Anthropic's own code — the directional truth is undeniable. When most of the code is machine-generated, the review queue fills faster than any human team can drain it without the review itself becoming the bottleneck.

Faced with that flood, teams had two options: slow down merges to preserve human review, or automate the first pass. Most chose automation. An AI reviewer reads every diff the moment it lands, produces a plain-language summary of what changed, flags the obvious problems, and checks the change against the team's coding standards — all before a human opens the tab. The promise is seductive: reclaim human attention for the judgment calls that actually need it, and let the machine handle the mechanical pass.

What AI Review Does Well — and What It Does Badly

AI reviewers are genuinely good at a specific and valuable slice of the review job. They never get tired, never skim, and never skip the boring parts. They apply the same standard to the first PR of the morning and the fortieth of the day. For the mechanical layer of review — catching a missing null check, flagging an unhandled error path, noticing a style violation, summarizing a 400-line diff into three readable sentences — they are excellent, and they are excellent at a scale no human team can match.

Where they fall short is exactly where review matters most. An AI reviewer reads the diff, but it does not hold the architecture of the system in its head. It cannot tell that the change, while locally correct, pushes the codebase toward a boundary the team deliberately drew years ago. It does not know the author's intent — whether this is a quick hotfix that will be reverted Monday or a load-bearing abstraction other teams will build on. And it is weakest precisely on the novel security edge cases that have never appeared in its training distribution, the ones a paranoid senior engineer catches by smell.

This split maps almost exactly onto the trust gap developers already report with AI-generated code. The frustration is rarely code that is obviously broken — that gets caught. It is code that is almost right: plausible, well-formatted, and subtly wrong in a way that survives a quick read. An AI reviewer that shares the same blind spots as the AI author is poorly positioned to catch the almost-right failure, which is the most expensive one to miss.

The New Failure Mode: AI Reviewing AI

Here is the structural risk that the volume story sets up. If an AI writes the code, and an AI reviews the code, and a human glances at a green checkmark and clicks merge — who actually checked it? The danger is not hypothetical. The author-model and the reviewer-model are drawn from the same broad family of systems, trained on overlapping data, prone to overlapping blind spots. When they agree, that agreement looks like validation. Often it is just correlation.

Compounding this is review fatigue. When the AI reviewer leaves fifteen comments on every PR — some sharp, many trivial — humans quickly learn to skim its output. The signal drowns in the noise. After a week of dismissing low-value nits, the engineer stops reading the AI's comments carefully at all, which means the one genuinely important flag in the pile gets dismissed along with the rest. The tool meant to extend human attention ends up eroding it.

The Quiet Erosion of the Approval Signal

There is a deeper cultural cost hiding underneath the technical one. For two decades, an approval on a pull request meant something specific: a named engineer read this change, understood it, and is willing to attach their judgment to it. That signal is what made the pull request a real social contract rather than a bureaucratic step. It is also what made post-incident investigations tractable — when something broke, you could trace back to who reviewed the change and ask what they were thinking.

As AI review becomes the default first pass, that signal degrades unless teams actively defend it. The approval starts to mean "the bot did not complain and a human glanced at the bot's summary," which is a much weaker claim. The danger is that the form of the old contract persists — there are still approvals, still checkmarks, still a merge button — while the substance quietly drains out. Teams that do not notice the difference end up with a review process that looks rigorous on the surface and provides almost no real assurance underneath.

This matters most for the changes where it is least visible. A routine dependency bump or a copy change can ride the weakened signal with no consequence. But the same weakened signal is also applied to the change that touches authentication, alters a migration, or rewires a payment path — and there, "the bot did not complain" is nowhere near enough. The job of a healthy workflow is to make sure the strength of the review scales with the stakes of the change, rather than flattening to the lowest common denominator the automation makes convenient.

The Speed Trap: Faster Merges Are Not Always Better

AI review is often sold on velocity: PRs that used to wait a day for a busy reviewer now get feedback in seconds, and merge throughput climbs. That is a real benefit, but velocity is a seductive metric to optimize in isolation. The point of review was never to be fast; it was to be a deliberate friction that catches problems before they reach production. Strip out too much of that friction in the name of throughput and you have simply moved the cost of the missed bug from review time to incident time — where it is an order of magnitude more expensive to pay.

The healthiest teams treat the time AI review saves as a budget to reinvest, not a pure win to bank. The hours reclaimed from mechanical review get spent on the deeper questions a human is uniquely equipped to ask. Velocity goes up where velocity is safe — small, reversible, well-tested changes — and stays deliberate where it should, on the changes that can take the whole system down. Used that way, AI review buys back attention rather than spending it.

The Healthy Workflow: Maker-Checker at the Gate

The fix is not to abandon AI review — the volume problem is real and the mechanical coverage is genuinely valuable. The fix is to design the workflow so that the AI reviewer is positioned as anindependent, adversarial checker rather than a second voice from the same choir. This is the maker-checker pattern, and it is the same discipline we argue for across agentic systems in our deep dive on the maker-checker pattern keeping AI in production. The maker produces; an independent checker, explicitly prompted to find fault, scrutinizes; and a human holds the gate where the stakes demand it.

Three design principles separate a healthy AI-review workflow from a rubber-stamp loop. First, the checker must be adversarial by construction — prompted and tuned to hunt for problems, not to summarize agreeably. A reviewer whose job is to find the strongest case against the change behaves very differently from one asked whether the change looks fine. Second, the checker should be independent — ideally a different model, a different prompt lineage, with different context, so its blind spots do not perfectly overlap the author's. Third, the human stays in the loop in proportion to reversibility: a typo fix can merge on AI approval; a change to the auth path or a payment flow gets a human who is accountable for it.

The Human's Job Changes, It Doesn't Disappear

In this model the human reviewer's role shifts up the stack. The mechanical pass — style, obvious bugs, missing tests, summary of what changed — is handled before they arrive. What remains is the part that was always the hardest and most valuable: does this change belong in the system? Does it respect the boundaries the team has invested in? Is the author solving the right problem? Is there a security implication that only makes sense in the context of how this code will actually be deployed and attacked? Those are judgment questions, and judgment is precisely what the AI reviewer cannot supply.

Done well, this is a genuine upgrade. The human stops spending attention on null checks and starts spending it on architecture. The AI absorbs the volume that would otherwise have crushed the queue. And the maker-checker structure ensures that the approvals stacking up on a PR represent real, independent scrutiny rather than the comfortable echo of two models agreeing with each other.

Conclusion: The Gate Is Only as Good as Its Independence

AI code review is eating the pull request, and on balance that is a good thing. The volume of machine-authored code is not going back down, and a tireless reviewer that reads every diff and summarizes it for a human is a real productivity gain. CodeRabbit and its peers earned their place at the gate by solving a problem — review throughput — that humans alone could no longer solve.

But a gate is only as good as the independence behind it. The moment an AI reviews the work of an AI and a human waves the result through, the review has become theater. The teams that get this right treat AI review as one half of a maker-checker loop: an adversarial, independent checker that catches what it can, feeding a human who owns the judgment calls that matter. Keep the checker honest and the human accountable, and AI review makes the pull request stronger. Let two models rubber-stamp each other, and it quietly makes it weaker while everyone admires the green checkmarks.