The Code Review You Approved in 90 Seconds — and Why That's Worse Than Skipping It

Day 4: The Rubber Stamp That Feels Earned

Review was never about catching every bug. It existed so a second brain had to touch a change before it went out. Agentic coding didn't remove that check — it did something sneakier. It made the check feel satisfied when it wasn't. And a review that feels done but isn't is more dangerous than a review everyone knew was skipped, because nobody's watching for it.

The moment you approved without reading

You open a PR an agent wrote start to finish from a ticket. 380 lines, clean structure, tests included, a commit message that reads like documentation. You scroll it once, at reading speed, not audit speed. Nothing snags, so you hit Approve. Here's the thought that made it feel fine instead of lazy: 'if this were wrong, it would look wrong.' That sentence is the whole failure mode. It's a claim about correctness dressed up as an observation about style.

Two rubber stamps, two different mechanisms

Rubber-stamping isn't new. The old version came from laziness or a deadline — you typed 'LGTM' on a colleague's diff because you trusted the person, not because you'd checked the logic. Everyone knows this failure. Every org has a postmortem line about it and a manager who's given the lecture. It's nameable, which means it's correctable.

The new version shows up dressed as something more responsible: calibrated trust. 'This agent has nailed the last twenty PRs like this' feels like evidence. But you have no error bars on that. No confusion matrix, no held-out set, no idea what fraction of 'looks right' diffs from this agent, on this codebase, at this size, actually are right. You're pattern-matching on a small, biased sample and calling it calibration. That's worse than admitting you didn't read it — because it doesn't feel like skipping a step. It feels like doing the step well.

Where compute vs. attention stops being abstract

This series keeps circling one distinction: compute is cheap now and scales on demand, attention doesn't. Review is exactly where that stops being a slide and starts being a broken workflow you can point at. Agents can plausibly turn out several times the diff volume a team used to produce, same headcount, same hours. The exact multiple depends on the team, but the direction never flips. If review-attention supply is flat while diff demand climbs like that, per-diff attention has to collapse — whether or not anyone decided that on purpose, and whether or not anyone notices it happening.

The concrete, checkable tell

Rubber-stamp v1 looks like: 'LGTM' on a 40-line human diff, maybe a nitpick about a variable name. It's visible as corner-cutting even to the person doing it.

Rubber-stamp v2 looks like: 'LGTM' on a 400-line agent-authored diff, zero substantive comments, approved minutes after the push. And this one's falsifiable — go check your own repo. Pull the last 30 days of merged PRs, plot time-to-approve against diff size, split the points by whether the PR was agent-authored (label, commit trailer, whatever signal you've got). If the classic pattern holds, approval time should climb with diff size. If the line's flat — if a 400-line agent diff gets waved through as fast as a 20-line one — that's v2, sitting in your own history, not a hypothetical someone's warning you about.

Why this is worse, not just different

Old rubber-stamping had a brake built in. Code written under deadline pressure by a tired human usually looks like it — awkward names, missing tests, a commit message that's one word. Those are visual tells, and even a reviewer who wants to skim will flinch and slow down a little.

Agent-authored code deletes that tell. It's stylistically consistent, ships with tests, has a commit message that reads well — none of which tells you anything about whether the logic underneath is right. Confidence of presentation is now fully unhooked from correctness of reasoning, and presentation is the thing your eyes actually check when you skim. The brake is gone precisely because the output looks like the kind of code that used to earn scrutiny-free trust for good reasons.

What actually gets attention back

'Read every line' doesn't scale. It's the same trap as the old 'review everything' — just shouted louder now that there's more to read. What scales is spending a fixed attention budget on purpose instead of pretending the gate is a binary switch.

• ▹Sample depth by blast radius, not by diff size or who wrote it: changes touching auth, payments, migrations, or anything irreversible get full-line review; internal tooling tweaks get a skim, on purpose, as a decision you made rather than one that happened to you.
• ▹Make the author-agent flag its own uncertainty inline — a note on the lines it's least sure about — so your attention routes to the risky 20% of the diff instead of getting spread thin and even across all of it.
• ▹Treat review time as a budget per PR, not a pass/fail gate: decide up front 'this one gets eight minutes of real attention,' spend it where uncertainty and blast radius overlap, and accept you won't get full coverage. You never actually had it — you just used to feel like you did.

The throughline

Attention burned on a fake-thorough skim doesn't come back later. You can't recover it in the incident review after the bug ships — by then the cost has already moved from 'minutes in review' to 'hours in production.' Tomorrow builds straight off this: the next 26 days keep circling the same question, and it was never whether you trust the agent. It's where you're choosing to spend the one resource that doesn't scale with it.

Extend your knowledge

• ▹Pull your own repo's PR history for the last 30 days and plot review time (or time-to-approve) against diff size, split by whether the PR was agent-authored — check whether the curve has flattened.
• ▹Check how your team currently marks agent-authored PRs (label, commit trailer, description text). If you can't tell which PRs were agent-written, you can't sample review depth by that axis at all.
• ▹Read up on confidence calibration in ML (Brier score, reliability diagrams) — the same framing applies to checking whether your trust in an agent's output is actually calibrated or just a feeling.
• ▹Add a required 'uncertainty note' field to your PR template for agent-authored changes, and watch whether reviewers actually use it to route their attention.