# Adversarial review brief

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/the-agent-never-touches-the-button/

Purpose: hand a change to an independent reviewer whose only job is to find where it is wrong.

Output: a findings table, evidence-checked responses and one verdict that names what would change it.

## Use when

A wrong “looks good” would be costly: the change is hard to undo, brings its own tests, touches security or release state, or only its author has checked it.

## Quick start

1. Bundle the artifact, the original request, the claim, the acceptance criteria and the evidence offered — not the author’s narrative.
2. Give the bundle and the brief in section 3 to a fresh reviewer, ideally a different model or tool.
3. Verify every finding before acting on it, then record one verdict.

Nothing merges on its author’s word: a different reviewer has to try to break it and fail.

## 1. Decide whether the pass is worth it

Run the build, tests and static analysis first. Add an adversarial pass if any line is true:

- [ ] A wrong result would be silent: plausible output, no failing check.
- [ ] It is irreversible or security-sensitive: deletion, release, permissions, secrets.
- [ ] Its tests come from the same author, so they share its assumptions.
- [ ] It was ported or generated from another context: locale, calendar, version or platform.

Skip it when the change is reversible and a deterministic check you trust already proves the claim.

## 2. Keep the reviewer independent

The author grades the work against its intent. The reviewer must grade the artifact.

| Give the reviewer | Withhold |
|---|---|
| The artifact: `git diff main...feature/x`, files or output | The author’s reasoning, plan and transcript |
| The original request verbatim, and the claim as one sentence that could be false | Explanations of why the change is safe |
| Acceptance criteria, including what must not change | “Tested, works” with no artifact |
| The evidence offered: commands, logs, hashes, results | Earlier reviewers’ verdicts |
| Read access to the base revision and reference data | Write, merge, release or publish access |

- Use a fresh session that never saw the author’s context — ideally a different model or tool, so the two do not share failure modes.
- Prefer a separately verified reference (the spec, known-good data) to the author’s tests as the oracle.
- The reviewer proposes. A human owns the merge, the release and every irreversible act.

## 3. Reviewer brief

```text
You did not write this change and you have not seen its author's reasoning.
Your job is to find where it is wrong. Do not edit, merge, release or publish anything.

ARTIFACT: [diff, files or output]
REQUEST: [the original requirement, verbatim]
CLAIM: [one sentence the author says is now true]
ACCEPTANCE CRITERIA: [observable conditions, including what must not change]
EVIDENCE OFFERED: [commands, logs, hashes, results]

1. Try to break it: find the input, state, date, environment or ordering that makes it wrong.
2. Check each claim against its evidence. Name every claim the evidence does not prove.
3. List hidden assumptions (formats, time zones, calendars, defaults, versions, paths,
   permissions) and say which ones the change's own tests share.
4. Check these failure classes: requirement silently narrowed; invented APIs, packages or
   flags; tests that cannot fail; swallowed errors; secrets or injection; unrequested scope;
   generated or mirrored files left stale.
5. For each finding give severity, reproduction, evidence, confidence and the cheapest check
   that would confirm or disprove it.
6. If you cannot break it, say plainly that it is correct for this claim and name what you
   did not check.

End with: VERDICT: proven / disproven / inconclusive - [one-line reason]
```

## 4. Findings

| Severity | Finding | Reproduction | Evidence | Confidence | Cheapest check |
|---|---|---|---|---|---|
| Blocker / Major / Minor |  |  |  | High / Medium / Low |  |

Blocker: the claim is false or unsafe. Major: true only under unstated conditions. Minor: verdict unchanged. A finding with no reproduction or evidence is a question.

## 5. Failure classes in agent-written changes

- [ ] **Requirement silently narrowed:** it solves an easier case (happy path, one locale, the sample data).
- [ ] **Invented APIs, packages or flags:** look each up (`npm view NAME version`; `https://pypi.org/pypi/NAME/json`, 200 or 404; `--help` or `man`). A dependency that exists is not yet trusted.
- [ ] **Tests that cannot fail:** asserting on mocks, copied output or live state; skipped or deleted. Break the code; a test must go red.
- [ ] **Swallowed errors:** empty handlers, `|| true`, defaults or retries that hide a failure.
- [ ] **Secrets or injection:** credentials in code, logs or fixtures; untrusted input reaching a shell, query, path or prompt.
- [ ] **Unrequested scope:** refactors, renames, upgrades or churn the claim did not need.
- [ ] **Generated or mirrored files left stale:** lockfiles, built assets, schemas, docs, version references.

## 6. Author response

- Reproduce each finding before acting; if it does not reproduce, answer with the evidence that refutes it.
- No performative agreement: “fixed” needs the check failing before the fix and passing after.
- Record disagreement with its evidence; agents never settle a blocker by vote.
- Fix in new commits, and send every blocker fix back to a reviewer.

| Finding | Reproduced? | Fix, refute or defer — with evidence | Reviewer accepts? |
|---|---|---|---|
|  | Yes / No |  | Yes / No |

## 7. Verdict

```text
VERDICT: Proven / Disproven / Inconclusive
CLAIM: [one sentence]
BECAUSE: [the strongest evidence]
WOULD CHANGE IF: [the observation that would flip it]
OPEN FINDINGS: [severity and summary, or none]
DECISION OWNER: [who merges, releases or rejects]
```

- Proven: no open blocker, every open major written into the claim as a condition, and the evidence re-checked by someone other than the author.
- Inconclusive: pending; it does not merge until an independent check reproduces the result.
- Disproven is still a result: keep the work and its evidence findable as a warning so nobody proposes it again.

## Worked example

**Claim:** `nextWorkingDay(date, region)` returns the next working day for every configured region.

It was ported from another service with its tests, all green. A fresh reviewer on a different tool got the diff, request, claim, criteria and test log.

| Severity | Finding | Reproduction | Evidence | Confidence | Cheapest check |
|---|---|---|---|---|---|
| Blocker | Weekend hardcoded; region setting ignored | Friday–Saturday region: Thursday in, Friday out | `src/dates.js` checks for Saturday and Sunday | High | One test for that region |
| Major | Ported tests share the assumption | Delete the region lookup: all tests pass | Every fixture uses Saturday–Sunday | High | Mutate the weekend |
| Blocker | New dependency does not exist; anyone could register the name | `npm view` on its name: E404 | `package.json` diff | High | Registry lookup |

**Response:** all three reproduced. A Friday–Saturday test failed before the fix and passes after; the dependency is gone. The reviewer re-checked the delta: no open blocker.

**Verdict:** Proven for both configured regions against a separately maintained calendar; would change if a region’s working days do not fit the setting. The human owner merges.

## Stop if

- The reviewer saw the author’s reasoning or shares its session: restart with a fresh reviewer.
- The claim cannot be stated as one sentence that could be false, or acceptance criteria are missing.
- A blocker can be neither reproduced nor refuted with available evidence: Inconclusive; nothing merges.
- Author and reviewer still disagree on a blocker after exchanging evidence: the human owner decides.
- Continuing needs write, merge, release or publish access, or a fix would widen scope beyond the claim.

## Sources

- GitHub Docs: Review AI-generated code — https://docs.github.com/en/copilot/tutorials/review-ai-generated-code (checked 2026-10-02)