We replaced our reviewer agent with the same agent, memory wiped. It found the same bugs.

We ran the classic writer-agent -> reviewer-agent setup on code changes. Same model on both sides, different system prompts. The reviewer got the "you are a harsh reviewer" treatment. It worked, sort of. The reviewer reliably caught surface stuff. Dead imports. A missing null check. An off-by-one. Sloppy error messages that would've made an on-call shift worse than it needed to be. What it never caught was the class of bug that actually cost us money: things the model believes confidently and wrongly. The example that still annoys me. The writer wrapped a POST in a retry loop because it "knew" the endpoint was idempotent. It wasn't. The reviewer read that same retry loop and also knew the endpoint was idempotent, so the code just read as correct to it. Duplicate charges in production. Fun morning. After a few of these i started to suspect the reviewer was never an independent observer at all. It just didn't have the writer's context. So we tested it. Threw away the second agent. Same single agent, hard context reset, handed only the final diff with no memory of having written it. It caught roughly the same set of things. Dead code, missing guards, the same awkward edge cases. So whatever that second instance was buying us, it was mostly a fresh context window. The independence i'd assumed was in there was never in there. I want to be fair to the setup though. Reviewing really is a different job from generating. When you generate you're committing token by token and you have to keep going. When you review you see the whole artifact at once. That's a genuine asymmetry, and the reviewer does beat the writer at some things because of it. It just doesn't help when the model is confidently wrong, and those are the expensive ones. Correlated errors are exactly the ones nobody catches. The checks that actually helped came from outside the weights. Running the thing for real. Replaying a production trace against it. Assertions derived from prod data instead of from vibes, which was tedious to build and did more for us than any amount of reviewer prompting. Maybe a different model family helps too, i genuinely don't know. Which is the thing i'm curious about. Has anyone actually measured that a different model family decorrelates the errors, or are we all just assuming it because it feels like it should? And does a sterner system prompt ("you are a paranoid security reviewer") buy any real independence, or just a more confident-sounding rubber stamp?