adversarial-review-cycle

An adversarial code review is a structured hardening pass that hunts for bugs and security gaps the implementer missed. It forces an explicitly hostile review loop to identify and fix P0/P1 issues before release, preventing avoidable production failures.

To run an adversarial hardening pass, prompt the reviewer in explicitly hostile terms like “Poke holes in this and try to break it.” The cycle requires two review rounds from different angles, full-diff consumption, and severity classification before a ship-or-spin decision.

Yes, you can use this adversarial review process for completed, non-trivial iOS, web, and AI agent changes. The work must be stable enough for a full-diff and test read-through to identify and fix P0/P1 issues before release.

The best way to triage findings during a security hardening review is to classify them by severity as P0, P1, P2, or P3. You must fix all P0 and P1 issues before proceeding, and only declare “ship clean” when both review rounds return acceptably clean results.

Yes, a full-diff adversarial review requires the reviewer to read the tests themselves, not rely on summaries. The reviewer must read the full git diff or each changed file end-to-end alongside the tests to ensure comprehensive scrutiny.

You should block a release after an adversarial review cycle if there are unresolved P0 or P1 issues. The ship-or-spin decision blocks on these high-severity findings, requiring explicit rationale for accepting any lower-severity P2 or P3 issues before shipping.