Review 18 October 2026 Read
Self-training wore down every code a model tested, with or without review. The case against AI self-review is not in the data.
In brief. The paper, When AI Reviews Its Own Code: Recursive Self-Training Collapse in Code LLMs, trains four small open code models, five times in a row, on code they generated themselves, and filters that code in different ways before each round. Every version ends below where it started, whatever the filter: none, a check that the code compiles, simple text rules, or the model scoring its own code. That result is well supported. The paper then suggests that stable training “requires exogenous verification rather than model-coupled self-review”, and its title and abstract present AI self-review as the weak point. Its own main results do not show that: on HumanEval+, one of its two primary benchmarks, the model scoring its own code finished best for three of the four models, and every result comes from a single training run.
What we did. We read the full text of version 2 as published on arXiv, including all fifteen appendices. We reran nothing; the paper does not mention a code release. Every claim in this review is therefore Read: it rests on reading the paper. Three AI models from different labs checked our account against the paper and raised objections of their own, including four points where they found us too harsh. Every quotation and number below was checked against the paper’s text by a script. arXiv’s HTML edition, which we read, shows only two of the paper’s fourteen figures; we read the other twelve by their captions, and no caption describes a series of the binary filter’s acceptance scores. Our corrections policy is to send authors our account five working days before we publish; this time we did not. We are sending the authors this review on the day it is published. If they show us where we have misread their paper, we will correct this review, and with their permission we will publish their reply.
01
What the paper claims
- Recursive fine-tuning on self-generated code degrades code models: “every tested recursive regime falls below its own starting point” (Abstract).
- Filters that do not depend on the model (“exogenous” gates) “preserve executable validity and sometimes reduce decline” (Abstract).
- Filters that use the model’s own judgement (“AI self-gates”) “can look strong early but later lose their filtering effect. In the clearest case, the binary self-gate enters a rubber-stamp regime where acceptance scores rise while benchmark correctness falls” (Abstract).
- A theorem: if the model’s own reviewer gives the same score to everything the model is likely to write, filtering by it is the same as not filtering (Theorem 2.3).
- The conclusion, stated as a suggestion: “These results suggest that stable recursive code LLM training requires exogenous verification rather than model-coupled self-review” (Abstract). §4 puts it as “Our results suggest that stable recursive training requires verification signals that remain externally grounded”.
02
What the researchers tested
Four small open code models (SantaCoder 1.1B, StarCoder2-3B, Qwen2.5-Coder-1.5B, Code Llama-7B). In each of five rounds, the current model writes code for a fixed set of prompts, a filter keeps 5,000 samples, and the model is fine-tuned on them. The filters are: none; Python’s compile check; two fixed text rules (limited repetition, at least 50 tokens); the model’s own perplexity; and the model’s own score for “good” against “bad”. Performance is measured on standard coding benchmarks, mainly HumanEval+ and MBPP+.
Two names need care. The “human-style” gates are not people: the paper calls them “automatic proxies, not literal manual review”. And the “AI review” is not a separate reviewing model or a prompted code review: it is the generating model scoring its own samples. Prompted reviewers are described in an appendix but “not used as main filtering methods”.
03
What our review questioned
- Which filter came out best. At round 5 on HumanEval+, the model scoring its own code was best for SantaCoder (0.104 against 0.079 for the compile check), StarCoder2 (0.122 against 0.092 for the text rules) and Qwen2.5-Coder (0.122 against 0.098 for the compile check); the paper says so (§3.4). For Code Llama the compile check was best. On MBPP+, no filter at all was best for StarCoder2 and Code Llama. The paper’s own summary is that “no review policy consistently performs best” (§3.2), and its appendix that compile and static filters “are still too weak to guarantee semantic robustness”.
- The “rubber-stamp” case. The self-scoring filter keeps the top 25% of samples by design, so its acceptance rate is 0.25 in every round (Table 9). No table reports its acceptance scores rising. The rising series the paper does report is for the perplexity filter. Part of the paper’s description does have numbers behind it: on MBPP+ the binary filter looks strong early and then falls, for StarCoder2 from 0.278 to 0.066 by round 5 (Table 12). What has no number is the claim that its acceptance scores rise.
- One run per setting. The appendix titled “Robustness Across Additional Runs” reports exactly the same numbers as the main table and is labelled “single-seed”. No variation between training runs is reported anywhere, so the gaps between filters, often a few hundredths, cannot be told apart from chance. In fairness, the self-scoring filter’s round-5 lead on HumanEval+ points the same way in three of the four models, which is weak but consistent evidence.
- What “executable” means. The paper’s execution measure counts code that fails only on a missing import as a pass. Strict success with the compile check is about 11 to 12% (Table 8).
- No comparison with ordinary training. No run fine-tunes the same models on the same number of fresh, human-written samples, so part of the decline may be ordinary damage from repeated fine-tuning on a small set of prompts whose origin and size the paper does not describe.
- Filters that differ in more than one way. The fixed filters accept about nine in ten samples; the self-scoring filters keep one in four from a pool four times larger (§3.1, Table 3). Whether the rule comes from the model is mixed up with how hard each filter selects.
- Tables that do not add up. In the appendix experiment with a small share of fresh verified data, training with no filter kept the most of its starting score (0.364, against 0.247 with execution filtering and 0.180 with fresh data added); the text notes the filters’ gain in valid code but not this ordering, and the model is not named (Table 5). None of those three values matches any trajectory in the full per-round tables. In the noise experiment, the share of samples accepted (about 0.5) cannot follow from flipping 5 to 20% of a gate’s decisions (which would leave about 0.74 to 0.86), the change column is never defined, and the results go up and down as noise rises rather than in one direction (Table 6).
- The theory. The theorem is correct, but only under its own premise that the self-reviewer has stopped telling samples apart, and the experiments do not measure whether that happened for the binary filter. The main-text statement of the second result (Proposition 2.1) relies on an identity that does not hold for a general matrix; the appendix proves a narrower version, and a third result (Lemma 2.5) is stated in the main text with a stronger bound than the appendix proves. None of these results is tested against measurements in the paper.
- Smaller points. The main results table shows the perplexity filter for Code Llama, although its caption promises the strongest self-scoring filter and the per-round table gives the binary filter a higher score (0.1585 against 0.1341). One reporting column, “filter pass rate”, measures different things for different filters, and two appendix passages cite the wrong figure for the pass rates.
04
Which objections survived checking
| Objection | Raised by | Outcome | Checked against | Label |
|---|---|---|---|---|
| The data do not show exogenous filters beating self-scoring; the conclusion goes beyond them | Our account; DeepSeek; Grok | Held (the paper hedges with “suggest”) | Table 2; §3.2, §3.4; Abstract; §4 | Read |
| No numbers show the binary filter’s acceptance rising | Our account; DeepSeek; Grok | Held | Table 9; App. H, K | Read |
| Single runs; the “additional runs” repeat the main table | Our account; DeepSeek; Grok | Held | Tables 2 and 7 | Read |
| “Executable validity” counts import errors as passes | Our account; DeepSeek; Grok | Held | Table 8 | Read |
| No filter retained most in the fresh-data experiment; the values match no other table | Our account; Grok; GLM | Held | Tables 5, 11-14 | Read |
| No same-recipe run on fresh human-written code | GLM | Held | §3.1, App. N | Read |
| Filter type is confounded with how hard each filter selects | GLM | Held | §3.1, Table 3 | Read |
| The noise experiment’s acceptance shares do not follow from its flip rates | GLM | Held | Table 6 | Read |
| Lemma 2.5’s main-text bound is stronger than the proved one | GLM | Held | Lemma 2.5, Theorem D.2, proof F.2 | Read |
| Results in the noise experiment go up and down as noise rises | Our account; Grok | Held | Table 6 | Read |
| The theorem holds only under an unmeasured premise | Our account; DeepSeek; Grok | Held | Assumption 2.2, Theorem 2.3 | Read |
| Proposition 2.1 rests on a false identity in its general form | Grok (sharpening our account) | Held | Prop. 2.1, Prop. E.1, proof F.3 | Read |
| Table 2 does not follow its caption for Code Llama | Grok | Held | Table 2, Table 14 | Read |
| Our account: the compile check’s pass rate of 1.000 contradicts its raw pass rate | Grok, against us | We were partly wrong: the column reports the accepted set for those filters. The perplexity mismatch stands. | §3.1, Tables 3 and 9 | Read |
| Our account: we should say the paper hedges its conclusion | Grok, against us | Accepted; the quotations above now include “suggest” | Abstract, §4 | Read |
| Our account: the text mentions the filters, not only the fresh data, in Table 5 | GLM, against us | Accepted; reworded | Appendix C.1 | Read |
| Our account: credit the self-scoring filter’s consistent lead and the numbers for its MBPP+ instability | GLM, against us | Accepted; both now stated | Tables 11-14 | Read |
05
What you can take from the result
- Engineers. Fine-tuning a code model repeatedly on its own unchecked output made it worse in every setting tested here, and filtering by compilation, simple rules or the model’s own scores did not stop that. If you train on generated code, keep real code in the mix and check outputs by running tests, which this paper did not try as a filter.
- Researchers. The interesting comparison, between a filter that cannot drift with the model and one that can, needs repeated runs with intervals, a filter that executes tests rather than only compiling, and a self-reviewer that resembles AI code review as practised. The theory gives a clean statement of when self-review must fail; whether real self-reviewers reach that state is the open question.
- Decision-makers. The paper does not show that AI code review fails where human review succeeds. Its experiments contain no human review and no AI reviewer of the kind sold today. It does show that a training loop fed with its own output, filtered only by cheap checks, gets worse.
06
What remains unknown
Whether the differences between filters survive repeated runs; what the twelve figures we could not see show (we read their captions); how these small models and short loops relate to training at the scale of public code repositories; and whether a filter that runs tests, or a separate reviewing model, would hold the line where these filters did not.
07
The record
Our account and its two versions, the reviewers’ returns, the decision on every objection, the scripts that checked every quotation and number, and the extracted text of the paper are kept with this review and are available from the editor on request.
08
Corrections
None yet.