Who owns correctness when review volume outpaces human reviewer bandwidth and code starts merging unread?

The shift

AI makes generating plausible, syntactically clean, test-passing code abundant and near-instant — so the volume of diffs arriving at the review gate grows far faster than human reading speed does. Review used to throttle naturally because writing code was the bottleneck; now writing is fast and reading is still exactly as slow as it always was, so the gate is the only thing left standing between output and production, and it's the one thing AI hasn't sped up.

The axioms

• A human reads every line before it merges. Rests on the assumption that diff volume stays within a reviewer's daily reading capacity — code arrived at roughly the rate a team of humans could produce it.
• Passing CI plus one approval means the code is correct enough to ship. Rests on the approval being a genuine signal that a competent person examined the logic, not just clicked a button — scarce human attention converted into a scarce, meaningful signal.
• The author understood what they wrote, so they can answer for it under questioning. Rests on authorship implying comprehension — the person who typed the code held a mental model of it.
• Review is where bugs, security holes, and bad architecture get caught before production. Rests on review being the cheapest point to catch defects — cheaper than catching them after they ship.
• A reviewer's approval is a reputational and professional bet — they'd catch flak for rubber-stamping something bad. Rests on the reviewer's judgment being scarce and personally accountable, not a formality.

Invalid axioms

1. A human reads every line before it merges. AI made draft-code generation abundant while human reading speed stayed fixed, so "read everything" silently became "read what you have time for." The habit-trap: teams still staff review as if one senior engineer's eyeballs are the throughput ceiling, instead of redesigning the gate around what's actually scarce now — verified correctness, not eyeball-seconds. Pretending the old ritual still functions at 10x volume is worse than admitting it broke.
2. The author understood what they wrote, so they can answer for it. When a large share of a diff is agent-generated and accepted with light editing, authorship no longer implies comprehension. The habit-trap: assigning blame and follow-up questions to "whoever's name is on the commit" as if that still locates the person who can explain the change.
3. Passing CI plus one approval means the code is correct enough to ship. That signal was only meaningful when producing a plausible-looking diff was itself hard, so getting past CI filtered for competence. Now a model can produce a fluent, test-passing, wrong diff on the first try — confidently wrong is the default failure mode — so the same gate that used to mean something now passes garbage at the same rate it passes good code.

Unchanged axioms

1. Someone is accountable when the code is wrong in production. A model can't be fired, sued, or asked to explain itself in a postmortem. Whoever merges, or whoever's org merged, still eats the outage, the security incident, the compliance failure. AI hasn't found an owner for this — it just increased the odds that the owner didn't actually check.
2. Judgment on novel, high-stakes changes has no shortcut. AI review tools pattern-match against code they've seen; they're weak exactly where the stakes are highest — a new payment path, an unusual concurrency pattern, a security-sensitive boundary. A human still has to decide whether this specific change, in this specific system, is safe, and that judgment doesn't scale with compute.
3. Trust between teams is built on reviewers actually looking, not on the existence of a review step. If engineers learn that approvals are rubber-stamps, they stop trusting the green checkmark, and the whole point of having a gate — letting people build on each other's work without re-verifying it themselves — collapses. That trust has to be earned by real scrutiny; a fast model can't manufacture it by proxy.

New axioms

1. What does "reviewed" mean when the reviewer is also an AI, or an AI pre-filters what a human even sees? If an AI system triages, summarizes, or pre-approves diffs before a human glances at them, the record of "who looked at this" gets murky — nobody has solved what a defensible audit trail looks like when review itself is partly automated.
2. How do you calibrate trust in an AI reviewer whose false-negative rate is unknown and drifts as the codebase and model both change? Confidently-wrong AI review is worse than no review, because it removes the felt need for human scrutiny while providing none of the actual protection — and nobody has a reliable way to know, in production, how often that's happening.
3. What happens to the ability to debug or extend code six months later when nobody — author or reviewer — ever built a mental model of it? Correctness at merge time isn't the only thing at stake; comprehension debt compounds silently until an incident forces someone to reconstruct understanding of code no human ever really held in their head.
4. Who absorbs the volume the old process was never sized for — do orgs hire more reviewers, build new automated gates, or quietly let bar drop? The instinct is to add AI-assisted review to keep pace, but that just relocates the confidently-wrong-by-default problem one layer up without addressing who is actually accountable when that layer misses something.

Where it breaks

The collision is direct: teams keep the old "approval means someone checked" signal (INVALID) running on autopilot precisely because nobody has built a replacement audit trail for partially-automated review (NEW #1). The green checkmark still gates deploys, but it no longer means what it used to mean, and no new signal has taken its place — so the org is making promotion, security, and compliance decisions on a proxy that quietly stopped tracking the thing it was supposed to measure. The same gap shows up in incident response: when production breaks, the postmortem still asks "who reviewed this" as if that answer locates someone with a mental model of the change (INVALID #2), while the actual comprehension debt (NEW #3) means the answer is often "someone clicked approve, and no one who understands this code is in the room."

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