Don't Let AI Grade Its Own Homework: Four Key Principles for Coding Agent Review

Recently, while browsing on X, I noticed the same idea recurring across different code repositories: add a review step before agent-generated code is pushed, and don't let the agent that wrote the code decide whether it's done.

I agree with this view, and it has become a rule I follow when building tools.

Why self-review doesn't work

When a model writes code and then checks it itself, it tends to repeat its own blind spots. The assumptions that produced the bug are the same assumptions it uses to review the code. Re-running "please check carefully" with the same model mostly yields more confidence, not more coverage.

There's a structural reason behind this: a model's reasoning path is continuous. The context it built while writing the code—its understanding of the requirements, its assumptions about edge cases, its expectations about dependency behavior—is fully preserved during the review phase. It doesn't suddenly gain an "external perspective," because the same set of weights can't simultaneously be the problem-maker and the problem-finder.

Four practices that work in practice

Run deterministic checks first

Linters, tests, secret scanners. They catch the boring problems cheaply, so that any model review can spend its attention on intent and edge cases.

The order matters. If you let the model review first, it may waste a large number of tokens on style issues that a linter can resolve in milliseconds. Putting deterministic tools first is essentially "preprocessing" for model review, letting its context window focus on the parts that genuinely require judgment.

Deterministic checks refer to tools whose output is fully predictable and doesn't rely on probabilistic reasoning: linters check code style and common errors against fixed rules, unit tests produce fixed pass/fail results for given inputs, and secret scanners match sensitive strings using regex or entropy analysis. In contrast, model review is probabilistic—the same code may yield different conclusions across different runs. The value of putting deterministic checks first is that they provide a binary, reproducible signal, consume no model context, and aren't contaminated by the model's reasoning biases, thereby leaving a cleaner starting point for subsequent model review.

Use a different model as the reviewer

Different training, different blind spots. Disagreement is the useful signal.

This point was repeatedly mentioned in multi-source discussions. According to several developers sharing on X, when they integrated a second model for code review in their CI pipelines, the most valuable output wasn't "pass" but the cases where the two models reached inconsistent conclusions. These points of divergence often point to genuine design ambiguities or hidden edge conditions.

"Different" here doesn't just mean a different model name—it means substantive differences in training data, fine-tuning objectives, and reasoning style. Different-sized models in the same family often share large amounts of training corpus and alignment strategies, with highly overlapping blind spots and limited review effectiveness. What's truly valuable is models from different vendors and different architectures, whose "first reactions" to the same piece of code may be completely different—and this inconsistency precisely exposes ambiguities in the requirement description. In practice, you can treat the second model's output as a signal rather than a verdict: when both agree on passing, human spot-checks are still needed; when disagreement arises, prioritize human intervention.

Keep states separated

"Candidate," "verified," "human-reviewed," and "released" are four different things. Conflating them is how unreviewed code gets into the main branch.

The problem for many teams isn't the absence of review but the compression of the state machine. The agent says "done," and the code is marked as mergeable—missing the three independent gates in between: deterministic checks passing, second-model review passing, and human confirmation. Each gate should be an explicit, non-skippable state transition.

A state machine is a model in software engineering that describes a system transitioning between a finite number of states according to rules. In the code review process, modeling "candidate," "verified," "human-reviewed," and "released" as explicit states means every transition must be triggered by corresponding evidence: tests must pass to move from candidate to verified, second-model review must pass to move to human review, and human confirmation is required before release. The essence of state separation is turning "done" from a subjective judgment into an auditable transition record—any shortcut that skips intermediate states leaves a visible gap in the process.

Pull the source code out as files

Reading a chat log is not reviewing. Download the code, open it in your editor, and look at the handoff points.

A chat log is a narrative that naturally guides you to accept the agent's reasoning framework. Files are objective—you can grep them, diff them, jump to definitions. The object of review must be files, not conversations.

How I built this philosophy into a tool

I made a desktop workspace called Brainstorm, where several AI models discuss a goal, split the work, and then a different model reviews it before anything counts as done. You export the source code and make the final decision yourself.

It's BYOK: you connect your own model accounts or API keys, and we don't sell tokens. Linux is the first platform.

If you're interested in taking a look: https://brainstorm.mungwaan.cn

How do you gate agent-written code today: tests only, a second model, or human review every time?

Why this problem will only grow more important

As coding agents take on more real work, the question of "who decides it's done" will rise from an engineering detail to the core of process design. Self-review's failure isn't a matter of model capability but a structural problem—any single judge will systematically miss the problems it created itself. Multi-model review, deterministic checks first, state separation, and source code as files together form a line of defense that doesn't rely on any single model's self-discipline.

According to discussions among several developers on X, what's most dangerous is often not the agent writing wrong code but the agent confidently declaring the code correct. The design goal of a review process should be to make "correct" an assertion that requires external evidence, not just a sentence from the agent.