Arc · 6 posts
No Model Reviews Its Own Homework
The factory's adversarial-review practice didn't start as doctrine, it became doctrine because the same failure kept recurring: a fix, itself unreviewed by a second perspective, quietly introduced the next bug. This arc is that doctrine's origin story plus four demonstrations that it holds outside its original context, closing on the sharpest evidence available: two real, live-exploit-confirmed bugs a second reviewer caught that the first pass missed.
Reading order
- 1No Model Reviews Its Own Homework
agentic-sdlc-patterns
Four documented review cycles, one recurring shape: a fix, left unreviewed by a second perspective, quietly introduces the next bug. The sentence the factory arrived at after proving it the hard way, four times.
- 2The Fixes That Held Changed a Rule
agentic-sdlc-patterns
Three adversarial review rounds on the same new codebase, and the diagnostic that separated a durable fix from a fragile one: did it change a rule, or just a line?
- 3Doubt Before the Code Exists
agentic-sdlc-patterns
Adversarial review, applied at intent-declaration time instead of code-review time, caught real defects before a single commit existed to review, proving the doctrine is a decision-making technique, not just a code technique.
- 4It Wasn't a Matched-Cast Comparison
agentic-sdlc-patterns
A live-model coordination comparison looked decisive: peer-delegation succeeding, central-orchestrator starving the colony. An independent review asked whether it was actually a fair fight. It wasn't.
- 5Shipping With a Watch, Not a Verdict
agentic-sdlc-patterns
Five doubt cycles on one small registry guard, and the finding rate never reached zero. What actually caught the headline bugs was mutation testing and fresh-context review, self-inspection caught none of them.
- 6Two Reviewers, One Exploit, Two Real Bugs
agentic-sdlc-patterns
Two AI reviewers, independently, with real build and openssl access, found a bypassable revocation path and a spoofable certificate identity field in device-CA code. Both were confirmed with a live exploit, before and after the fix.
Interactive · Arc-level · No Model Reviews Its Own Homework
Six real incidents, six different products and people. Every one collapses to the same shape: a first pass believed something was settled, and a differently-angled second pass, aimed at exactly what the first pass just changed, caught what it structurally could not see. Pick an incident.
First pass
A device-certificate authority's enrollment path shipped without checking a device's current status before issuing it a fresh certificate.
Second pass caught
Two independent reviewers, given real build, Docker, and OpenSSL access and told to attack rather than read, separately reproduced a live exploit: replaying an already-processed enrollment request against a just-revoked device minted it a brand-new, fully valid certificate.
Why the first pass missed it
A review that never runs the code it's reviewing is trusting the code to describe itself honestly. This class was very plausibly invisible to static reading alone.
Proof
The fix was verified by revoking a real device, then replaying the identical exploit again: confirmed rejected with the correct error, and confirmed the device's status stayed revoked, not silently reset by the attempt.