Español

One Model Writes, a Different Model Reviews

Never let the AI grade its own homework. The model that wrote your code shares its own blind spots — ask it to review its own output and it tends to approve its own mistakes. The fix is structural, not a better prompt: one model writes, a different model reviews, the first one fixes, and a human makes the final call.

Why self-review fails

This isn't a hunch; it's measured.

• Self-enhancement bias. The MT-Bench study that popularized LLM-as-a-judge documented that model judges can favor their own outputs — GPT-4 rated its own answers higher in evaluation setups (Zheng et al., 2023).
• Self-preference is tied to self-recognition. A NeurIPS 2024 paper showed LLM evaluators score their own generations above others' even when human annotators rate them equal — and models like GPT-4 recognize their own text with non-trivial accuracy, with self-recognition linearly correlated to self-preference (Panickssery et al., 2024).
• Intrinsic self-correction underperforms. Without external feedback, asking a model to "check your answer" often leaves reasoning performance flat or worse; earlier gains largely came from oracle labels the model wouldn't have in practice (Huang et al., ICLR 2024).

The intuition matches the data: the same weights that produced a wrong assumption will re-apply that assumption during review. One model, one set of blind spots.

The split-role loop

1. Model A writes. Full task context: spec, constraints, codebase conventions.
2. Model B reviews. A different model family gets the diff plus the spec and reviews for correctness, edge cases, and architecture. It flags — it does not rewrite.
3. Model A fixes. Feed B's findings back to the writer. Cap it at 1–2 rounds.
4. A human decides. Merge, revise, or reject. The models advise; you own the call.

A review prompt that keeps the roles clean:

You are a senior code reviewer. You did not write this code.
Review the diff below against the attached spec for correctness,
edge cases, and architecture. List findings as numbered items
with file:line references. Do not rewrite the code.

Rules of thumb

Power-user moves

• Cross-family beats cross-version. Two versions of the same model line share training data and habits; a reviewer from a different provider brings a genuinely different set of blind spots — and different models miss different things.
• Starve the reviewer of the writer's context. Give Model B the diff and the spec, not the writing conversation. Chat history carries the writer's rationalizations, and a reviewer that reads them starts to inherit them.
• Automate the split you already have. If an AI assistant wrote the code, requesting a review from a separate tool — for example GitHub Copilot code review on the pull request — gives you a second model in the loop with zero pipeline work.
• Hold both models to human review standards. Google's engineering-practices reviewer guide (does the change improve overall code health? is it correct, tested, understandable?) is a solid checklist for what to ask Model B — and for your own final pass.

Resources

• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al., 2023) — documents self-enhancement bias in model judges
• LLM Evaluators Recognize and Favor Their Own Generations (Panickssery et al., NeurIPS 2024) — self-preference bias and its link to self-recognition
• Large Language Models Cannot Self-Correct Reasoning Yet (Huang et al., ICLR 2024) — why intrinsic self-correction underdelivers
• Using GitHub Copilot code review — a drop-in second reviewer on pull requests
• How to do a code review — Google engineering practices — the human standard both models should be held to