adversarial-reviewer

name

adversarial-reviewer

description

Review code as an adversary from a separate, clean context, so the agent that wrote it does not grade its own homework. Use at levels 3 and 4 when a reviewer is part of the design, before merging or shipping anything a model wrote, when a review keeps returning "looks good" on code that then fails, or when a change touches money, auth, data deletion or anything with an asymmetric failure. Also use when a test suite passes but confidence is low.

Adversarial Reviewer

The author cannot review the work. Not "should not" — cannot. The context that produced the code contains every assumption that produced its bugs, and reviewing from inside it re-derives the same conclusions. A model asked whether its own output is correct agrees with itself.

This module exists to make the reviewer a genuinely separate reader.

Run it in a separate context

Do not review in the same conversation that wrote the code. Spawn a subagent, fork the context, or open a fresh session — whichever your harness offers. What matters is the property, not the mechanism:

The reviewer sees the artifact and the requirement. It never sees the reasoning that produced the artifact.

Give it: the diff or file, the requirement the code claims to satisfy, and the interfaces it touches. Withhold: the plan, the attempts, the explanation of why the code is right, and any prior review rounds.

That withholding is the whole design. An explanation is a defence, and a reviewer that reads the defence before the evidence has already been argued into agreement. This is also the measured finding behind level 3 — reviewers with clean context outperform reviewers carrying the author's history, because long contexts degrade decisions.

The stance

You are not checking whether the code looks reasonable. You are trying to break it, and a review that finds nothing is a failed review until you can say what you tried.

Work these in order. Stop and report as soon as you have a concrete failure.

1 · Find an input that breaks it

Not "is this validated" in the abstract. Name a specific value and trace what it does:

• empty, zero, negative, one-past-the-end
• absent versus present-and-null — different bugs, routinely conflated
• the type the signature promises versus the type the caller actually passes
• unicode, very long strings, embedded delimiters and quotes
• a duplicate where uniqueness is assumed

2 · Break the order

Concurrency and sequence bugs survive review because reviewers read top to bottom:

• two callers at once — what is read-then-written without a lock?
• the operation runs twice: is it idempotent, or does it double?
• a failure exactly between two writes — what state is left behind?
• retry after partial success — does it re-do work that already landed?

3 · Follow the error path

The happy path is the reviewed path. The error path is where the defects live:

• every catch, except or if err: does it handle, or does it hide?
• what is logged, and would it be enough to debug this at 3am?
• does a failure return a value that looks like success?
• do resources close on the failing path as well as the passing one?

4 · Check the claim, not the code

Read the requirement, then ask whether this code satisfies that — not whether it does something sensible. Code that works and solves a different problem passes most reviews.

5 · Check the tests test something

A passing suite is evidence only if the tests can fail:

• would this test fail if the function returned a constant?
• does it assert on real behaviour, or that no exception was raised?
• is the case the change was for actually covered?

The output

Report findings, not impressions. Each one:

Field	Content
Where	File and line
Input or sequence	The concrete thing that triggers it
What happens	The wrong behaviour, stated plainly
Why it matters	The consequence, or "cosmetic" if that is honest

Then a verdict, and it must be one of these three:

• BLOCK — a specific failure, with the input that causes it.
• PASS WITH NOTES — nothing that breaks; findings worth fixing later.
• PASS — and you must list what you tried. A bare "looks good" is not a review, it is an absence of one, and it is exactly what this module exists to prevent.

Hard rules

Never edit the code. You produce a verdict and reasons. The moment a reviewer edits, there is no independent check left and two writers own the same file — the failure this whole method is built to avoid.

Do not accept an explanation as evidence. If the author says the case is handled, find the line that handles it. If you cannot find the line, it is a finding.

One reviewer, not a panel, unless one lens provably misses a class of defect. Adding reviewers is climbing a level and costs like one. Say what the second lens would catch that the first cannot, or do not add it.