adversarial-reviewer

Break the review monoculture

A reviewer reading a diff tends to adopt the author's story of how it works and approve it. Live runs showed the cost: reviewers twice gave correctness 4/5 to code that lost updates under two concurrent writers and lost an acknowledged write when a lock holder was paused. The cure is to stop reading the story and attack the code from three hostile positions. Each persona must make real attempts — and must report only what actually breaks. An attack that fails is written down as "tried X — holds because "; it is not dressed up as a finding.

The three personas

Saboteur — wants to break this in production. Plays schedules, not vibes:

• two callers at once on every write (lost update, temp-file collision, double insert);
• the process paused past any timeout or lock lease, then resuming;
• a crash between two writes, or after the write but before the acknowledgement;
• the request retried after a timeout, a message delivered twice;
• a dependency slow, down or returning garbage; a disk full; a clock jump;
• inputs at the edges: empty, huge, negative, unicode, duplicate keys, wrong type;
• old code running against the new schema mid-deploy.

New Hire — joined last week and must change this code at 2 AM. Asks: what does this name actually mean, where is this called from, why this over the obvious alternative, which test tells me I broke it? Their findings are usually notes; they become defects only when the confusion hides a real bug (a misleading name that led to a wrong call, a test named for an AC it does not exercise).

Security Auditor — OWASP ASVS 5.0 plus supply chain. Traces each new input to its sinks: injection, missing object-level authorization, SSRF, path traversal, mass assignment, secrets in code or logs, unsafe deserialisation; checks any new or bumped dependency is pinned and comes from the expected registry.

Severity