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 reports patterns in a bounded sample. As a May 2026 preprint, it is useful evidence rather than a universal law. Written intent can give reviewers a clearer reference point, but the study does not prove that review fails or that verification replaces it.

A 2026 Sonar vendor survey reports self-described review behavior and perceptions. It is dated and relevant, but it is not universal production telemetry and does not establish a causal throughput rule.

NIST’s February 2022 Secure Software Development Framework treats peer review, code analysis, and executable-code testing as distinct practices. That is the durable point: combine evidence sources according to risk and record their coverage and omissions. Missing or stale evidence can create verification debt.

Treating either practice as a universal replacement is the wrong abstraction. 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. Define intent and select checks. A spec-vs-implementation check against written intent, plus risk-appropriate static analysis, tests, and other evidence with recorded limits.
2. Review with evidence in view. The reviewer receives the diff plus recorded findings and outcomes, challenges their coverage, and may request another iteration.
3. Human gate last.A designated person accepts or rejects under the team’s decision rights. Review opinion and verification evidence inform that business or release decision; neither makes it automatically.

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.

As a concrete process with steps and roles, this division is described in the two-pass review workflow.

• 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 records one task-relative evidence layer: written task intent before the run, boundary and criteria checks after it, selected validation outcomes and omissions, and an evidence report the reviewer reads before judging. What those checks add up to, one value per run rather than a patchwork of per-tool statuses, follows the rules under how the outcome is computed. It does not prove correctness, security, or compliance and does not make business, legal, or release approval. Your review process and decision rights stay yours.