Cross-model code review

Cross-model code review is the arrangement where one model writes the code and a different model reviews it, and usually fixes it too. It raises two design questions: whether the writer can review its own work, and which of the two seats should get the stronger, more expensive model.

The practitioner claim

A September 2026 post on a Russian-language Telegram channel lays out a concrete version. The author has coding tasks done by DeepSeek-V4-Flash, cheap enough that he also runs its vision variant locally for overnight jobs, while GLM-5.3 does code review and fixes. He reports that the pair works well on his tasks and keeps him within about $200 a month, $144 of which is the GLM Max v2 subscription. The post makes three arguments and cites six papers for the last two.

The first is cost. In feature-based work, writing code consumes many times more tokens than reviewing the changes, so the cheaper model should do the bulk.

The second is that the writer should not review itself. The model that made an error, or even its model family, is likely to miss it for the same reasons it made it. His own side-by-side comparisons of review against self-review agree, with self-review almost always worse. He notes that self-review can be pushed further by running it as a goal ("a repeat review must find no new must-fix or should-fix issues"), at a much higher token cost than a review by another model.

The third is that the weaker model should write and the stronger one should review, not the other way round, because a strong model's coding errors are too subtle for a weak reviewer to catch and the weak reviewer would mostly idle. He attaches a caveat: "weak" is relative, and the writer must clear a quality threshold below which review turns into rewriting most of the change, a threshold that depends on the tasks, the domain and the stack.

What the cited papers actually measure

Only one of the six papers is about code review, and it does not vary who wrote the code. Two are about code generation with model collaboration or candidate selection. Three are about math and reasoning. The post's claims are therefore extrapolations, and the papers support them unevenly.

• llm-self-verification-limits (2024): GPT-4 critiquing its own answers in a loop on puzzles and planning, against a sound external checker.
• reviewer-capability-rejection-targeting (2026): a fixed executor with self-review, a cross-family reviewer and a weak reviewer, on 100 olympiad math problems.
• verification-dynamics-llms (2025/2026): 15 models as both generators and verifiers on math, knowledge and reasoning benchmarks.
• strong-weak-model-collaboration-codegen (2025): ways to split SWE-bench Lite issue fixing between a strong and a weak model.
• small-model-code-judges (2026): small fine-tuned judges picking among a small generator's Java candidates.
• swr-bench-code-review (2025/2026): LLM review of 1,000 real, human-written pull requests.

Self-review

Both papers that test self-review find it underdelivers, which supports the post's conclusion. Neither finds the mechanism the post describes. In the 2024 GPT-4 study the self-critic failed mainly by rejecting correct answers and writing hallucinated critiques, which drove accuracy below the model's first guess. In the 2026 pilot the self-reviewer had the highest recall of any reviewer (0.85): it did flag its own errors. It also rejected 35% of answers that were already correct, repaired only 15% of what it rejected, and produced a +6-point gain that was not significant, while a cross-family reviewer added 12 points with no damage.

The difference matters for the goal-loop workaround. A self-reviewer that over-rejects is harmless only while the writer ignores it. In the pilot, the writer complied with 3 of the 18 false rejections and all 3 answers became wrong, and full compliance would have pushed accuracy below having no review at all. A loop that keeps revising until the reviewer is satisfied is a loop that complies, so the goal-mode rerun is spending extra tokens on a reviewer whose rejections are least trustworthy.

The same-family half of the claim is not tested by any of the six. The 2025 verification study cites concurrent work (Lu et al.) reporting that cross-family verification is especially effective, but that paper is not in the vault. llm-cross-entropy-similarity shows models from one lab write alike, which is the intuition behind the claim, but it measures prose style, not shared blind spots.

SWR-Bench adds a qualification. Merging ten review passes from the same model raised F1 by 43.67% and recall by 118.83%, so repeating one model is not useless as a reviewer of someone else's code. That is a different situation from reviewing one's own output.

Stronger writer or stronger reviewer

The best support for "weak writes, strong reviews" is verification-dynamics-llms. Errors from stronger generators are much harder to catch: Qwen2.5-72B rejected 68% of wrong math answers from Llama-3.1-8B and 17% from Qwen3-32B, because weak models make surface mistakes and strong models build coherent chains on an early wrong step. With GPT-4o verifying, weaker generators closed 30–50% of their gap to stronger ones across domains, and on one 181-problem math subset Qwen3-4B with a GPT-4o verifier scored 0.954 against GPT-4o generating alone at 0.952, using 2.5 times fewer GPT-4o tokens. The pilot's weak reviewer, which could not solve the problems, changed none of 100 answers while doubling token cost, which supports the "weak reviewer idles" half.

Three results qualify it.

The collaboration paper the post cites never tests a reviewer. In strong-weak-model-collaboration-codegen the highest-quality split has the strong model write the patch and the weak one only fix formatting, the reverse of the post's order. The split where the weak model does most of the work is a budget cascade that adds little when the weak model is competent. Read literally, that paper favours the strong writer.

A weak checker can work if it is trained for the job. In small-model-code-judges, small models used zero-shot were near-useless judges of Java correctness (kappa 0.00–0.35), but after fine-tuning a 3B judge reached 0.57, above GPT-4.1-mini, and a 1–4B generator plus that judge matched or beat its 8–33B sibling in four of five families. The judge was not stronger than the generator. It was specialised, and trained on outputs from those same generators.

The strong-reviewer advantage also fades exactly where the post needs it most. The verification study found that on hard problems, and on strong generators' output, a 7B verifier and GPT-4o gave about the same gain, 0.1 or less, because neither could catch much. The helpful reviewer in the 2026 pilot was a mid-tier model from another family and was never shown to be stronger than the executor.

Which claim holds when

Four points survive the evidence, each with a condition attached.

Do not let the writer grade itself in a loop that acts on every rejection. This is supported for self-critique generally, and the failure is over-rejection and bad critique more than blindness.

Put a different model in the reviewer seat, and make sure it can solve the task itself. Below that floor, review costs tokens and changes nothing. Above it, precision matters more than recall: a reviewer that rejects rarely and correctly beats one that flags everything.

Pairing a weaker writer with a stronger checker pays while the writer's errors are the shallow kind a checker catches. It pays less as the writer improves, because the remaining errors are coherent and even strong verifiers miss them. This is the post's quality-threshold caveat approached from the other side: the writer must be good enough that review is not rewriting, and weak enough that its mistakes are still visible.

Where a sound check exists, it beats any model critic. The 2024 study found that re-sampling against a sound verifier kept most of the gain with no critique text at all. In code that means tests, type checkers and compilers, as in testing-heavy-no-review-workflow and neurosymbolic-ai. A model reviewer covers what those cannot express.

All of this rests on benchmarks with ground truth, mostly math, models from 2023 to 2026, and in one case a 100-problem pilot, so llm-output-variance applies. None of the six measures what the post actually does: an agent working in a real repository, reviewed and fixed by a second model. SWR-Bench, the one real review task, puts the ceiling in view: the best single-pass LLM reviewers reach about 20% F1 on human pull requests, mostly because of false positives.

Relation to human review

Model review is attractive because human review cannot keep pace: code-review-throughput-limits and reviewing-ai-code put numbers on that. cacm-code-review-ai-coding quotes a founder whose pipeline includes a fresh adversarial review pass, and llm-critics-are-right-use-anyway describes adversarial subagents run until they start inventing problems. roborev lets the reviewing and fixing agents be different models. Against all of this, laycock-review-by-exception argues that an AI reviewer preserving the old gate is automating a ceremony, and that most of what review was for should happen before the code exists. The papers above measure whether a second model catches errors. They do not settle whether every change should pass through one. The post's model choices, deepseek for writing and GLM for review, are one operator's configuration and not a finding.