Recursive Self-Improvement in AI Agents: What the Experiments Actually Show

Asking a coding agent to fix a bug in your application is routine by now: it opens files, edits a few lines and runs the test suite. Change the instruction to "improve the software you use to do this work" and the target becomes the agent itself: how it locates files, which tools it calls, how it recovers from a failed attempt, and whether the resulting version can produce the next improvement. That last question is what recursive self-improvement (RSI) is about. This article separates self-modification from real self-improvement, walks through the main experiments and their numbers, and gives you a set of questions and a small experiment design for judging such claims yourself.

Self-modification, self-improvement and recursion

Prompting a model to double-check its answer can produce a better reply, but that does not make the model any more capable on the next task. Only that single output changed. To reason clearly about RSI, three levels need to be kept apart:

• Self-modification: some part of the system changes.
• Self-improvement: that change yields a measurable benefit.
• Recursive self-improvement: the new capability strengthens the very machinery that produces later improvements.

A concrete case helps. If an agent gets better at searching for files, it finishes tasks more easily; that is self-improvement. If the same better search also helps it understand its own codebase, and so makes it better at editing itself, the gain loops back into the improvement process; that is the recursive part.

It also matters what "itself" refers to. A deployed AI system is rarely just a language model. The model sits inside tools, memory, operating instructions and orchestration code, and that surrounding system can change a great deal while the weights stay fixed. Evolution in that outer layer is still evolution, but any claim about self-improvement should state which layer changed: weights, agent code, prompts, tools or the improvement procedure itself.

The Gödel Machine: prove the benefit before changing

The Gödel Machine, proposed by Jürgen Schmidhuber, is the classic mathematical framing. The system may rewrite any part of its own software, including the component that searches for proofs, but only after it has proven that the rewrite increases expected utility under its defined goals and assumptions.

That guarantee is narrower than it sounds. It does not promise that every change helps in the real world under every condition; it holds only relative to the chosen axioms, the model of the environment and the definition of utility. Finding a formal proof that a given modification is beneficial can also be computationally very hard.

Most current experiments therefore take an empirical route: rather than proving a change is good in advance, they run the modified system and measure how it performs. That is far more practical, but it shifts the burden onto evaluation. The obvious follow-up question is whether the thing being measured is really the kind of growth you care about.

STOP: using an improver on itself

The Self-Taught Optimizer (STOP) starts from an "improver", a program that calls a language model to propose and score improvements to other programs. The improver is then pointed at its own source code, and the updated improver is used in the following round to produce further improvements.

The notable finding is that the loop does not behave the same way across models. With GPT-4, average performance went up over iterations; with GPT-3.5 and Mixtral, it went down. Because the underlying language model never changes, the authors are explicit that their work is not full RSI.

The lesson for practitioners is simple: iterating a process does not guarantee progress. A weak improvement method applied to itself can just as easily reinforce its own mistakes on every pass.

Gödel Agent: rewriting the agent's own logic

Gödel Agent lets a language model modify the agent's own reasoning logic and behavior code at runtime. It is evaluated on reading comprehension, mathematics and knowledge-based question answering, with optimization done on a validation set and the resulting agent measured on a separate test set, which is the right way to avoid tuning to the test.

The headline numbers need careful reading because the variants run under different conditions. On MGSM, Meta Agent Search reports 53.4% accuracy and the restricted Gödel-base variant reports 64.2%, which is a like-for-like comparison. The unrestricted Gödel-free variant reaches 90.6%, but it operates under different constraints and should not be presented as the next step on the same comparison.

What stands out technically is less the score than the design choice: the method the agent uses to solve problems has itself become software that can be searched over and modified.

SICA: a coding agent that edits its own codebase

A Self-Improving Coding Agent (SICA) makes the question concrete. The agent modifies its own code, and each new version is scored on how well it solves tasks, how long it takes and what it costs.

On 50 randomly chosen tasks held constant from SWE-bench Verified, performance rose from 17% in the first iteration to a peak of 53% at iteration 14, and the final iteration landed at 51%. Improvement, in other words, was not monotonic. The authors estimate that the 15-iteration run cost roughly $7,000 in API usage.

Two details temper the headline. First, the authors point out that a five-minute limit per task may have depressed the starting score, and much of the early gain came from faster file-editing tools that let the agent finish more work within that same limit. Second, the improvements the agent discovered look like ordinary tooling work: precise edit operations instead of rewriting whole files, and finding functions and classes by walking the parsed syntax tree (AST) of the code rather than by plain text search.

None of this makes the result trivial, but going from 17% to 53% does not mean the system's general intelligence nearly tripled. What was measured was performance on one specific task set, under one time limit, and much of the gain is exactly what a human engineer would add to a coding agent's toolbox.

Darwin Gödel Machine: an archive instead of a single line

The Darwin Gödel Machine (DGM) drops the idea of a single chain of versions. It keeps an archive of agent variants and lets new branches grow from any of them. A variant that scores lower today can still be the parent of a later, more useful change, which is the open-ended, evolutionary element in the name.

Reported gains, according to the v3 paper, include an increase from 20% to 50% on the SWE-bench subset evaluation and from 14.2% to 30.7% on the full Polyglot benchmark. The study also runs transfer experiments with other models and benchmarks not used during development. Those suggest some of the gains generalize beyond the development tasks, though they fall short of showing broad improvement across all domains. As with the other agent-level work, the foundation models stay frozen; only the agent software around them evolves.

Cost is part of the picture too. The authors estimate one DGM run on SWE-bench at about $22,000, against roughly $10,000 for each baseline run. Ablations that isolate the contribution of individual components therefore do not fully answer whether DGM would still win under an equal budget.

The most transferable insight is about search strategy: discarding every version that looks like a regression can cut off the route to a better system, because good designs sometimes pass through weaker intermediate steps.

When the weights, or the improver, change

Agent-code experiments are not the whole field. SEAL (Self-Adapting Language Models) studies a model that generates its own fine-tuning data and update directives, including instructions about how the adaptation should be carried out. Training on those self-generated directives makes lasting changes to the model's weights, so self-improvement research is clearly not confined to agent scaffolding. Still, the fact that weights change says nothing by itself about unbounded or accelerating gains.

Hyperagents tackles a different limitation. It merges the task agent and the meta-agent that edits it into one editable program, so the mechanism that produces future improvements can itself be changed. The authors report that some of these meta-level improvements transfer between task domains and accumulate across runs. Together, these studies move the conversation from "can an AI edit its own code?" to "how far can it improve the process by which it develops itself?"

Four questions for any "it got better" claim

When a self-improvement curve goes up, it is worth asking what exactly went up.

Better in which respect?

Accuracy may rise while cost and latency rise with it. A trade-off that is fine for a research objective can be unacceptable in a product, so look at all the metrics, not just the headline one.

Better on which tasks?

Gains on tasks that are repeatedly used to pick the next version are weaker evidence than gains on a held-out final test nobody touched during development. Every time a test score informs another selection decision, the process drifts toward fitting that test.

Which version is better?

An archive that keeps the best result will show a rising "best so far" line even if most new candidates are worse. Check the distribution of candidates, not just the maximum.

Is it getting better at improving?

Solving more tasks can hint at better self-improvement ability, but they are different metrics. A stronger experiment checks whether a new version produces better successor versions than its predecessor did, under the same budget.

These questions are not meant to deny progress. They are how you define progress precisely enough to recognize it.

A self-improvement experiment you can run

A realistic entry point for an individual developer or small team is not to open up an entire system to self-modification, but to pick one narrow development tool and constrain it tightly. Take a test-generation tool for a Java codebase as an example:

• Fix what cannot change: the tool may not modify the application code or the evaluation tests.
• Define what can change: only its own file-scanning strategy, its instructions and its test-generation workflow.
• Score each version on several axes: tests that compile, bugs detected, mutation-testing results (whether the generated tests catch deliberately injected code changes), cost and execution time.
• Separate selection from final evaluation: choose versions using validation tasks, and keep a set of final evaluation tasks untouched until the process is finished.
• Track the whole population, not only the current best, so you can see whether candidates are generally improving.

Treat this as an experiment design, not a promise of results. Using open models or free quotas can lower the running cost, but cheaper runs do not prove the changes are useful. Look for one clearly measurable gain first, and widen the scope only after you have it. The same evaluation discipline applies to any agent you ship; our guide to bounded agentic loops in TypeScript covers the runtime side of keeping such loops under control.

Better agents are not an intelligence explosion

So can AI design better AI? In the experiments above, yes in a specific sense: AI systems helped produce more capable agents, and several applied that process to their own software. What they do not show is a chain of improvements that speeds up with each iteration, generalizes across domains and runs independently of human design choices. Dismissing the work as "just prompt engineering" misses the real results; calling it the start of an intelligence explosion overstates them.

Key takeaways

• Always ask which layer changed: weights, agent code, prompts, tools or the improver itself.
• Formal guarantees such as the Gödel Machine's hold only relative to their assumptions; empirical approaches trade proofs for evaluation, so evaluation quality decides everything.
• Iteration alone is not progress: STOP improved with one model and regressed with others.
• Many measured gains (SICA, DGM) come from better tooling around frozen models, on specific benchmarks, at substantial cost.
• Keep held-out tests, watch the whole candidate population, and compare under equal budgets.

The hard problem is not letting an AI modify its own code. It is reliably demonstrating that a modification is genuine progress, and carrying that progress into the next round of improvement.