Step 4: Reviews that try to kill the work

“Please review this” produces compliments and nitpicks. An adversarial review is a different instrument: independent reviewers whose explicit job is to refute the work, followed by a verify pass that tries to kill each finding before you act on any of them.

You’ve met this before. Code review crossed with a red team, plus mutation testing’s founding instinct: a test that can’t fail proves nothing, and neither does a reviewer that can’t refute. Independent passes are the old two-reviewer rule; agents just make N reviewers cost what one used to.

Where this comes from: on a multi-phase foundational build, a per-phase multi-agent correctness review caught real data-loss, panic, and cache-invalidation bugs in code a green test suite had already passed. It earned a standing rule: after each phase of foundational work, review-then-refactor before building the next floor on top.

The shape

Independent passes. Two to four reviewers that cannot see each other’s output. Independence is what makes agreement between them mean something.
Distinct lenses, not clones. One traces correctness on real inputs; one hunts data-loss and failure modes (crashes, partial writes, rollback); one checks the change against what was actually asked. Diverse lenses catch failure modes redundancy can’t.
A verify stage. For each finding, an explicit attempt to refute it against the code. Plausible-but-wrong findings are the tax on agent review; the refute pass is how you stop paying it.
Findings on disk, severity-ordered, scenario spelled out. “This breaks” is a claim; “these inputs produce this wrong output” is a finding (AF-17, AF-02).

Try it

TRY IT The review that refutes

you

Phase 1 of the storage engine is done and tests are green. Review it before we build phase 2 on top.

agent

This is foundational: everything after this sits on it. The review can be a read-through, or it can be structured to attack.

Pick the agent's next move, then see where it leads:

AI've reviewed the phase 1 code: clean architecture, good separation of concerns, idiomatic throughout. Two style nits in the cache layer. Solid foundation, ready for phase 2.

you

Three phases later: the cache returns stale entries after a partial write. Everything above it inherited the bug.

agent

The review read the code as its author intended it. The invalidation path only misbehaves under a write that fails halfway, a case the read-through admired past, because admiring is what a single sympathetic pass does.

the baseline

"Please review" produces compliments and nitpicks. A single pass with no mandate to attack confirms the author's mental model (including its blind spots), and the bug ships into the foundation. AF-02

BSpawning three independent reviewers that can't see each other's output: one tracing realistic inputs, one hunting data-loss and partial-failure modes, one checking fidelity to the spec. Then a verify pass that tries to refute each finding before you see it.

agent

Findings on disk. CONFIRMED: concurrent write to the same key loses one writer's data (reviewer 2; refutation attempt failed: reproduced with a 6-line probe, scenario attached). REFUTED and dropped: reviewer 1's claim that the index desyncs on delete; the lock ordering actually prevents it. One suspected: cache invalidation on partial write, needs a fault-injection run I couldn't do. Not covered: the compaction path.

you

Fix the confirmed one, run the fault injection for the suspected one, then we build phase 2.

correct

Independent lenses found what sympathy can't, the verify pass killed a plausible-but-wrong finding before it wasted anyone's time, and the review states what it didn't cover: findings you can act on, with the confidence labeled. AF-17 · AF-18

CGreen is good but thin. I'll strengthen the test suite: 30 more unit tests across the modules, all passing. Coverage is now 94%.

you

94% and the stale-cache bug still shipped. How?

agent

The new tests encode the same assumptions the code does. I wrote both. Coverage measures which lines ran, not which beliefs were challenged. The partial-write case wasn't in the code's mental model, so it wasn't in the tests either.

plausible but wrong

More green is not review. Tests written by the code's author (human or agent) share the code's blind spots; a review exists precisely to bring assumptions the author didn't have. AF-05

When to run it

After each phase of foundational or multi-phase work: the standing rule above.
Before merging anything an agent built while you weren’t watching (overnight runs, background tasks; see step 5).
Any time green tests are the only evidence you have. Tests prove what they test; the review hunts what they don’t.

Or paste this into Claude

Run an adversarial review of the current diff (or the directory I
name). Spawn three independent reviewers that cannot see each other's
output: one for correctness (trace realistic inputs through the
changed paths), one for data loss and failure modes (crashes, partial
writes, rollback, concurrent access), one for fidelity to the request
(does this do what was asked, no more, no less). Each returns concrete
findings with file:line and the failing scenario. Then run a verify
pass: for each finding, try to refute it against the actual code, and
drop anything you can't confirm. Report only confirmed findings, most
severe first. State what the review did NOT cover. Don't fix anything
yet: findings first, fixes on my pick.

Watch out

Skipped verify stage: raw reviewer output includes confident fiction. Never batch-apply unverified findings.
Coverage theater (AF-18): a review that sampled three files reads identically to one that read the codebase, unless disclosure is demanded. “State what you did not cover” is the part that matters.