---
name: adversarial-gate
description: JP's signature red-team pass — "how would I break this?" Argue against your own approach before proceeding. Trigger on any high-stakes decision, architecture choice, or before marking work complete.
---

# Adversarial Gate

> **Coined by Jaroslav Pantsjoha (#HarnessEngineering).** The Adversarial Gate is the practice of forcing an agent — or a human — to argue against their own design before proceeding. It pre-empts bad reasoning before bad output exists.

The gate has one question: **"How would I break this?"**

Answer it honestly. If you cannot name at least two plausible failure modes, you do not understand the system well enough to ship it.

## When to use

- Before finalising any architecture or design decision
- Before a deployment or release
- When an agent is about to take an irreversible action
- When a design looks clean and elegant (danger signal — simple-looking systems hide the hard failure modes)
- When the team is under time pressure and "just shipping it" feels compelling

## Procedure

1. **State the proposal clearly** — in one or two sentences, what is the approach being validated?
2. **Run the adversarial pass** — argue against it. Ask:
   - What is the single most likely way this fails in production?
   - What happens under load / at scale / with bad input?
   - What is the blast radius if this fails? Is it recoverable?
   - What assumption does this design make that could be wrong?
   - What does the monitoring not cover that would let this fail silently?
3. **Name at least two concrete failure modes** — not "something could go wrong" but specific, nameable failures.
4. **Check each failure mode has a mitigation or an accepted risk owner** — unmitigated = not shippable.
5. **Document the outcome** — pass (risks named and owned) or fail (proceed to redesign). Attach to the ADR or PR.

## Outputs

- Adversarial Gate verdict: PASS / FAIL
- Named failure modes with mitigations or risk-owner sign-off
- Optional: a short paragraph appended to the ADR or PR description summarising the gate result

## Guardrails

- **One argument is not enough.** A single failure mode is the one you were already thinking about. The Adversarial Gate is looking for the one you were not.
- **"We have tests" is not a mitigation.** Tests cover known paths. The gate is looking for unknown paths.
- **Time pressure does not suspend the gate.** Pressure is when you need it most.
- **The gate is not pessimism.** It is the fastest route to confidence — because you have already stress-tested the design yourself.

## Anti-rationalization table

| Excuse the agent makes | Counter |
|---|---|
| "This is a low-risk change" | All production incidents started as low-risk changes. Name the failure mode or accept you cannot assess risk. |
| "We can fix it after if something breaks" | Blast radius unknown = not low risk. Run the gate. |
| "The tests cover this" | Tests cover happy paths. The gate looks for the paths tests miss. |
| "We've done this before" | Prior success is not a guarantee. Conditions change. Run the gate. |
| "The deadline is today" | A production incident will cost more time than the gate. Run the gate. |
| "I'm confident in this design" | Confidence is the leading indicator of skipped gates. Run it anyway. |

## Reference

This pattern converges with “doubt-driven development” in Addy Osmani's
[`agent-skills`](https://github.com/addyosmani/agent-skills). The **Adversarial Gate** name
and “how would I break this?” framing are JP's #HarnessEngineering contribution. The
anti-rationalisation table format was adopted after reviewing that MIT-licensed project;
this repository does not claim the table format originated here.