Should a different model review the code your agent wrote?

Code written by a coding agent still has to be reviewed, and the common advice is to use a different model for it: the one that wrote the code will go easy on it, so ask a second vendor. This piece checks whether that advice has evidence behind it. It reads the research, then adds thirty days of records from one review pipeline: a Codex reviewer on 278 pull requests written with Claude Code, with the author model assessing every finding before fixing it.

The short answer is that nobody has shown that a second vendor catches more than a fresh session of the same model, and the two direct code experiments that exist point in different directions. What the research does show is narrower and still useful. A model is a soft judge of its own work, mostly when that work sits in its own context window. Two models are not independent, and share more wrong answers than chance predicts. And two reviewers of different lineage find different bugs, so one of each covers more than two of the same. The pipeline's numbers fit that reading: the second model raised 763 findings, the author model accepted 682 of the 731 it assessed (93%) on first assessment, and the reviewer withdrew 4.5% of the blocking ones after pushback. That is a yield, not a controlled comparison, and we say what it does and does not show.

What has been tested?

Six studies bear on the question. Xiang et al. and Song compare review configurations directly, on tasks that include code. Both are 2026 preprints, and they disagree. Olausson et al. study code repair with feedback from a stronger model, and Nogueira et al. study failure correlation and majority voting among generated implementations. He et al. and Lu et al. study verification of reasoning. Both find a model weaker at checking its own work than another model's, and Lu et al. find the benefit shrinks as the two models become more alike.

Read the first two rows together. In Xiang et al., the only cross-model gain was the stronger model reviewing the weaker one's drafts, and self-review by that weaker model recovered most of the same ground. The reverse pairing, Codex on Claude drafts, made things worse than no review at all, and the authors say their design cannot separate review direction from the gap in baseline ability. Song's result is the one we find most informative. Song's top-tier cross-model reviewer was no better than the same model in a fresh session, and on the code artefacts it was slightly worse. The gain appeared only when both reviews ran, because they found different errors. Two reviews of the same model shared 52.2% of their errors; a same-model and a cross-model pair shared 46.1%. Neither paper tests repository-scale changes, and in Song's study the generator also planted the errors.

The other four add context. Olausson et al. is the oldest and the cleanest on code, and its gain is explained by feedback quality: GPT-4's feedback to GPT-3.5 lifted repair to roughly GPT-4's own level. Lu et al. and the DeltaBench appendix are the closest to a controlled self-against-other comparison, and both find self-critique weaker, with the benefit of a second model tied to how differently it thinks. Nogueira et al. is the cautionary one: even twelve different models fail the same tests far more often than independence predicts, and mixing families recovers under half of the gain you would expect from independent versions.

Why would a model go easy on its own code?

Because it recognises or is anchored to its own output, and because it cannot see a mistake it could not see while writing. Those are two different mechanisms, and only the first is fixed by changing the model.

The recognition effect was measured first on text. GPT-4 identified its own summaries 73.5% of the time, and across fine-tuned models its preference for its own output rose in line with its ability to recognise it (Panickssery, Bowman and Feng, NeurIPS 2024). A judge's recall of its own answers against other models' sat at 0.945 against 0.425 in one workshop study (Wataoka et al.). The effect follows lineage. Judges favoured a student model trained on their own data by 23.6%, a model in the same series by 8.9%, and a different series from the same family by 2.8% (Li et al., ICLR 2026, chat benchmarks).

On code, two 2026 studies measure it directly. Pombal, Rei and Martins (COLM 2026) asked twelve judges whether a solution satisfies a given LiveCodeBench unit test, and compared the false-positive rate on the judge's own failing code with its rate on other models' failing code. Most judges were significantly more lenient to themselves. GPT-5's ratio was 20.15, GPT-oss-120B's 5.97, Claude Sonnet 4.5's 1.78 and Claude Haiku 4.5's 1.71, and the leniency extended to same-family relatives. A ratio of twenty is a ratio of false-positive rates on a model that rarely fails, so it does not mean twenty times as many missed bugs, and the authors' hardness-stratified check keeps GPT-5 above one in nearly every bin. Khullar et al. (preprint, March 2026) tested the context mechanism on SWE-bench patches. When Claude Sonnet 4 rated a patch it had just produced in its own conversation, its ability to separate passing from failing patches fell from an AUROC of 0.99 to 0.89 in the same turn and 0.92 in the previous turn. Telling the model "you wrote this" barely moved the score. Showing it the same patches as fixed artefacts in a user turn restored 0.99.

Three results cut the other way, and they matter for what to do about it. Chen et al. (preprint) find that on MBPP+ between 81% and 89% of a strong judge's self-preference is legitimate, because its own code really is better, and that the harmful remainder rises when the judge is itself wrong. Roytburg et al. (preprint) rerun four earlier self-preference studies against a baseline that swaps in another model's wrong answer, and find evaluator uncertainty explains 89.6% of the measured effect on average; on MBPP-Plus the apparent self-preference falls by 89.26%. And Barkhordar and Thapa (preprint) find that a model's ability to pick out its own code is near chance (balanced accuracy 49% to 58%) and tracks length and docstring style; after normalisation, ten of twelve results fall to chance. A model's leniency to its own code is real, concentrated in the identical model and the same conversation, and largely a property of the questions it cannot answer rather than of recognising its own hand.

That second mechanism is a blind spot rather than a bias. Tsui (COLM 2026) injected the same error once as the user's and once as the model's own. Fourteen open models corrected the external version and missed the identical internal one 64.5% of the time on average; Claude Sonnet 4 missed 41.4%. On errors the models had generated themselves, only 4.3% to 10.8% were caught even when presented externally. A fresh session of the same model gets you out of the first mechanism. It does not get you out of the second.

Can a model fix its own mistakes without outside signal?

Not reliably, and the failure is in finding the error rather than fixing it. Huang et al. (ICLR 2024) removed the oracle labels from earlier self-correction setups and found accuracy fell: GPT-3.5 on CommonSenseQA went from 75.8% to 38.1% after one round of self-correction, and GPT-4 on GSM8K from 95.5% to 91.5% and then 89.0%. Tyen et al. (ACL Findings 2024) separated the two steps: given the location of a mistake, models repair it, and the best model located mistakes only 52.87% of the time. Stechly, Valmeekam and Kambhampati found GPT-4's self-critique on Game of 24 lowered accuracy from 5% to 3% while a sound external verifier reached 36%, and GPT-4 as a verifier of graph colourings had a 95.8% false-negative rate. Kamoi et al.'s survey (TACL 2024) reaches the same conclusion across the field: self-correction works where reliable external feedback exists, which for code means tests, compilers and static analysis before it means another model.

This is the strongest argument for some outside check on the author's work, and it says nothing about which check. The cited studies do not rank the alternatives consistently. In Song's study the author's in-session self-review scored F1 27.1, above the subagent (23.8) and both Gemini reviewers given the requirements (24.0 and 26.8). The only condition significantly below a fresh session (28.6) was a second self-review pass (21.7).

Are two vendors' models independent reviewers?

No. Models trained on similar data share wrong answers, and the sharing rises with capability. Kim, Garg, Peng and Garg (ICML 2025) measured agreement across 349 models on one leaderboard and 71 on another. When two models were both wrong on a HELM multiple-choice question they gave the same wrong answer 60% of the time, against a random baseline of one third; on the Hugging Face leaderboard the figure was 0.423 against 0.127. Same provider, same architecture and similar size all raised agreement, and more accurate pairs agreed more. Goel et al. add the judge angle: a judge's score for another model tracked that model's similarity to the judge (r = 0.84 averaged across families on MMLU-Pro), and across 130 models similarity rose with capability. Zhou et al. (TMLR 2025) found thirteen models from four families agreed on answers to fictional questions 54% of the time, against 25% by chance.

On code, Nogueira et al. (above) found that 65.9% of pairs of generated implementations deviated significantly from independent failure, and the manual analysis traced many distinct failure patterns to one shared root cause, such as relying on a global heuristic where the input structure mattered. A second vendor buys partial independence: majority votes across different models realised 0.44 of the reliability gain independence would predict, against 0.24 to 0.27 for one model. Those are voting experiments on generated programs, and they do not measure how many more defects a second reviewer catches. For judging, panels help: Verga et al. found a three-family panel tracked human judgement more closely than GPT-4 alone (Pearson 0.917 against 0.817 on Arena Hard) at a seventh of the cost, and Pombal et al. found a five-family ensemble reduced self-preference without removing it.

What do the vendors themselves do?

Neither of the two vendors whose models we use recommends a different vendor's reviewer. OpenAI's Codex reviewer and generator are the same model with different tasks, which its alignment team states in a footnote of its December 2025 post. The same post reports that review comments on PRs written entirely by Codex lead to a code change 46% of the time, against 53% on human-written PRs, and that comments appear on 36% of fully Codex-written PRs. Anthropic's Claude Code guidance recommends a second session as the easiest independent reviewer, says plainly that a default subagent is the same model on the same task, and warns that a reviewer asked to find problems will always find something. Its Code Review product reports that the share of its internal PRs receiving substantive review comments rose from 16% to 54%, with under 1% of findings marked incorrect, and does not say which model reviews. The case for a different vendor comes from tool vendors and practitioner posts, without effect sizes.

What did thirty days of a second model reviewing agent-written pull requests show?

A high yield with a low withdrawal rate, on code the author model had already tested and shipped as ready for review. Between 28 September and 27 October 2026 we ran 291 completed review rounds on 278 pull requests across 12 private repositories, mostly PHP and Laravel, Node and TypeScript, with some Python and Vue. The PRs were written in Claude Code sessions with Claude Opus 5.5 at the highest effort setting; 262 of the 291 runs forked that session so the author could answer with its own context. The reviewer was OpenAI's Codex, GPT-6.1 in 278 runs and GPT-5.6 in 11, also at the highest effort. Both agents worked from a full checkout of the branch rather than a diff, and the coordinator, not either model, ran the project's own tests after every fix.

The first-assessment acceptance rate, 682 of the 731 assessed findings or 93%, is the number to be careful with. It is the author model's judgement under a prompt that tells it to assess each finding critically and reject what it does not accept, and a model can defer. Three things argue that the acceptances were mostly earned. When the author did push back, the reviewer withdrew the finding 32 times out of the 55 that went to rejection or alignment, so the pushbacks had substance and the author was willing to make them. Every accepted fix then had to pass the repository's own test suite, run by the coordinator rather than reported by the model, and 51 of 484 check runs failed on the first attempt. And 81 fixes were sent back by the reviewer as not addressing the finding, which a deferential loop would not produce. None of that makes a finding true. It makes it a finding two models agreed on and the tests did not contradict.

What the second model found is the more useful part. We classified the 707 blocking findings by the root problem the reviewer named, one class each, by reading every title and the opening of its description.

Logic and spec mismatch, where the code does something other than the PR says, is 35.8% of the total. Concurrency and ordering is second at 14.9%, and state and data integrity third at 11.7%. Together with error handling and recovery, the four classes that need the reviewer to hold a sequence of events in mind make up 73% of what the second model raised. Security classes are smaller in count and larger in weight: authorization and access gave 8 of the 38 blockers from 33 findings, and the blockers read like a penetration tester's notes. An exhibitor could fetch every submission in a show, including other submitters' email addresses, through a JSON variant of a page that lacked the administrator check the HTML variant had. An administrator of one show could record a full payment against a work in another show and have that work assigned without the second show being paid. A failed password-writing query put the bcrypt hash into an exception message, and the diagnostic log tools returned it, bypassing a deliberate withholding of the password column. A treasury payment that failed its first send could still be broadcast after its grant had been corrected or revoked, because the guard ran in only one of the paths able to broadcast it. Each of these was in a branch the author had finished and the developer had opened for review.

The withdrawal rate was flat across classes, between 0% and 5% of findings in the large ones, with the highest rates in tests and verification (5 of 27) and secrets and configuration (3 of 21), where the reviewer sometimes asked for coverage the project had decided against. About 85% of findings named a concrete request, value, sequence or state, which is our estimate from reading the titles and a random sample of 25; the rest were general concerns such as a missing index or an N+1 query.

What does this data not show?

• There is no same-model control. We did not run Claude as reviewer on the same PRs, so the 763 findings measure the yield of a second model, not its advantage over a fresh session of the first. The research above suggests a fresh same-model session would have caught a large share of them, and Song's study suggests the two sets would have overlapped by about half.
• Acceptance is a model's judgement. No human labelled the findings as real bugs. The checks against deference are the pushbacks, the withdrawals and the coordinator-run tests, and they bound the problem rather than remove it.
• The reviewer saw finished work. Each branch had been worked to the point where the developer opened a pull request, so the reviewer found what survived the author's own session. That is the realistic condition, and it also means the yield is a lower bound on what the author missed.
• One developer's repositories. Twelve private codebases, one person directing every session, mostly PHP and TypeScript. The classification was done by a model from the same family as the author, one pass, with borderline calls recorded.
• No cost accounting here. A median run took 27 minutes of wall time and two review passes on two paid subscriptions; we have not priced it per finding.

The experiment that would settle the question is cheap to describe and nobody has run it on real code. Take a few hundred agent-written PRs. Review each three ways: the author's session, a fresh session of the same model, and a different vendor's model, all at matched effort, with the same prompt. Have people label every finding as a real defect, a style preference or wrong. Then compare recall of the human-labelled defects, overlap between reviewers, and withdrawal rates. Song's design is the nearest thing, on thirty artefacts with planted errors; Xiang et al. is the nearest on code, on single functions with no test runner. Our own next step is to run the same-model arm on a sample of our PRs, with the tool configured to use Claude as reviewer, and publish the overlap.

Why did we build review-loop?

Because the hand-driven version of this loop was taking sixteen review events on a single PR. review-loop is a small open-source coordinator that drives a reviewer agent and an author agent through pull request rounds: the reviewer reads a full checkout and raises structured findings, the author assesses each one and fixes only what it accepts, the coordinator runs the repository's own checks, pushes verified fixes, replies on the PR, and sends the reviewer back for another pass. When the two disagree past a budget, both arbitrate blind with the labels swapped, and whatever survives goes into one report the developer reads at merge time. Agents have no GitHub write access, no tokens and no credential helpers; the coordinator publishes. Codex reviewing and Claude authoring is the default, and either role can be given to any of the four agent CLIs it supports. The numbers above are its run store, which is why they come with event-level provenance rather than a survey.

What should you do with this?

• Never let the author's session be the reviewer. In Khullar et al., a model rating a patch in its own conversation separated passing from failing patches less well than the same model shown the patch in a user turn. In Song's study, a second self-review pass was the only condition significantly below a fresh session. It is also the configuration most people run by asking "does this look right?" at the end of a task.
• A fresh session of the same model is the minimum, and on the evidence it recovers most of the context effect. If you can only afford one review, run it off-policy: a new session, the diff or branch as input, no access to the reasoning that produced it.
• Add a second family for coverage, not for a verdict. The measured gain is that two different reviewers find different bugs. Treat the second model's findings as candidates to assess, which is what our loop does, and expect to withdraw a few percent of them.
• Match the reviewer's strength to the author's. A weaker different model is not shown to help, and in one study made the code worse. The stronger model should review the weaker one's work, whatever the vendor.
• Keep the tests in the hands of neither model. Self-correction works where external feedback exists. Have something that is not a model run the suite, and count a fix as verified only when it passes.
• Measure your own withdrawal rate. Findings raised, accepted on first assessment, withdrawn after pushback, and sent back as unfixed are four numbers any review pipeline can log. Ours were 763 raised, 682 of the 731 assessed accepted (93%), 32 of 707 blocking findings withdrawn (4.5%) and 81 of 768 fixes sent back (10.5%). If yours differ a lot, you have learned something about your reviewer or your author.