jpantsjoha 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
- State the proposal clearly — in one or two sentences, what is the approach being validated?
- 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?
- Name at least two concrete failure modes — not "something could go wrong" but specific, nameable failures.
- Check each failure mode has a mitigation or an accepted risk owner — unmitigated = not shippable.
- 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. 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.