We all became reviewers — so who actually reviews?

The bottleneck moved

AI collapsed the cost of writing code, not the cost of being sure it's right. Around 90% of engineers now use AI at work, pull requests are roughly 18% larger, and the constraint has moved from writing to verifying.

Our processes assumed humans write at human speed. When output outgrows verification capacity, either the queue backs up or people start rubber-stamping. Most teams are quietly doing the second.

The accountability gap

The author's job already became a reviewing job — but the process still pretends the author is a writer and the reviewer is the safety net. So the AI writes it, the author skims because someone is assigned to review, and the reviewer skims because surely the author understood their own change. Two shallow reviews, zero deep ones.

Two effects make it worse. Automation bias, where vigilance drops after a few good experiences. And what Simon Willison calls normalization of deviance — every time unreviewed AI code works, skipping verification feels a little more acceptable.

What the data says

GitClear, looking across 211 million changed lines, found duplicated code blocks up eightfold in 2024, and code rewritten within two weeks rising from 5.5% to 7.9%.

DORA 2025 ties it together: AI raises throughput and instability at the same time. It behaves as an amplifier — strong teams get better, weak controls get exposed.

What worked at Intercom

Intercom published their numbers in April 2026: 93% of pull requests agent-driven, 19% auto-approved with no human in the loop, and AI-authored backend code reverted at 0.53% against 5.39% for human-authored. Roughly tenfold better.

The headline sounds reckless. The implementation is conservative:

• Review is split across specialist sub-agents — intent match, safety, logic, best practices.
• The agent traces execution paths humans rarely have time to follow.
• Oversized PRs are rejected outright.
• Every approval is labelled, logged and audited; they involved their SOC 2 auditors before scaling.
• The engineer who ships still watches it in production.

Five rules for authors: the PR contract

1. Write the intent before generating, and put those one or two sentences at the top of the PR. You can't check a diff against an intent that was never articulated.
2. Attach proof. Tests run, manual steps, screenshots, logs. No evidence, no review.
3. Respect a size limit. The OCaml maintainers rejected a 13,000-line AI PR not because it was bad, but because it was unreviewable.
4. Guide the reviewer. Name the one or two places you actually want human judgment.
5. Never submit code you can't explain. If on-call can't get an explanation from you at 2 AM, knowledge transfer is broken.

Plus one thing across all five: disclose what the AI generated, and with what context. Provenance lets reviewers calibrate instead of guess.

What organizations should change

Uniform review causes rubber-stamping — when everything needs the same sign-off, everything gets the same glance. Tier by risk. Auth, payments, secrets and untrusted input get a mandatory human threat-model review. Genuinely low-risk changes can be AI-reviewed alone, provided the approval is logged and a named human still owns the merge.

Run AI as the first pass and humans as the last. Then measure it: review time per changed line — AI PRs carry around 1.7× more defects, so equal review time means scrutiny has quietly collapsed — plus post-merge churn and occasional explain-the-diff spot checks.

The reviewer's role

Stop competing with machines at pattern matching. Style, common bugs and first-pass security scans are the tool's job. What stays human: does this match the actual intent, is the architecture one we want to live with, and what's the blast radius?

Don't try to be a better linter than the AI. Be more human than it.

Where this goes

Is code review becoming redundant? The ceremony is; the function isn't. Verification is being redistributed — into the author's workflow, into review agents, into CI evidence, into production monitoring. The invariant worth protecting isn't the review step. It's a named human owner on every change, enforced by tooling rather than policy.