AI Development
Don't Let the Maker Be the Checker
An AI agent grading its own work passes itself every time — the highest-value move in an autonomous loop is to hand the review to a separate agent, ideally a different model told to assume the author is wrong.
- AI Development
- AI Agents
- Quality
- Reliability
Ask an AI agent to do a task and then ask the same agent whether it did the task well, and it will tell you it did great. Of course it will — it’s the author, grading its own homework, and it has every incentive and every blind spot to give itself a passing mark. This is one of the most reliable ways an autonomous loop fools you, and the fix is old and boring and effective: separate the maker from the checker. The thing that produces the work should not be the thing that approves it.
A model reviewing itself is a closed circuit
When one agent both writes and judges, there’s no independent signal anywhere in the loop. Any flaw in the work is, by construction, a flaw the judge shares — same model, same context, same assumptions, so whatever it missed while making it, it misses again while checking it. It talks itself into “looks done” and moves on. That’s not laziness you can prompt away; it’s structural. A single agent evaluating its own output is a circuit with no outside reference, and it will happily converge on “yes, that’s finished” whether or not it is.
An agent checking its own work isn’t verification, it’s agreement with itself. You need a second opinion that isn’t just the first opinion in a mirror.
Give the review to a different agent
The move is to make the checker a separate agent — a distinct reviewer whose only job is to evaluate the maker’s output against the spec and the tests. One agent explores and implements; another, defined and invoked separately, reviews. Ideally the checker runs a different model, because a different model has different blind spots, so it catches things the maker’s model couldn’t see. And you instruct it adversarially: assume the author got it wrong until the work proves otherwise, review it like an owner who has to live with the result. A reviewer told to find fault finds real faults; a reviewer told to “check if it’s good” rubber-stamps.
This is just separation of duties, which we already trust everywhere it matters. Human code review exists because the author is the worst person to catch their own mistakes. Four-eyes approval exists for risky operations for the same reason. Maker-checker is that principle applied to agents — and it turns out to be, by a wide margin, the highest-leverage thing you can add to a loop, because it’s what stops the loop from drifting toward “looks done” without being done.
Tool checks and agent checks are both worth having
A separate reviewer agent isn’t the only kind of verification, and it’s important to be honest about its limits. A second model is less grounded than a tool — a compiler, a test suite, a type checker can’t be talked into agreeing, whereas two language models can still share a blind spot. So the strongest loops use both: a tool-based verifier for the objective facts (“does it compile, do the tests pass”) and a second-agent reviewer for the judgment a tool can’t render (“is this actually solving the right problem, is this diff sane”). The tool is the floor you can’t argue with; the reviewer catches what the tool doesn’t think to check. I made the case for the tool side of this before — the maker-checker split is the agent side, and they’re complementary, not competing.
Spend the second opinion where being wrong is expensive
The honest cost: a separate checker means running a second agent, with its own model and its own tool calls, so it isn’t free. That’s fine — it just means you aim it deliberately. Being wrong on a throwaway script is cheap, so maybe you skip the review. Being wrong on a change to something that matters is expensive, so that’s exactly where a separate, adversarial checker earns its tokens. It’s the same judgment about where to spend that runs through all of this — put the expensive verification where a mistake would hurt.
The principle is small and it long predates AI: the maker doesn’t get to grade the work. Wire your loops so a different agent, ideally a different model, with instructions to be skeptical, does the checking — and back it with a tool verifier for the objective parts. An agent that grades itself will always pass. An agent that has to convince a skeptic actually has to be right. If you’ve built a maker-checker setup and watched the checker catch things the maker was sure about, I’d love to hear about it.