Code Review Is Not Dead. It Is Becoming Governance.

There is a growing argument in the engineering world that code review is dead. The reasoning goes like this: AI agents generate code faster than human reviewers can keep up, so the answer is to move oversight upstream to specifications and replace human judgment with layers of automated verification. A widely read essay on Latent.Space made exactly this case in March 2026, proposing five layers: competing agents, deterministic guardrails, BDD acceptance criteria, permission scoping, and adversarial verification.

The diagnosis is right. The volume problem is real, and it is not going away. But the prescription does not follow from the evidence, and the framing matters more than it seems. What this school of thought describes as killing code review is really rebuilding governance with different vocabulary.

The Swiss Cheese Problem

The kill-review argument often cites James Reason’s Swiss cheese model of accident prevention, and that is a good instinct. Reason’s model is one of the most durable ideas in safety engineering. The core insight: no single layer of defense is perfect. Every layer has holes. Safety comes from stacking imperfect layers so the holes never align.

Then the argument asks us to remove a layer.

The five automated layers are presented as superior to human review. But Reason’s model does not say “replace weak layers with better ones.” It says “add more layers, because you cannot predict where any single layer will fail.” The entire intellectual foundation of the Swiss cheese model argues against reducing the number of verification surfaces.

That is not a minor inconsistency. It is a thesis contradicting its own framework.

Read the Whole Dataset

The strongest evidence cited for killing review comes from a Faros.ai study of more than 10,000 developers across 1,255 engineering teams. The productivity numbers are impressive: +21% task completion and +98% PRs merged with high AI adoption.

The same report also found +9% bugs per developer and +154% average PR size with high AI adoption. And its headline finding cuts the other way entirely: no significant correlation between AI adoption levels and company-level performance improvements. More AI usage did not translate to better outcomes at the organizational level. More PRs did not mean better software. It meant more code to govern.

LinearB’s benchmarks tell the same story from another angle. Across 8.1 million pull requests analyzed, AI-generated PRs showed a 32.7% acceptance rate versus 84.4% for manual PRs, and AI code waited 4.6 times longer to be reviewed. Human reviewers are already treating AI code with caution. Removing the scrutiny layer does not resolve that lack of trust. It only hides it.

What Code Review Actually Does

The case for killing review rests on a narrow definition of what review accomplishes: bug-finding. If automated tools find bugs better, and in many categories they do, then human review looks redundant.

That misses most of the picture. A 2024 Springer study of code review practices found that three quarters of defects identified in review affect evolvability and maintainability, not functionality. Design coherence. Naming conventions. Architectural consistency. Coupling between modules. Technical debt accumulation. These are the concerns that determine whether a codebase remains workable in six months or becomes a system nobody wants to touch.

None of the five automated layers address evolvability. Competing agents verify functional correctness. Deterministic guardrails enforce rules. BDD tests confirm behavior. Permission scoping limits blast radius. Adversarial verification probes for edge cases. All of these target “does it work right now?” None of them ask “will this codebase still be comprehensible in a year?”

Review also serves functions that have nothing to do with defect detection: knowledge transfer across the team, mentoring junior engineers, building shared understanding of system architecture, establishing coding norms. These are organizational functions. No automated layer replaces them.

When AI Writes the Tests Too

The BDD layer deserves a closer look, because the argument leans on it hard: define behavior specifications upfront, then verify generated code against those specs automatically.

There are two problems. First, academic research on BDD at scale is thin. A 2021 ScienceDirect review found that empirical evidence of BDD’s usefulness in large-scale projects is missing. BDD works well for well-defined, bounded behaviors. Enterprise systems full of complex state interactions and cross-cutting concerns are a different challenge.

Second, and more fundamental: when AI generates both the implementation and the tests, passing specs do not guarantee correct software. Simon Willison raised exactly this concern. If the same model produces the code and the verification, you have correlated failure modes. A systematic bias in the model will produce code that is wrong in exactly the way the model’s tests expect.

The calibration problem runs deeper than tooling. METR’s randomized controlled trial with experienced open-source developers found that AI assistance made them 19% slower, while those same developers believed they were 24% faster. If humans cannot accurately judge the quality of what they produce with AI, transferring the judgment entirely to AI agents does not solve the calibration problem. It removes the last independent observer.

What Actually Works

The volume problem deserves a real answer, and “review everything the old way” is not it. The answer is governed review: risk-based triage that directs human attention where it matters most.

Automated pre-screening. Let automated tools handle the categories they are good at: style consistency, known vulnerability patterns, test coverage, type safety. This layer works, and every team should have it.

Risk-based routing. Not all changes carry equal risk. A CSS tweak and a payment processing change should not go through the same review process. Security-sensitive code, data-handling logic, and architectural changes get thorough human review. Low-risk changes get automated verification with spot-check sampling.

Architecture review, not line review. Human reviewers should spend less time on individual lines and more time on design decisions, system boundaries, and integration patterns. This is where human judgment remains irreplaceable, and it is where the 75% evolvability value lives.

Verification independence. When AI generates code, the verification layer must be genuinely independent: human reviewers, separate models, or formally specified properties. Never the same system checking its own work.

This approach does not kill anything. It allocates human attention efficiently within a governed framework. The review process changes shape. It does not disappear.

The Name Matters

You could argue this is all semantics. Call it spec review, call it verification layers, the old process evolves either way. But naming matters. When engineering organizations hear “code review is dead,” some of them will hear “we do not need oversight.” They will cut review investment. They will skip architectural review because the agent passed its own tests. They will ship faster, and the damage will stay invisible until the codebase becomes unmaintainable and the institutional knowledge has evaporated.

The Faros.ai data already shows this pattern forming: more code, more PRs, more bugs, longer reviews, and no improvement at the company level. That is what killing review looks like in practice.

Code review is not dying. It is becoming governance, and it deserves to be treated as such: with clear ownership, human judgment at the points of highest risk, and honest measurement of whether each layer, human or AI, is actually earning its place. Teams that keep investing in the review layer, and keep measuring it, are the ones that get to move fast with trust instead of hope.

If you are curious how effective your review layer really is today, for human and AI reviewers alike, discover what a code review effectiveness metric can show you.