What Does a Successful Self-Improvement Pass to the Next Round?

DeepMind reports that AlphaEvolve found a better way to divide a large matrix multiplication into subproblems, producing a 23% speedup for a Gemini kernel and a 1% reduction in overall Gemini training time. A searched program had delivered a practical training benefit. The percentages describe different quantities at different scopes; they do not reveal the kernel’s original share of training time. AlphaEvolve’s official announcement

That success leaves a more efficient program in use. Following recursive self-improvement adds a further question: what does the system inherit that helps it find the next improvement? The cited training result does not measure whether the program proposer subsequently becomes more capable.

SEAL, DGM, AlphaEvolve and MetaRSI let us follow this question through concrete objects. For each, trace what changes, what feedback selects it, and what the reported result actually measures. The return path matters as much as the forward path.

This editorial teaching diagram organizes relationships from the cited reports. Read across a row, then follow its return arrow to the object receiving feedback. Arrows show processes, not effect sizes; row positions distinguish studies. In the AlphaEvolve row, the deployment arrow and the return to later prompts answer different questions.

Two paths out of the successful program

In AlphaEvolve’s described search loop, Gemini models propose programs. Automated evaluators verify, run and score them, and an evolutionary program database determines which programs appear in future prompts. Earlier search therefore changes the material available to later proposals. Official mechanism

Deployment takes a program into another process. In the opening example, the improved matrix kernel accelerates Gemini training. The diagram’s downward arrow connects the local kernel result to that whole-training outcome. Its return arrow instead follows programs back into search prompts.

Both routes carry something useful forward, but they leave different evidence. The announcement reports a training-efficiency gain and describes program reuse in later search. It does not present a matched test of subsequent proposal capability for this kernel result. The diagram’s “unmeasured” preserves that open question; it assigns no zero benefit and implies no update to the proposing models’ weights. This is our reading of the announcement’s measurement scope.

Where the return arrow lands

SEAL’s knowledge-incorporation loop makes the distinction between an artifact and a learned method especially clear. A model turns a supplied passage into implications or restatements, then LoRA fine-tuning applies that material to its parameters. The adapted model answers passage questions with the passage removed from context. Generating the material alone would leave the parameter-update step undone. SEAL v1, knowledge incorporation

There is also an outer learning loop. Performance after adaptation supplies the reward used to train self-edit generation. The paper reports that material generated after this training produces better no-context question answering than passage-only fine-tuning or material generated without prior reinforcement learning. One update incorporates knowledge; the other learns how to prepare future learning material. Reducing SEAL to “it changes weights” would hide the destination of its return arrow. SEAL v1, methods and results

DGM gives the next round a different inheritance: an altered coding-agent implementation around frozen foundation models. A concrete discovered change adds viewing by line and editing by string replacement in place of whole-file viewing or replacement. That code is part of the agent used for later tasks, including editing its own repository. DGM v1, discovered tools

The inheritance can also remain in a branch. A selected parent examines its benchmark logs, proposes a feature and implements it in its own codebase. The archive retains functional variants, including some that initially score below their parents and later become stepping stones. Thus DGM can carry forward an option whose value appears only after another modification. Its outer archive maintenance and parent selection remain fixed in v1. DGM v1, archive mechanism

The diagram’s return arrows now have distinct destinations: training SEAL’s generation method, selecting DGM’s later parents, and supplying AlphaEvolve’s later prompts. Showing that an earlier result re-enters work identifies a mechanism. Whether that mechanism makes the next improvement step more productive remains a question for the measurements.

What the feedback is allowed to select

SEAL’s reward comes with a task attached. In the knowledge experiment, passages are paired with questions and reference answers; GPT-4.1 grades the adapted model’s answers. The current instantiations require explicit downstream evaluation tasks, so the paper does not demonstrate the same outer training loop on unlabeled corpora. The reward tells us how well an edit serves the supplied task. SEAL v1, evaluation and limitations

Its retention test asks a separate question about what survives. After each new passage edit, the model is tested again on earlier tasks. Earlier-task performance declines as edits accumulate, although multiple updates are possible without complete collapse. Retention was not explicitly optimized. A successful new edit can therefore coexist with loss of older knowledge; the positive single-passage result does not settle continued accumulation. SEAL v1, sequential edits

DGM separates archive admission from immediate performance improvement. Candidates must compile and retain code-editing functionality to enter the archive; admission does not require beating the parent’s score. Coding results inform the search, and the paper reports positive comparisons for both continued self-modification and archive exploration. Interpreting coding performance as self-improvement capacity still uses the authors’ explicit proxy assumption: editing the agent itself is a coding task. These controls support that coding setup without establishing general research capability. DGM v1, admission, controls and limits

MetaRSI makes additional parts of the improvement method writable: policies for diagnosing failures and proposing changes, and the scheduling policy governing operation order. Its target includes data and the execution harness—the prompts, tools and other scaffolding around the model. Model-state changes are also available on the self-hosted open-weight target; provider-interface targets use the data and harness route. A fixed, deterministic compiler assembles attempts, trajectories and outcomes into the learning signal. MetaRSI v2, writable objects and signal

Every model-driven role in the reported MetaRSI experiments uses the target model itself, but success still comes from environment verifiers: coding tests or exact/numeric answer checks. The stated contract keeps sealed evaluation, held-out tasks, release rules and resource accounting outside all writable targets, including the meta policies. The reported outcome is the released successor, scored once per term on the sealed split, rather than the best archived candidate. Using the target model in every role therefore does not remove the external correctness standard. MetaRSI v2, experimental protocol

Compare the next step from the same starting system

MetaRSI then tests the question that the kernel’s deployment percentages leave open. Term 1 produces a released successor, S1. Term 2 forks that same S1: one branch uses the original improver; the other uses the meta-updated improver. Both receive the same next-term budget and sealed splits. The updated improver produces a larger average benchmark gain. MetaRSI v2, same-successor control

The starting point is what makes this comparison informative. A later, higher system score alone would leave ambiguous how much came from starting with a better system. Here both branches start with S1, so the comparison tests which whole improver makes the more productive next step under the matched conditions. It does not separately identify the causal contribution of each proposal-policy or scheduling-policy edit. This is local positive evidence on executable coding and closed-form reasoning.

The five-term trace places a further limit on that result. The updated path keeps a larger cumulative gain, while gains per term decline on both paths. Each term receives a fresh allocation of the same budget; improvement and meta budgets are tracked separately. A more productive matched next step can coexist with diminishing later increments. The trace does not show indefinite acceleration. MetaRSI v2, accounting and five-term results

Back at the matrix kernel, the deployment benefit is already reported, and the database’s route into later prompts is described. What remains unmeasured is the proposal capability on the other end of that return path. MetaRSI’s fork illustrates the difference between documenting inheritance and measuring a subsequent improvement step; it does not turn these studies into a ranking.

The useful comparison follows the same relationships while keeping each result’s scope: what returned, which object received it, and what changed at the next measured step? The selected QA, coding and efficiency results provide neither a common performance or net-cost scale nor evidence of general recursive improvement across open-ended work.

This article interprets author-reported results from SEAL v1, DGM v1, DeepMind’s official AlphaEvolve announcement and the MetaRSI v2 paper. This article provides no independent replication results or common cross-system benchmark.