The New Code Review

A senior engineer opens her review queue on a Monday and finds eleven pull requests, four of them agent-authored, one a five-hundred-line database migration written overnight. The old queue used to have a texture she could feel her way through — a typo here, a missing null check there, an off-by-one that jumped out after enough years of looking. This queue does not have that texture. The migration compiles. It passes lint. It passes the tests the same agent wrote for it. She still has to decide whether to approve it, and the part of her job that used to tell her how has gone quiet.

That quiet is not a personal failing and it is not a tooling gap waiting on a firmware update. It is what happens when the cheapest part of writing software gets radically cheaper and the rest of the job does not automatically follow. This chapter is about what is left for a human to do at the review desk once that has happened, and about the two ways teams are trying to do it: with a second AI in the loop before the human ever opens the diff, and with better data about where the review clock is actually going.

The number this volume keeps returning to

This volume opened with a mismatched pair of numbers: teams using AI completing roughly 21% more tasks and merging nearly twice as many pull requests — about 98% more — while code review time grew about 91% and organization-level delivery metrics stayed flat, in a 2025 analysis spanning more than ten thousand developers. That figure has been cited repeatedly across this Library because it is the clearest available fingerprint of where generation gains get absorbed rather than realized. It is worth returning to here because the same research firm has since updated the picture, and the update does not describe a bottleneck stabilizing. It describes one still accelerating.

A later telemetry pass from the same analysis, run across roughly 22,000 developers, found median time in PR review up 441% against its earlier baseline, alongside bugs reported per developer up 54% and incidents per pull request up roughly 243%. Delivery metrics, again, were reported as largely flat. Whatever is happening in that gap between merged output and shipped value, it is not a one-time adjustment period that review is working through. It is a widening one.

The reframing that is only half true

The comfortable version of the argument goes like this: when a human wrote every line, review absorbed a lot of work that had nothing to do with judgment — catching typos, a misplaced semicolon, a loop bound that was off by one. An AI rarely makes those mistakes, the reasoning goes, so that portion of review’s old job has simply evaporated, freeing reviewers to spend their attention on the things that actually require a human — whether the change solves the right problem, whether it fits how the team actually builds things, whether it introduces a risk nobody bothered to name because the model had no way to see it. Free up the low-value work, spend more time on the high-value work. Tidy.

Half of that is simply correct and always was: a compiler, a type checker, and a linter catch syntax and formatting problems better than a human eye ever did, and that was true before any of these tools had a language model behind them. AI did not create that reallocation; it just made the tooling universal enough that almost nobody argues about it anymore. The other half of the argument — that AI is also more reliable at reasoning, so review can retreat from correctness the same way it retreated from style — has not been earned. CodeRabbit’s own analysis of its review data found logic and correctness problems 75% more common in AI-authored pull requests than in human-authored ones. The mechanical layer of review really did get cheaper. The judgment layer did not get lighter to match — if anything it got more exposed, because code that compiles and passes its own tests now arrives looking finished in a way that has very little to do with whether it is right.

What that leaves for a human reviewer is narrower than "everything that isn’t syntax" and more specific than "use your judgment." Three questions do most of the actual work, and none of them are answerable from the diff alone. Does this solve the problem the ticket was actually written to solve, or does it solve a plausible-sounding adjacent one — the difference between a right answer and a right-shaped answer, which an agent has no structural way to tell apart. Does it fit how this particular team builds things — the conventions, the layering, the places where the "obvious" approach is the one the team deliberately moved away from two years ago for a reason nobody wrote down. And does it introduce a risk the model had no way to recognize as a risk at all: a regulatory constraint, a security posture decision, a piece of business context that lives in someone’s head and nowhere in the repository.

What review checks now

Reviewing AI code with AI

The second shift is procedural rather than conceptual: putting a second, distinct model between the agent that wrote the code and the human who has to decide on it — a first pass that flags the mechanical issues, drafts a summary of intent, and surfaces the places most likely to need a careful human look, before the reviewer ever opens the diff cold. Addy Osmani frames the resulting workflow plainly: one AI writes the code, a different AI reviews it, and the human orchestrates the fixes rather than reading raw output first. This is not a new mechanism invented for the review desk. It is the LLM-as-judge and adversarial-verification techniques this volume covered in Chapters 3 and 4, applied to the specific artifact of a pull request instead of a general claim — one model checking another’s work, with the human positioned to arbitrate rather than to read everything cold.

Whether that first pass is worth anything comes down to a question with an unusually direct precedent. Google once deployed a bug-prediction algorithm across its own codebase and found, after rollout, no identifiable change in developer behavior at all — engineers simply did not act on the flags. The researchers traced the failure to two properties the tool lacked: the output was not actionable — knowing a file was "bug-prone" did not tell anyone what to do about it — and it was not explicable, so a flagged file read as a plausible false positive rather than a finding worth trusting. An AI first-pass reviewer inherits exactly that risk. A comment that says a function looks wrong without saying why, or flags a pattern without connecting it to a concrete failure mode, gets the same treatment the bug predictor got: ignored, quietly, forever. CodeRabbit’s framing of the underlying bottleneck — that the hard part of review was never reading the diff but reconstructing the intent behind it — applies here with force. A first-pass AI reviewer that cannot reconstruct and state that intent is not saving the human any of the work that actually costs time.

A flag nobody acts on is not a review. It is a notification the team has already learned to dismiss.

Review-time data, by kind of change

The 91%-then-441% review-time figure this chapter opened with is real and it is also close to useless as a management signal, for the same reason a single average temperature is useless for describing a climate. It blends the ninety-second glance at a one-line config fix with the three-hour sitting a five-hundred-line AI-generated migration demands, and reports the average as if it described either one. A team watching that number alone cannot tell whether review is scaling in proportion to the work it is being asked to check, or quietly drowning under a handful of large changes it has no separate visibility into. Those are opposite situations and the flat aggregate looks identical either way.

Engineering-metrics guidance converging on this point in 2026 argues for tracking cycle and review time against targets that vary by the size and category of the change, rather than one number for everything — same-day for a small fix, a one-to-two-day window for a typical feature-sized change, three to five days treated as reasonable for a large refactor or architecture-level migration — and for reporting medians and distributions per bucket rather than a single blended mean, since averages hide exactly the tail that AI-assisted volume is stretching.

What to track, bucketed

1. Bucket by change shape before reporting anything. At minimum: trivial diffs, typical feature-sized changes, large AI-generated refactors or migrations, and anything touching auth, payments, or another security-sensitive surface — the last bucket gets a human every time regardless of size.
2. Report medians and tail percentiles per bucket, not one blended average. The tail is where the migrations and the incidents live; a mean buries both.
3. Pair review time with what review actually caught, per bucket. A bucket where review time is climbing and defect-catch rate is flat is not more careful — it is just slower.
4. Watch the trend within each bucket over months, not the level in any one week. The right absolute number varies by codebase; whether a bucket is getting worse relative to itself is the signal worth acting on.

None of this requires new tooling most teams don’t already have. A pull request’s line count and touched paths are already in the repository; the only missing piece is deciding on the buckets and reporting them separately instead of collapsing them for the sake of one clean chart. The teams that will notice review turning into a bottleneck before it becomes an incident are the ones who can already say which bucket is degrading — not the ones who can quote a single review-time number to two decimal places.