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

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.