AI Code Review Is the New Bottleneck, and the New Control Point

On July 9, PostHog published a post with a title every engineering team feels in its bones: "Stop being the code review bottleneck." Their own review agent, StampHog, already gives the final stamp on roughly 1 in 3 pull requests merged into their main repository, and handled 1.6K of them on its own last month.

A pull request (PR) is the unit a change ships in, and the advice lands because the pain is real.

But the same month produced a second finding that reframes the first. Read together, they say something sharper than "get out of the way." They say the thing you are being told to shrink is the one place your leverage now lives.

Why is code review the bottleneck in AI-assisted development?

Because generation stopped being scarce and judgment didn't. When a machine writes faster than a person can read, the queue stops being about producing code and starts being about deciding whether it merges. The slow step moved downstream, from the keyboard to the review.

The clearest measurement comes from a Carnegie Mellon and Stanford team that studied 802 developers and 196,212 pull requests at a company operating under an explicit "2x productivity" mandate. Per-capita throughput reached 2.09x baseline, while the load on each reviewer roughly doubled and automated review overtook human review. Merge and revert rates held steady. AI writes faster than humans can review, and the bottleneck genuinely relocated.

One honest caveat travels with that number. The authors are careful: adoption was not randomized, it is a single AI-forward company, and pull request throughput is a proxy for output, not a clean measure of value. The direction is credible; the precise multiple is one company's story.

Do developers review AI-generated code differently than human code?

Yes, and in the wrong direction. The code whose origin should invite the most scrutiny is getting the least. A Carnegie Mellon team read 3,100 practitioner posts and discussions and built them into a causal theory of review in an AI world, and the pattern it surfaced is uncomfortable.

Agent-authored pull requests receive lower review rates, faster merges, and less discussion than human-authored ones. The same study lands on a sentence worth pinning up: code review is the control point through which a coding agent's effect on software is decided. Not a queue stage to be minimized. The control point.

There is a perception trap underneath this, and it is the least reliable instrument in the building right now: how fast the work feels. Developers routinely report feeling faster with AI than controlled measurement shows them to be, which is the same felt-versus-measured gap we traced in the deskilling debate. "It looked fine" is not evidence, and it is exactly the standard a relaxed review applies.

Should you automate code review with AI agents?

Partly, and the line between the two halves is the whole game. Automating the toil of review is real relief. Automating the judgment is abdication dressed up as efficiency. The trick is knowing which is which before you wire it up.

Start by giving the automation its due. Routine review genuinely is toil, and an agent handling low-risk diffs removes a real tax: StampHog's 1.6K PRs in a month are 1.6K interruptions that never reached a person. One PostHog engineer, Paul D'Ambra, is happy about the trade.

That is delegation, and it is good engineering. The failure begins when the same reflex reaches the decisions that carry consequence. The question is never "human review or agent review." It is which decisions still require judgment, and who owns them. Deciding what is safe to merge is the scarce human act now, the same way verification, not generation, became the real discipline.

Does AI-generated code hurt software quality?

The measured picture is calmer and more precise than the fear. A study of 13,360 AI chat sessions linked to commit histories across 1,356 open-source repositories found that agent adoption widened participation, lowered contributor concentration, and produced no broad measured drop in code quality or merge rates. The machines are not salting the codebase.

The one asymmetry the study did find is about trust, not quality. Developers perceive other people's AI code as harder to maintain, even when the aggregate numbers do not bear that out. So the real risk is not that AI code is inherently worse. It is a process risk: review discipline relaxes while volume doubles.

This is the builder's leverage relocating, not vanishing. When everyone and every agent can produce the code, the checks that used to live between roles don't disappear, they move into the review surface. Whether that surface holds is now a design decision.

How should teams restructure code review for AI-written code?

Redesign it around judgment at throughput, rather than abandoning it. The encouraging part is that the best advice in the "automate review" camp already points here. PostHog's strongest recommendation is to decompose large agent changes into small, observable, testable units instead of trusting agent reasoning wholesale. Read closely, that is review redesign, not review removal.

Four disciplines make the control point hold when volume doubles. They are ordered from structural to cultural, and each one is enumerable and testable on your own team:

• Route review by risk, not by queue order. Send routine, low-consequence diffs to automated review; reserve human attention for changes that can hurt.
• Decompose agent work into judgeable units. A 2,000-line change no one can evaluate is not reviewed, it is waved through.
• Measure outcomes, not felt speed. Track what actually shipped and held, because felt velocity is the instrument that lies.
• Keep a named human owner for every high-consequence merge. Steady merge-and-revert rates today are a lagging indicator, not a guarantee.

The bottleneck always was judgment. AI just made it visible by removing everything around it. Teams that automate the toil and keep the judgment get compounding speed. Teams that automate both will learn which pull requests needed a human, one incident at a time.