An agent that grades its own homework will always find a way to pass itself. That’s not pessimism, it’s basically math: whatever reasoning got you into a decision is still sitting right there when you turn around and ask yourself to check it. The original poster, u/Substantial_Belt2626, found this out the hard way, and not even with an AI agent first, it was a test harness they’d been running for weeks.
The harness kept printing “0 passed, 0 failed, exit code 0.” Green, every single run. Turns out it wasn’t collecting any test cases at all, so it compared nothing, nothing failed, and it reported total success. Everything shipped during that stretch went out completely unverified, and the author felt more confident than if there’d been no check running at all. A broken verifier doesn’t fail loudly. It lies to you with a straight face, and you believe it because it looks exactly like success. Nobody caught it sooner because a passing test suite doesn’t invite scrutiny, that’s the whole point of having one, and this is exactly the blind spot that made the bug survive for weeks instead of a single afternoon. That single bug is the whole argument in miniature.
🧠 Here’s the idea that actually matters: coding agents have the same failure mode, and it’s worse there. An agent that plans a change, writes the code, then reviews its own diff will approve almost anything, because it remembers exactly why every shortcut made sense in the moment. It’s not reading behavior anymore, it’s reading its own intentions back to itself, and it already convinced itself once, so the second pass is free. Telling it to “be more critical” doesn’t touch this. The reasoning is still sitting in context, so the model performs skepticism and lands on the same verdict anyway. Ask it to list edge cases it might have missed and it’ll happily generate a list, then wave every item away with the same justification that shaped the original code, because none of that reasoning ever left its context window. A few people in the thread said the same thing happened to them with same-context review, tone changed, the verdict never did. One commenter described watching an agent flag its own bug in plain language, then conclude in the very next sentence that the bug wasn’t actually a problem, because it could still see the reasoning that made the shortcut feel fine the first time around.
- Separate the roles completely. The fix this Redditor landed on: the verifying role runs in its own context and only gets a file path, never a summary of what the builder did or why. The moment one role explains the previous phase inside the next one’s prompt, the independence is gone, and a leaky run looks perfectly clean while verifying nothing. In practice that means no shared scratchpad, no “here’s what I just did, please check it” handoff message, and no letting the reviewer see the plan before it sees the code. Even something as small as a commit message summarizing intent can be enough contamination to make the review agree with the builder by default.
- Treat a silent pass as a bug, not a result. Every check now needs a control built in that’s supposed to fail on purpose. If it doesn’t fail, the check itself is broken, not the code. Zero cases collected counts as an error now, never a neutral “all good,” which is exactly the state that burned the author for weeks. Concretely, that looks like seeding one test you already know should fail and confirming the run actually reports it as failing before you trust anything else that run says. If your “all green” harness can’t produce a single red result on demand, you don’t have a working test suite, you have a very convincing rubber stamp.
- Skepticism prompts don’t fix epistemics. The author tried “just prompt it to be critical” first, before building any of this. It changes tone, not the actual verdict, since the model still holds all its own reasoning in context and reads the artifact straight through that lens regardless of how the prompt is worded. Stronger wording, more emphatic instructions, even threats about consequences for missing bugs, none of it moves the needle, because the fix isn’t a better prompt, it’s a different context entirely.
The actual build is free and MIT-licensed: four separate Claude Code roles. An Architect writes the plan, a Coder implements it, a Tester writes and runs real tests without ever seeing the Coder’s reasoning, and a Manager gates every handoff between them. It runs roughly four times the cost of a single-role setup, and it deliberately refuses one-line fixes, since there the process costs more than it saves! That refusal is the tell that this thing was actually built to be honest instead of just built to look thorough. For a quick typo fix, dragging four separate agents through a full plan-code-test-gate cycle would be theater, not rigor, and the system knows the difference.
🛠 If you’re running any pipeline where an agent reviews its own output, go check it for this exact hole today. Look specifically for the review step that reads a summary of what the previous step did instead of just the raw output, that’s where the leak usually hides. The original poster dropped the full repo in the thread, worth a look even if you just steal the “build a control that fails on purpose” trick for your own tests.
Frequently Asked Questions
Q: Why doesn’t telling the agent to “be more critical” fix this problem?
Because it changes the tone, not the reasoning. The model still has the builder’s rationale in its head and reads the diff through that lens, so it’s already convinced itself it was right. You need actual structural separation: the reviewer has to never see the builder’s reasoning, only the final code.
Q: What information should I hide from the reviewer?
The builder’s reasoning, explanations, and rationale for every decision. Only give the reviewer the files, test cases, and expected outputs. The second you include “here’s why we did this,” independence vanishes and a broken implementation looks fine.
Q: How do control cases prevent silent failures?
Control cases are intentionally-failing tests baked into your harness. If the reviewer doesn’t flag them, the whole run fails, not as a warning, but as a hard error. This catches when your validator is collecting zero cases and pretending everything passed.
Q: Should I use a different AI model for building vs. verifying?
Some users found it helps: using a different model family (like Claude for building, something else for reviewing) improved how well they caught real issues. But the bigger win is keeping the contexts separate. Even the same model works if the reviewer never sees the builder’s reasoning.
An agent that reviews its own work approves its own work. It already convinced itself.
by u/Substantial_Belt2626 in PromptEngineering