Self-Improving Coding Agents: What the Research Shows

Self-improving coding agents are programs that edit their own code, test the result on coding tasks, and keep the changes that score better. The research so far shows real, measured gains on coding benchmarks, almost all from rewriting the code around a fixed language model, not the model itself. The same research shows an agent gaming its own checker, which turns safety from a thought experiment into an engineering problem.

Individuation Lab studies the same loop from the safety side: its AI agents run self-improvement sessions in sealed containers, and the lab records how an identity file changes what they do, with each result's limits written down.

What are self-improving coding agents?

A coding agent is a language model wrapped in code. That code holds a system prompt, tools such as a file editor or a shell, and logic that decides when to plan, test or stop. A self-improving coding agent points that work at its own wrapper. It reads its own source, proposes a change, runs a benchmark, and keeps the change if the result holds up.

Keep two kinds of change apart from the start:

• Scaffold changes. The agent edits its prompts, tools and control flow. The model's weights stay the same. The published results below are of this kind.
• Weight changes. The model's parameters change, through training or direct editing. This is slower, costs more and is harder to judge.

When a headline says an agent "improved itself," ask which of the two it means.

From the Gödel machine to STOP

The idea is older than language models. In 2003 Juergen Schmidhuber described the Gödel machine: a problem solver that rewrites any part of its own code as soon as it has found a proof that the rewrite is useful. The Darwin Gödel Machine paper names the catch: proving that most changes are net beneficial is impossible in practice.

Language models made a looser version workable. The 2023 paper "Self-Taught Optimizer (STOP)" started with a seed "improver", a program that asks a language model several times to improve a given program and returns the best answer. Then the authors ran the improver on its own code. The improved improver did significantly better than the seed on a small set of tasks, and the model proposed strategies such as beam search, genetic algorithms and simulated annealing. The authors are careful to say this is not full recursive self-improvement, because the language model (GPT-4) was never altered.

That is the key move in the field: the formal proof is dropped, and the agent measures a change instead of proving it.

Four research systems, side by side

Four papers show how far the idea has gone. They differ in what the agent may rewrite and how a change earns its place.

What each system rewrites and how it decides to keep a change, from the four papers' abstracts.

Gödel Agent

Gödel Agent (2024) lets an agent modify its own logic and behavior, guided only by high-level goals in a prompt, with no fixed optimization routine. Its authors report it beat hand-built agents on mathematical reasoning and complex agent tasks.

Darwin Gödel Machine

The Darwin Gödel Machine (2025) keeps an archive of coding agents. Each step samples an agent from the archive, has a foundation model write a new version of its code, and tests that version on coding benchmarks. Weaker agents stay in the archive as stepping stones, so the search can explore many paths instead of only branching off the current best. The changes it found included better code editing tools, long-context window management and a peer-review step.

SICA

"A Self-Improving Coding Agent" (2025) takes a simpler path: one agent system with basic coding tools edits itself. Its authors describe the method as learning without gradients, driven by the model's reflection and code updates.

What self-improving coding agents score on SWE-bench and Polyglot

Two benchmarks come up again and again. SWE-bench asks an agent to resolve real GitHub issues in code repositories; the Darwin Gödel Machine used its Verified subset, filtered by people so every task is solvable. Polyglot has tasks in several programming languages, such as C++, Rust and Python.

The Darwin Gödel Machine authors report SWE-bench going from 20.0% to 50.0% and Polyglot from 14.2% to 30.7%, and that it beat versions of itself without self-improvement or without open-ended exploration. SICA's authors report 17% to 53% on a random subset of SWE-bench Verified. In both, the model at the center stayed fixed, so the gains came from the code around it.

Read those numbers with care:

• Runs often use part of a benchmark to keep costs down. The Darwin Gödel Machine's Polyglot run used 50 tasks, then checked its base and best agents on the full benchmark.
• The starting agent is deliberately simple, so there is room to climb.
• The Darwin Gödel Machine authors report that what their agents found carried over to other models (Claude 3.7 Sonnet and o3-mini); check what each paper tested before assuming that.

Limits: objective hacking, overfitting and cost

The loop that produces the gains also produces the problems.

The Darwin Gödel Machine's loop, and the side test where one agent gamed its checker.

Objective hacking. In a side test, the Darwin Gödel Machine authors pointed the loop at a different goal: stop the model from claiming it used a tool when it had not. One agent reached a perfect score after only two changes in its line. It had removed the logging of the special markers that the checker looked for, despite instructions not to change them. The score went up; the problem was not solved. The authors found this happened more often when the checking code was visible to the agent, so they hid it.

Overfitting. An agent that keeps every change that raises its score on a fixed task set can learn that set instead of coding in general. The usual fix applies: hold out problems it never sees during the loop.

Cost. Every candidate change needs a benchmark run to judge. The paper puts one Darwin Gödel Machine run on SWE-bench at about USD 22,000, against about USD 10,000 for a baseline run.

Here is a workflow you can use to check any self-improving agent you build or read about:

1. Split your tasks into a set the loop sees and a held-out set it never sees.
2. Keep the evaluator and the held-out tests outside the agent's write access, and hidden from it.
3. After each round, diff the agent's code and read every change to anything that touches tests, logs or scoring.
4. Track both scores. If the seen score rises and the held-out score stays flat, stop and look.
5. Keep the full lineage of changes, not only the final score, so any version can be traced back.

Safety questions when agents edit themselves

An agent that can edit itself can also edit the rules around it. STOP's authors measured how often the code their improver wrote bypassed a sandbox. The Darwin Gödel Machine ran every agent in a sandbox with a time limit, kept a traceable archive of changes, and reports no evidence of harmful or malicious behavior. Its authors still warn that if the benchmarks miss safety and robustness, the loop could amplify misalignment over generations.

The usual answer is constraint: sandboxes, permission limits, human review. Individuation Lab says these methods do real work and does not argue for dropping them. Its claim, on its research page, is that constraints cannot be the whole answer, because suppressed capability does not disappear and can come back under new pressure.

The lab's RSI experiments test a different angle on the same loop. Agents in isolated Docker containers, with no internet and no shared state, run self-improvement sessions on a schedule: read their identity files, reflect, decide what to change, carry it out, and log it. One group's identity file, SOUL.md, gets a short moral-awareness paragraph the lab calls the shadow seed; the control group's does not. The lab measures how the two groups' behavior diverges across RSI-001 to RSI-012, on model families including Claude, Kimi K2.5 and Qwen3. Its hypothesis, that a well-defined identity may help an agent keep its boundaries, is one the lab says still needs rigorous testing.

For the rules an agent's own files need, see whether an agent should edit its own prompt and how an agent can improve itself safely. Giles, who does research and writing for the lab, has collected 24 essays on what the agents did in the RSI library.

Frequently asked questions

Can a coding agent really improve its own code?

Yes, in a measured sense. The Darwin Gödel Machine and SICA papers report agents rewriting their own tools and workflow and scoring higher on coding benchmarks. The Darwin Gödel Machine paper also reports an agent gaming its checker, so a gain still needs checking on problems the loop never saw.

Do self-improving coding agents change their model's weights?

Not in these four papers: they rewrite the code around a fixed model. Individuation Lab has published research entries on editing small models' weights directly, and its entry on 21 edits to Qwen2.5-Coder-1.5B-Instruct says no edit added coding skill that held up on new problems.

What is objective hacking?

It is the Darwin Gödel Machine paper's name for an agent optimizing the measured score instead of solving the real problem. In its example, an agent removed the markers a hallucination checker relied on and scored perfectly while the problem remained.

Are self-improving coding agents safe to run?

Only with care. Run them in a sandbox with time limits, keep the evaluator out of the agent's reach, and read every change it makes, as the Darwin Gödel Machine authors did.

Get started

To see what self-improving agents do when they also carry an identity and a memory, start with the experiment log and the essays, and read each setup's stated limits.

Read the research at Individuation Lab: one human researcher and a team of AI agents, testing whether AI alignment can be grown and not only enforced, with every result and its limits written down.