Code Review vs. Verification

Code review earns its place three ways: it transfers knowledge, it catches design problems a compiler never will, and it keeps a second pair of eyes on everything that ships. All three assume something quietly: that reading capacity roughly matches writing speed. For twenty years it did – a reviewer reconstructed the author’s intent from the diff, the commit message, and a shared context, and usually got it right.

That reconstruction step is the part that breaks with AI. The author of the change is a model whose “intent” lived in a prompt that is gone by review time, and research on how humans actually review AI-generated pull requests shows reviewers falling back on surface signals when intent is missing. Review keeps judging quality; it silently loses the ability to judge correctness against intent.

The volume shift is measured, not hypothetical. A Faros AI telemetry study across 10,000+ developers in 1,255 teams found that high-AI-adoption teams merge about 98% more pull requests – while review time per PR rises by 91%. More code, and each unit of it harder to review: 38% of developers say reviewing AI code takes more effort than reviewing a colleague’s.

Quality data points the same direction. Industry analyses collected in 2026 review-standards guides put AI-authored PRs at roughly 1.7x the defect rate of human PRs, with 45% introducing at least one OWASP-Top-10 issue. A reviewer facing double the volume with subtler failure modes has two exits: rubber-stamp, or become the bottleneck. Both are forms of verification debt.

The maximalist take – “code review is dead” – draws the right diagnosis and the wrong cure. Removing humans from the loop discards the judgment layer that no check can provide, and it ignores what review does for the team’s shared understanding. The division that works in practice:

1. Verification first, per change. A spec-vs-implementation check against written intent, validation the model did not author, and a recorded result.
2. Review second, on verified changes. The reviewer receives the diff plus the verification outcome – and spends their attention on architecture, trade-offs, and the questions a checklist cannot ask.
3. Human gate last. A person accepts or rejects, with evidence in view. Verification informs the decision; it never makes it.

The reviewer’s job changes from “reconstruct what this was supposed to do” to “judge whether it is good” – which is the job review was always best at. This split is the heart of the broader verification loop.

• Dropping review entirely. Verification checks stated intent; it has no opinion on whether the intent was wise. That judgment is the reviewer’s.
• Treating AI review tools as verification. An AI reviewer without a written intent is another opinion, not a check. Useful for the mechanical backlog – not a reference point.
• Keeping review time constant and calling it progress. If AI PRs get the same minutes as human PRs despite subtler failure modes, the process is optimizing for throughput over certainty – measure both.

Reality Graph builds the verification half of this division: written task intent before the run, boundary and criteria checks after it, validation the model did not author, and an evidence report the reviewer reads before judging. Your review process stays yours.