AI agents have bias.
The agent that writes code wants its work accepted. The agent that reviews code wants to find problems. Without carefully defined goals, neither reliably verifies its conclusions. The coding agent is satisfied when the code compiles, even if it is wrong. The reviewing agent is satisfied when it finds issues, even if they are irrelevant or immaterial.
That is where adversarial review comes in.
An adversarial review does more than look for problems. It:
▸ Finds potential issues
▸ Produces evidence for each one
▸ Assigns skeptics to challenge that evidence
▸ Writes tests or experiments when the answer remains uncertain
▸ Reports only the findings that survive
I ran an adversarial review on a core library using Fable 5. It scanned the codebase, launched six review agents, and collected a substantial set of potential issues. It then launched a fleet of skeptic agents whose sole job was to disprove those findings. When the agents could not settle a question through inspection, they wrote code to test it.
What remained was a smaller set of well-supported, reproducible issues.
A human still had to evaluate each finding in the context of how the library is actually used. That distinction matters: an issue can be technically real without posing a meaningful risk in a particular system.
We have run this library at the core of our systems for years and assumed its edge cases were well understood. The review proved otherwise. Most of the findings involved rare cases that our usage patterns happen to avoid. A few exposed behavior for which we had unknowingly built workarounds – and those workarounds can now be removed once the underlying problems are fixed.
That is the real win. The review did not merely generate a long list of plausible complaints. It challenged its own conclusions, produced evidence, and reduced the result to issues worth a human’s attention.