Is code review dead now that AI writes most of the diff, or did it just move upstream to spec/plan review?

The shift

Producing a plausible, working-looking diff goes from scarce (an engineer's hours) to abundant (seconds, near-free, and available at unlimited volume) — but whether that diff is correct, secure, and doing the right thing stays exactly as scarce as before. AI moved the bottleneck from generating change to judging it, and pushed the highest-leverage judgment point earlier, to the artifact that scopes what the diff is allowed to do.

The axioms

• Writing code is the expensive step, so review is a cheap check layered on top of expensive work. (scarcity: engineering time to produce a diff)
• A diff is small enough and human-authored enough that a reviewer can hold the whole change in their head. (scarcity: diff volume matched to human reading bandwidth)
• The person who wrote the code understands it best, so review is a second opinion from someone who understands it second-best. (scarcity: deep contextual understanding of one specific change)
• Review is where correctness, security, and architectural fit get caught, because nothing upstream was rigorous enough to catch them first. (scarcity: rigor applied before code exists)
• A reviewer's approval is a real signal because it costs them attention and reputation to give it. (scarcity: reviewer attention as a costly, reputation-bearing act)
• Someone is accountable for what ships, and that someone is a named human who approved the merge. (scarcity: accountability — a person who answers for the outcome)

Invalid axioms

1. Review is a cheap check on top of expensive writing. AI flipped the cost ratio: writing is now the cheap step and reviewing is the expensive one, because diff volume scales with model throughput, not headcount. The habit-trap: teams still staff review as a light "second pass" — one reviewer, a quick pass, rubber-stamp culture — sized for a world where diffs were hand-written and rate-limited by typing speed. That review capacity is now the bottleneck, not the diff supply.
2. A diff is small enough to hold in your head. AI-generated diffs are often larger, touch more files, and are stylistically uniform in a way that hides where the actual risk is concentrated. The habit-trap: line-by-line human review of every AI-authored diff, at the same depth as before, is a losing race against generation speed — reviewers either rubber-stamp to keep up or become the throughput ceiling on the whole team.
3. The author understands the code best. When the author is a model prompted by someone who may not have read the generated implementation closely, "the author understands it best" no longer holds — sometimes nobody does until someone reads it adversarially. The habit-trap: routing review to whoever "wrote" the PR for context, when the human submitter may have only reviewed the spec, not the implementation.

Unchanged axioms

1. Someone is accountable for what ships. A model cannot be liable, fired, paged at 3am, or trusted with the next decision based on how the last one went. This doesn't move upstream — it stays exactly where it was, attached to a human who approves the merge, and if anything the model's fluency makes it easier to approve something nobody is prepared to own.
2. Review catches things nothing upstream can. Specs and plans describe intent; they can't fully predict emergent behavior, subtle concurrency bugs, or how a change interacts with the actual state of a large codebase. However good the plan, some classes of error only exist once code runs against reality — verification against ground truth (tests passing, behavior under load, security scanning) stays a scarce, necessary step that no amount of upstream clarity eliminates.
3. Judgment on novel, high-stakes changes doesn't scale with model throughput. A migration touching billing, auth, or data integrity still needs a human who's seen enough failure modes to distrust a confident-looking diff. AI raises the floor on routine changes; it doesn't raise the ceiling on judgment calls where there's no strong pattern to match.
4. Trust in a codebase is a lagging, earned signal. Whether a team believes a change is safe to ship still depends on track record, tests, and institutional memory — things a plausible-sounding diff or a well-written spec doesn't manufacture on its own.

New axioms

1. Spec/plan review inherits all the volume problems code review just had, plus new ones. If specs become the real gate, teams will generate specs at the same abundant, low-cost rate they generate code — so "review the plan instead" only helps if plan-writing stays scarce. Nothing in the current trajectory guarantees that; agentic tools are already drafting specs, not just code. The open problem: how do you keep the upstream artifact scarce enough to be worth gating on, instead of it becoming just another abundant, skimmable document.
2. A correct-looking diff from a correct-looking spec compounds unverified confidence instead of catching it. When both the plan and the implementation are AI-generated and internally consistent, human reviewers lose the natural friction that used to flag mismatches — the two artifacts agree with each other by construction, not because either is right. Solve for: what independent signal catches an error that's consistent top-to-bottom but still wrong.
3. Review bandwidth is now the throughput ceiling on an entire team, and nobody has resized it. If diff generation is 10-50x faster and reviewer count didn't change, the team's real velocity is capped by review capacity, not coding capacity — but budgets, hiring, and promotion criteria are still built around the old constraint. Solve for: what a review-bound org actually staffs and rewards, if the scarce skill is now judgment-at-volume rather than typing-speed-at-volume.
4. Spec review requires a different, less common skill than code review, at a moment teams are least prepared for it. Reading a plan for "will this behave correctly under ambiguity" is a different, harder judgment call than reading a diff for "does this match the plan" — and most engineering orgs built their review muscle on the latter. Solve for: whether senior engineers can be repositioned fast enough into spec/plan gatekeeping before the diff volume swamps them anyway.

Where it breaks

"Review is a cheap check on top of expensive writing" (invalid) collides with "review bandwidth is now the throughput ceiling" (new): teams that moved the gate upstream to spec review, expecting it to be lighter-weight because it happens earlier, are discovering that spec review at AI-generation volume is its own unstaffed bottleneck — they relocated the traffic jam, they didn't remove it.

Second collision: "the author understands the code best" (invalid) meets "a correct-looking diff from a correct-looking spec compounds unverified confidence" (new). Once the same system drafts both the plan and the implementation, there's no independent party left in the loop who was forced to build understanding by writing either one — the human "reviewer" is now the first person in the entire chain who has to construct understanding from scratch, under time pressure, with no fallback if they don't.

ai-axioms.vercel.app/axioms/engineering/swe-code-review-dead-ai-axioms