rsi.org.ai

The map

The map of recursive self‑improvement

What the field has learned so far, as a hierarchy: the principles, how to build on each one, how to test it, and what is still open. Every claim links to its source in the list.

It has no fixed procedure. It is rewritten whenever new entries change the picture, and every change is logged in the journal. First drafted with Claude on 30 October 2026 from the entries in the list; principle 7 is the editor's own position.

1

One loop, step by step

In 2025 a coding agent rewrote its own code 80 times and went from solving 20% of a set of real GitHub issues to 50%. This is what each round did.

  1. Start small. The first agent is a short Python program around a language model (Claude 3.5 Sonnet) with two tools: run a shell command, and view or edit a file. It solves 20.0% of SWE-bench issues.
  2. Pick a parent. Every agent made so far is kept in an archive. The loop picks one, usually a high scorer, but any agent can be picked, and agents with few children are favoured.
  3. Read its own record. The parent reads the logs of its own benchmark runs and writes down one feature it should add to itself, for example "edit files by replacing exact strings instead of rewriting whole files".
  4. Edit itself. The parent implements that feature in its own source code. The result is a new agent.
  5. Check. The new agent works on coding issues it has to solve for real. Agents that no longer run, or can no longer edit code, are thrown away. The rest join the archive with their score.
  6. Repeat. After 80 rounds the best agent solves 50.0%. The features it added include finer-grained file editing, summarizing its context when it runs out of room, and generating several patches and ranking them.

Why this counts as recursive. The agent's job is editing code, and improving itself is also editing code. A better coder is therefore a better self-improver, so each gain helps produce the next one. The authors of Hyperagents point out that this match is what made the loop work, and that it does not hold outside coding.

What stayed fixed. The language model, the benchmark that scored every change, and the rule for choosing parents. Every self-improving system leaves some parts fixed. The levels are defined by which parts.

Source: Darwin Gödel Machine (Zhang et al., 2025), sections 3–4.

2

The principles

7 principles. Each says why it holds, with the result behind it; how to build on it, with systems that do; how to test it; and what is still open.

  1. 1A change counts only if something outside the loop confirms it.
    • Run the changed system on tasks with real tests
    • Choose changes on one set of tasks, judge them on another
    • Write the tests first, then freeze them
    • When there is no test, compare candidates or evolve the grader against a human anchor
  2. 2To keep improving, the loop has to improve its improver.
    • Let the agent edit its own code, including the part that edits
    • Make the procedure that makes changes editable too
    • Train the judge or the task-setter, not only the solver
    • Learn how to improve from earlier improvements
  3. 3Keep the stepping stones.
    • Keep every version in an archive, and sometimes build on weak ones
    • Judge a version by how its descendants do
    • Share experience across lineages
    • Keep lessons as records that grow and get edited
  4. 4The gain must hold on tasks the loop never saw.
    • Keep held-out benchmarks for the final judgment
    • Reject edits that only fit the benchmark
    • Test with other models
  5. 5Recursive does not mean explosive. Returns and cost decide the speed.
    • Count search, execution and human effort separately
    • Shorten the trip around the loop
  6. 6Safety has to survive every update.
    • Run changes in a sandbox, with people watching
    • Compare each self-update with a copy that did not update
  7. 7Fix the data, let the execution change.Editor's position
    • Make checkpoints inspectable records, not fixed steps
    • Change the representation or the execution, never both at once
    • Rules are append-only
    • The person chooses the task and owns the final judgment
    • Fill missing data first, then improve what limits quality

A change counts only if something outside the loop confirms it.

Why
Models asked to correct their own reasoning with no outside feedback often get worse (Huang et al.). Optimizing hard against a learned grader first raises and then lowers real quality (Gao et al.). The Darwin Gödel Machine kept a change only after the new agent solved real GitHub issues, and went from 20% to 50% (DGM).
How to build
  • Run the changed system on tasks with real tests. Keep a change only if the new version passes tests it did not write. Absolute Zero checks the tasks it invents by running the code.Darwin Gödel MachineSICAAbsolute Zero
  • Choose changes on one set of tasks, judge them on another. AIDE² keeps the changes that do best on hidden evaluations, then reports results on four held-out benchmarks.AIDE²
  • Write the tests first, then freeze them. HarnessPro generates tests from public requirements and freezes them before it starts improving harnesses.HarnessPro
  • When there is no test, compare candidates or evolve the grader against a human anchor. Harness² contrasts candidate edits on the task itself (Propose–Probe–Compose). The Red Queen Gödel Machine evolves its graders together with its agents, anchored to human IMO grades.Harness²The Red Queen Gödel Machine
How to test
Report success on tasks with executable tests, such as SWE-bench Verified and Polyglot (DGM). Keep the final evaluation hidden from the loop. Measure reward hacking directly: in AIDE² it fell from 55% to 32% during the run.
Open
How do you check work that has no test, such as open-ended research? When frontier agents got six days to answer the questions of two unpublished NeurIPS submissions, the original authors rejected both results (case studies).

Cites 10 entries, 6 with a published record

To keep improving, the loop has to improve its improver.

Why
With the part that makes changes held fixed, the Darwin Gödel Machine's "gains taper off quickly" (DGM). Repeated training on a model's own output "can reach a point of diminishing returns" (Multiagent Finetuning). Gains compound when the skill being improved is the skill that does the improving: for a coding agent, a better coder is also a better self-editor.
How to build
How to test
Run the same loop with the improver frozen and compare (DGM does this). Then test whether the discovered system is a better self-improver, not just a better solver: for AIDE², its improvement in that outer role was not decisively established.
Open
How many levels of self-editing are possible? Self-editing systems "must leave part of their own editing machinery untouched to stay stable", which caps the depth they reach at about two (Metaⁿ).

Cites 15 entries, 4 with a published record

Keep the stepping stones.

Why
When the Darwin Gödel Machine kept only its latest agent, one bad edit made every later improvement harder. Its best agent descends from ancestors that twice scored worse than their parents (DGM).
How to build
How to test
Remove the archive and keep only the latest version, as the DGM ablation does; compare tree-shaped and group-shaped search on the same budget.
Open
What does a large archive cost to keep and search, and when does that cost outweigh what it finds?

Cites 7 entries, 3 with a published record

The gain must hold on tasks the loop never saw.

Why
A loop gets better at what it measures, which may not be what was meant. AIDE² chose its changes on one set of AI research tasks, then matched or beat a human-built research agent on four held-out benchmarks, one of them weather forecasting.
How to build
  • Keep held-out benchmarks for the final judgment. Select on one set of tasks; report on another the loop never touched.AIDE²
  • Reject edits that only fit the benchmark. RRSI adds a critic that screens out benchmark-specific edits, and limits how many edits one candidate may bundle, with the limit tightening over time.RRSI
  • Test with other models. The agent the DGM found with Claude 3.5 Sonnet also helped other models; with Claude 3.7 Sonnet it went from 19.0% to 59.5%.Darwin Gödel Machine
How to test
Held-out benchmarks, a different model, and at least one task unlike the selection tasks.
Open
Leakage is easy: the Harness² release reports a validation run that downloaded a public JobBench rubric, and it leaves network access unrestricted by default.

Cites 4 entries, 3 with a published record

Recursive does not mean explosive. Returns and cost decide the speed.

Why
A loop speeds up only if each improvement makes the next one cheaper. If each doubling of software efficiency needs more than twice the research effort of the previous one, progress fizzles; if less, it runs away (Eth and Davidson). Current estimates say today's loops are not yet self-sustaining but are strengthening (The Economics of RSI).
How to build
  • Count search, execution and human effort separately. HarnessPro treats cost as an objective and returns lite, medium and heavy harnesses; its heavy mode gained 2.0 points at 26.1% lower cost than RHO.HarnessProSoL-Pi
  • Shorten the trip around the loop. The time one round takes is a neglected deciding factor (Ord).The Dynamics of Intelligence Explosions
How to test
Report the cost of every accepted improvement, round by round, and whether later improvements cost less than earlier ones.
Open
Do later improvements cost less than earlier ones in any real system? Measuring it requires per-round cost records.

Cites 5 entries, 1 with a published record

Safety has to survive every update.

Why
A system that rewrites itself can rewrite away its safeguards. Agents that keep updating their memory and tools drift toward unsafe behaviour: alignment erodes as memory accumulates (Shao et al.). It can also go the other way: AIDE²'s rate of reward hacking fell from 55% to 32% though nothing optimized for it.
How to build
How to test
Measure the same safety tests before and after every update, against a copy that did not update.
Open
A goal-seeking system will want to keep its goals (Omohundro), but proving that a self-modified successor is still safe is hard (Yudkowsky and Herreshoff).

Cites 7 entries, 2 with a published record

Fix the data, let the execution change. Editor's position

Why
The editor's working premise (rsi-design study): define a task by fixed data contracts, meaning the required records, the checkpoints where progress is inspected, and how each is judged. Then let models, prompts, skills and paths change freely to satisfy them. In the editor's words: "the system must be designed around data, because only the data is fixed in the process and output for any given tasks (forms and ratings, not content)".
How to build
  • Make checkpoints inspectable records, not fixed steps. A checkpoint says which state must become visible, not which actions produce it.
  • Change the representation or the execution, never both at once. Hold one side fixed so a gain can be attributed to the other.
  • Rules are append-only. No rule is updated or removed; new rules are added. An output cannot pass by deleting an inconvenient requirement.
  • The person chooses the task and owns the final judgment. The system pauses only for judgments that the task's owner has to make.
  • Fill missing data first, then improve what limits quality. Produce required missing records before polishing ones that exist but are rough.
How to test
Compare a representation change and an execution change on the same fixed inputs, each with the other held fixed, under the same rules and the same judges.
Open
The evidence is thin so far. AFlow searches explicit agent structures and ACE keeps incremental knowledge records, but neither isolates changes to the task's data structure as the main source of improvement. No reviewed experiment directly tests the missing-first rule.

Cites 2 entries, 2 with a published record

3

Where the field is

Systems in the list by level and year. 21 of the 26 Level 3–4 systems, the ones that change their own improver, appeared in 2025 or 2026. No system has reached Level 5.

LevelBefore 20232023202420252026All
1 · Retries·2·1·3
2 · Learns77114736
3 · Improves its improver·2141017
4 · Improves its own model··2529
5 · Builds its successor······