Recursive self-improvement: review questions

Ask three things: what object changes, who proposes and applies the change, and what signal accepts it. Those questions give four types: (a) the model designs and runs its own training and improves its own weights; (b) a system edits its own scaffold, code or prompts with frozen weights; (c) AI accelerates human-led research; (d) training on self-generated data or self-play, with a human-written update rule. Both (a) and (d) change weights; the difference is who designs the update. Most public "self-improving" systems are (b) or (d); as of 2026-10-15, no full public demonstration of (a) was found.

STaR treats it as an approximation to policy gradient on a 0/1 reward: wrong samples contribute zero gradient, so "keep the correct ones and run SFT" approximates one policy-gradient step, and the filter is the reward. ReST-EM writes it as EM: the M-step is reward-weighted maximum likelihood on samples from the previous model. Unlike online RL such as PPO, the sampling policy is fixed during this step, so data collection and optimisation are decoupled. The consequence: the verifier defines what gets optimised, and the model learns toward whatever the tests reward.

Song et al. define the generation-verification gap: how much the true score rises when samples are reweighted by the verifier. If the update learns the reweighted distribution to within $\varepsilon$, one round's gain is about the gap plus or minus $\varepsilon$. They measured the gap falling to near zero within two or three rounds, non-positive gaps for small models under most verification methods, and falling pass@k at large $k$. ReST-EM sees diminishing returns after a couple of iterations; Self-Rewarding ran only 3 iterations and its authors expect saturation. Without new information from outside, the loop has nothing to learn.

This is a teaching assumption. Accepted samples make up $0.40+0.60\times0.10=0.46$, of which $0.40/0.46\approx87\%$ are correct. If fine-tuning imitates them perfectly, true correctness reaches 87% while the tests show 100%. In the next round the tests treat "correct" and "wrong but passing" alike, the gap is 0, and the loop stops at 87%. With a 30% false-accept rate the ceiling is 69%; at 2% it rises to about 97%. Raising the ceiling means strengthening the verifier, for example with hidden tests and edge cases.

Neither gives the solver a learning signal. The proposer's reward is 0 when the average success $\bar r$ is 0, and $1-\bar r$ otherwise. $\bar r=0.5$ earns 0.5, $\bar r=1$ earns 0, and $\bar r=0.25$ earns 0.75, so the highest reward goes to tasks solved only occasionally; with $G$ attempts the maximum is $1-1/G$. "Zero" means no human-curated tasks or answers; a pretrained model and a Python executor are still required.

Both change code; the LLM weights stay fixed. AlphaEvolve evolves programs against a human-written evaluation function; the kernel tiling it found cut Gemini training time by 1%, including training the models behind AlphaEvolve, and the authors say that feedback cycle runs on the order of months. DGM has a coding agent edit its own repository and keeps every working agent in an archive; after 80 iterations SWE-bench goes from 20.0% to 50.0%, but the authors state it is limited by the underlying FM and leave rewriting the training script to update the FM as future work. To be type (a), the object would have to be weights, the update designed by the model, and the acceptance signal out of the edited system's reach.

For each model, fit a logistic curve of success against the (log) human time of each task; the human time at which success is 50% is the horizon. If every task group succeeds more than half the time, the 50% point can only be extrapolated beyond the longest task, and one success more or less can change the estimate several-fold; METR's suite has no task over 30 hours. METR also said on 2026-05-19 that TH1.1 is essentially saturated and that at least 16% of successes on tasks of 8 hours or more were illegitimate; correcting for noise in task lengths could lower horizons by about another 30%.

First classify it: a task-level measurement, a lab determination against a threshold, a self-reported lab number, or a statement or prediction. Then ask five things: who measured it and can outsiders check it; whether the unit is code share, agent hours, researcher uplift or the overall pace of progress; how much humans intervened; how much compute grew over the same period; and whether the instrument is saturated, whether cheating was reviewed, and where any trend break was placed. Finally compare with existing anchors: as of October 2026, every estimate that gives an overall progress multiplier is below 2x (Anthropic self-reported, about 1.5x quoted by METR), Google DeepMind found no significant end-to-end acceleration on 2026-10-13, and no lab has declared a formal threshold crossed. Also remember that in METR's controlled trial, developers' perception and the measurement differed even in sign.