Step 4: Reviews that try to kill the work

“Please review this” often produces general approval and small style notes. An adversarial review asks a sharper question: How could this work fail? Several reviewers inspect the change independently from different angles. Then a separate pass checks whether each reported problem is real before anyone edits the code.

This combines familiar practices: code review, red-team thinking, and the rule that a test must be capable of failing. Agents make it cheap to run several independent passes. Independence matters because two reviewers who share an answer are not two sources of evidence.

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.

Four parts

Independent passes. Use two to four reviewers that cannot see one another’s output.
Different questions. One traces realistic inputs, one looks for data loss and failure recovery, and one checks whether the change matches the request.
Verification after review. Try to disprove every finding against the actual code. Agent reviewers can sound certain about a problem that is not there.
Concrete findings saved to disk. “This breaks” is a claim. “These inputs produce this wrong output at this line” 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.

Try it with your agent

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

Unverified review output: reviewers can be wrong. Never batch-apply findings before checking them against the code.
Hidden limits (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.