I stopped trusting my own review, so I made two AI agents argue about it
August 2, 2026
When I ask an AI coding assistant to fix a security issue and then "double check its own work," I get a confident yes almost every time — not because it’s careless, but because it already believes the fix is correct. It built the fix around that belief. Asking it to re-read its own reasoning mostly produces the same reasoning again, restated more confidently.
The change: a second reviewer with no stake in the design
Instead of one agent implementing a fix and then reviewing it, I split the work across two separate instances that never share context. One implements. A completely different one is handed only the finished result and one instruction: construct the actual attack, don’t just read the tests and assume they’re thorough.
That single change caught real problems a same-instance review had already missed. In one case, a fix for a specific bug had been applied to the "create" version of an operation but never to the matching "update" version — the identical defect, in the same file, that the whole piece of work existed to close. The implementing agent had genuinely tested its fix; it simply tested the half it had been thinking about.
Prove the test would have caught it — don’t just trust that it would
The sharpest habit that came out of this: before trusting that a test protects against a bug, deliberately reintroduce the bug and confirm the test actually fails. Not "the test looks like it should catch this" — actually break the code, on purpose, and watch the test turn red, then put the code back.
This caught something that would otherwise have looked like solid coverage: a test that was supposed to prove a security fix worked was passing on both the fixed and the broken version of the code, for reasons that had nothing to do with the fix. It looked green. It was proving nothing. The only way to find that out was to sabotage the code on purpose and check.
A wrong review is worse than no review
A reviewer that rubber-stamps bad work is worse than no reviewer at all, because it converts "unreviewed" into "reviewed and approved" — a much harder thing to walk back later. So the second agent was never just told to look for problems; it was explicitly told a clean pass is a fine and expected outcome, and to say so plainly rather than manufacture a finding to look thorough. Two of five reviews in this process came back clean, and they were trustworthy precisely because the same reviewer had already found real, serious problems elsewhere in the same body of work — it clearly wasn’t just agreeing to be agreeable.
What to ask about your own review process
- Does the person (or process) that reviews a fix have any reason to want it to be correct — and if so, can they really be its most rigorous critic?
- When someone says "this is tested," has anyone actually broken the code on purpose to confirm the test notices?
- Is a "looks fine" review allowed to say so plainly, or is there quiet pressure to always find something?
- When a fix touches five similar places, has anyone checked all five, or just the one that prompted the fix?
The takeaway
The person who wrote a fix is the worst-positioned person to find its blind spot, because the blind spot is the reason the fix looks correct to them. A second reviewer with no attachment to the design — one whose job is to try to break it, not confirm it — catches what a self-review never will.
Capabilities this touches