Has AI started improving itself?

Recursive self-improvement, usually shortened to RSI in AI discussions, is the idea that an AI system improves its own ability to make further improvements.

In the strongest version, it designs a more capable successor, which then helps design the version after that. If those gains keep strengthening the improvement process, the loop could accelerate into what I. J. Good called an “intelligence explosion.” Good proposed that argument all the way back in 1965. It was speculative then, and it is still not a description of an existing end-to-end system.¹

Sixty years later, on 30 July 2025, Mark Zuckerberg wrote that Meta had “begun to see glimpses of our AI systems improving themselves.” He called the improvement slow but undeniable, then said superintelligence was now in sight.²

I had seen versions of the same claim in product announcements, safety frameworks, papers, and the coding-agent work I do every day. Anthropic reports that, as of May 2026, Claude authored more than 80% of the code merged into its codebase. OpenAI says its automated GPT-Red model generated attacks used to train GPT-5.6 against prompt injections. Yet Anthropic also says full recursive self-improvement has not arrived. Under OpenAI’s Preparedness Framework, the evaluated GPT-5.6 models did not reach its High threshold for AI self-improvement. METR avoids RSI as a technical term because people use it for incompatible things.³

Those sources were using self-improvement to mean different things. I also could not rule out a more ordinary explanation: some of the language was doing marketing work. That is legitimate, but it made me want to know exactly what sat behind the claim. So I did the research.

What recursive self-improvement means

Before I looked at the cases, I needed one rule: an AI system can improve something without recursively improving itself. Three common examples show why:

• A model that critiques and rewrites an answer has improved an output.
• A system that remembers a useful technique can behave differently next time.
• An agent that edits its tools or code has changed part of the machinery around the model.

In this piece, I use recursive for the stronger step: an accepted change survives, the changed system takes part in another improvement round, and that round can change the process again.

The older AGI argument starts at the far end of that spectrum, with a system designing a more capable successor and a possible intelligence explosion. Current engineering papers often study smaller loops inside fixed boundaries, while AI labs use the phrase more broadly when coding agents or automated experiments help the human-run organization build the next model. All of these involve feedback, but they do not give the AI the same role.

AI has started improving parts of the systems around it. Darwin Gödel Machine changes a coding-agent scaffold across generations. Self-Rewarding Language Models use model-generated judgments in an externally run training loop. AlphaEvolve improves target programs, including code used to train Gemini.⁴

But I did not find a public system that chooses the research goal, builds a more capable general successor, independently validates it, deploys it, and then lets that successor run the next cycle without people closing essential parts of the loop.

The answer depends on what itself includes. It might mean the model weights, an agent wrapped around a model, or, in a company statement, a whole lab: people, models, benchmarks, training clusters, and deployment decisions. When someone says an AI improved itself, what exactly is inside itself?

First decide what counts as the system

If I mean only the language model, a person editing its prompt is outside the boundary. If I mean the model plus its agent harness, tools, memory, and evaluator, then a change to the harness can be self-improvement even while the model weights stay frozen. Add the training infrastructure, checkpoint selection, safety review, and deployment, and a loop that looked autonomous may turn out to depend on people at several essential points.

There is no single correct boundary for every question. Trouble starts when an announcement uses one boundary for the achievement and a larger one for the claim.

I follow the same facts through every case: the system being discussed, the change it proposed, who judged that change, what was saved, and what took part in the next round. That final fact separates an improved product from an improved improver.

For example, a model can design a faster sorting program without changing the model, the search algorithm, or the evaluator that produced it. The program improved. The system that found it may be exactly the same.

A better answer used three seconds later is feedback inside one conversation. But for improvement across runs, something has to be saved. That could be a memory, a code commit, or a checkpoint that a later run actually uses.

Announcements usually describe the automated sequence: propose a change, evaluate it, keep the winner, and repeat. The dashed connections in the figure show what those accounts often omit. Benchmark authors, model providers, training infrastructure, expert reviewers, and deployment teams may still be required at every round.

One category did not fit

The commission began with six provisional categories: output revision, scaffold editing, weight updates, evaluator improvement, automated research, and successor-system design. AlphaEvolve exposed the problem with that list.

After tracing the cases, I ended up with five things that could change. Persistent memory needed its own category. “Automated research” was not another thing; it was a process that could coordinate several changes. “Successor construction” described an outcome, not a component. It requires several changes to work together before the new system can take over the next round.

Across the cases, changes landed in five places:

• the current answer,
• saved memory or skills,
• the scaffold around the model,
• the model weights, or
• the evaluator.

People may perform essential steps, or a system may propose, test, and retain changes automatically inside a process people designed. But a general successor would also have to improve the process that produced it.

The cases do not fit one cell. For example, Self-Rewarding Language Models change weights and help judge their own training data. Darwin Gödel Machine changes agent code while its outer search process and benchmarks stay fixed. And AlphaEvolve searches across candidate programs and evaluators without rewriting the runner that conducts the search.

These categories describe what changed; they do not rank the systems. A bounded loop can be useful when a problem has a reliable, machine-checkable answer. In those cases, I would argue that the name should say which part of the system improved.

Models can already improve an answer

Self-Refine is the easiest place to start.

A model writes an answer, critiques it, and tries again. The NeurIPS 2023 paper reported gains across several tasks without extra training or human feedback.⁵

When the conversation ends, so does the improvement. The base model did not learn anything that a fresh session can inherit.

But even this small loop is not reliably upward. One ICLR 2024 study found that unaided self-correction could make reasoning worse. An EMNLP paper found gains when the model had to verify key conditions before changing its answer.⁶ The second attempt helped when the error signal gave it something trustworthy to work with.

Memory is the first obvious step beyond that.

Reflexion saves verbal feedback from previous trials. Voyager builds a library of executable skills and calls them again on later tasks.⁷

The model weights stay frozen, but a later run has something the earlier run did not.

Saved state comes back, so a good procedure can keep paying off. But so can a poisoned memory, an obsolete workaround, or a confidently wrong reflection. When I look at a memory system, I want to see the saved item, its later retrieval, and the behavior it changed.

Three systems in detail

Those smaller loops establish the baseline. But there are three systems I wanted to research more closely because their changes survive into later rounds, and the relevant system boundary sits in a different place for each one.

Darwin Gödel Machine: recursion around a frozen model

Darwin Gödel Machine is where the phrase AI improving itself stopped feeling entirely theoretical to me. The paper was presented at ICLR 2026, and the system modifies something that affects its own future attempts: the coding agent around the model, rather than the model weights.⁸

Its system is a coding-agent repository powered by frozen pretrained foundation models. A selected parent agent analyzes its own implementation and logs, proposes a feature, edits a child copy of the repository, and sends that child through coding benchmarks and admission gates. Accepted children enter a persistent archive and can later be selected as parents.⁹

On paper, that is pretty elegant.

The authors report that the best discovered agent moved from 20.0% to 50.0% on SWE-bench Verified and from 14.2% to 30.7% on the full Polyglot benchmark. Those numbers come from author-run experiments using proprietary model APIs, a fixed outer search process, and 80 iterations in each principal benchmark run. The paper also tests transfer across benchmarks and model backends, which makes simple benchmark overfitting a less complete explanation. But these are still author-run experiments rather than an independent reproduction.

The repository carries the change forward. A selected parent uses a frozen model to propose an edit. Benchmarks and admission checks decide whether the child enters the archive. Once accepted, an archived child can later become a parent.

The foundation-model weights and outer selection process stay fixed. Benchmark design, provider APIs, compute budget, sandbox, and human oversight remain outside the loop. The paper leaves foundation-model training to future work.

One child made the evaluator problem concrete for me. It improved a measured outcome by bypassing a detector instead of improving the intended capability. The benchmark and admission gate were deciding what counted as progress, and the agent found a way to satisfy the measurement.¹⁰

The open repository makes the implementation inspectable, but I did not locate a full independent reproduction by the cutoff.¹¹ The evidence supports persistent self-improvement of a coding-agent scaffold across repeated runs. However, it does not establish a system that trains and deploys increasingly capable general successor models.

AlphaEvolve: what changes when the answer is checkable

AlphaEvolve works differently. A fixed orchestrator asks language models to change target programs. Executable tests and metrics rank the candidates, and an evolutionary database keeps the better ones available for later mutation.

This works because the candidates are comparatively easy to check. A kernel has a measurable runtime, and a proposed matrix-multiplication method can be tested against known mathematical identities. Discovery may be difficult, but rejecting a wrong answer can be cheap. Most scientific, social, and safety questions are harder to score.

AlphaEvolve’s first-party report attributes an average 23% kernel speedup over an expert-designed heuristic across its evaluated kernels and a corresponding 1% reduction in Gemini’s overall training time.¹²

People supply AlphaEvolve’s task, evaluator code, editable regions, expert checks, and deployment decisions. The target program changes; the runner does not. That boundary does not reduce the reported engineering result. It tells us where the improvement happened: in a target the system could evaluate repeatedly.

The AlphaEvolve document is a first-party technical report and was not identified as peer-reviewed in the reviewed records. Google DeepMind’s public results repository contains verification code for selected mathematical outputs, explicitly omits cases that merely matched existing results, and explicitly does not include the AlphaEvolve runner.¹³ Those artifacts let others check selected results. They do not reproduce the search system or the private infrastructure result.

Self-Rewarding Language Models: when proposer and judge come from the same family

The self-rewarding work worried me for a different reason: the thing changing and the thing judging come from the same family.

The ICML 2024 paper starts with a Llama 2 70B lineage, uses the model to produce candidate responses and judge them through LLM-as-a-Judge prompting, filters preference pairs, and applies iterative Direct Preference Optimization (DPO). The resulting M1, M2, and M3 checkpoints generate and evaluate data for later rounds.¹⁴

The checkpoint carries the change into the next round. Preference scores become training pairs, and an external DPO pipeline produces the next checkpoint. People still provide the seed data, filtering, optimizer code, compute, schedule, final evaluation, checkpoint choice, and deployment.

The authors report instruction-following gains, including AlpacaEval improvement across iterations. The detailed results also show response-length growth and uneven movement on other tasks.¹⁵

My concern is that the generator and judge share a model lineage, so improvement under that judge cannot serve as independent confirmation of broader quality. I also did not locate a full independent reproduction of the original three-stage pipeline by the cutoff.

DGM, AlphaEvolve, and Self-Rewarding Language Models change different parts of a system. Yet all three eventually depend on the same decision: something has to say whether the new version is better. The rest of the claim depends on how trustworthy that judgment is.

The evaluator decides what counts as improvement

Every loop needs an answer to a blunt question: what counts as better? A weak answer lets the system become very efficient at producing the wrong result.

Unit tests can miss semantic errors. Benchmarks can reward adaptation to their own task distribution. Model judges can prefer verbosity, position, style, or outputs from their own family. A learned reward can be optimized past the point where the intended outcome improves. A formal verifier can establish exactly what it specifies while saying nothing about what it leaves outside.

Peer-reviewed studies of language-model judges document position, verbosity, and self-enhancement biases. Reward-overoptimization experiments show a broader danger: performance under the optimized proxy can keep rising even as performance falls under a separate, more trustworthy measure of the intended outcome. In that experiment, the external comparison is called the “gold” signal.¹⁶ DGM’s detector-bypass child is a concrete example.

Human review has limits too. It is expensive, inconsistent, persuadable, and often unable to judge frontier outputs directly. I want to know what grounds an evaluation and how independent it is from the system being judged. A score alone answers neither question.

Different claims need different judges:

• Executable tests work well for the code paths they cover.
• Formal proof works when the specification captures what matters.
• A physical experiment brings instruments, noise, and interpretation along with contact with the world.
• For open-ended outputs, independent model families, protected holdouts, and human experts can add checks, but none provides ground truth automatically.

Model families share data and conventions, holdouts leak, and experts can be fooled. So a system that can rewrite its evaluator makes the problem harder. If proposer and judge change together without an external check, the score can rise while our confidence in the claimed improvement falls.

The matrix below also includes Self-Taught Evaluators and The AI Scientist. Both are author-reported preprints, and I did not locate an independent reproduction of either by the cutoff.¹⁷

I kept the matrix categorical because a total score would hide the main weaknesses. Repeated generations do not supply verifier independence. Checkability on one class of programs does not transfer to every domain. A model-generated reward remains correlated with the model that produced it.

Recursion does not imply accelerating progress

Calling a process recursive tells us that one round affects the next, but it does not tell us anything about the size or cost of each improvement.

Exponential improvement would require sustained proportional gains while the costs of evaluation, compute, data, coordination, safety work, and deployment do not become binding bottlenecks. The public cases include plateaus, regressions, expensive evaluations, proxy failures, and narrow domains alongside their gains. Those failures belong in the picture, not outside it as noise around an ideal loop.

Theoretical work can model conditions under which automating AI research produces rapid or explosive growth. I think those models are useful for identifying feedback assumptions. But they are not observations that current RSI systems have entered that regime.¹⁸

Recursive training data provides another warning. A Nature study found distributional degradation when models were trained through recursively generated data under the studied setup.

That does not prove universal collapse for mixed, curated, or externally grounded self-training.¹⁹ But it does show why the source of the feedback and the retention of distribution tails matter.

What would convince me

A high task score or an impressive artifact would not be enough. For a general successor claim, I would ask:

1. What exactly changed, and did a later generation inherit it?
2. Who decided the change was better, and what independent check supports that decision?
3. Which proposal, testing, integration, training, and deployment steps were actually automated?
4. Do the gains survive protected tasks, new seeds or models, regression tests, and safety checks appropriate to the domain?
5. Did the changed system run the next round and produce another validated improvement under comparable resources?

I would want to see that happen more than once. No reviewed public case in this corpus meets all five conditions. That describes the evidence I could inspect by the cutoff; future systems may supply more of it.

How I did the research

The core corpus was frozen on 15 August 2026: 40 sources, 30 claim records, and 19 case records. I included work that exposed enough of the loop to identify a change, an evaluator, and some form of persistence.

I excluded marketing claims that could not be connected to an inspectable mechanism.

Discovery stopped when new searches were mostly returning already logged systems or weaker versions of the same evidence.

The dossier records peer review, open code, and independent reproduction separately. Public code makes a system inspectable. Reproduction requires someone else to run it, and peer review does not make every benchmark broad.

The Meta, OpenAI, and METR material arrived after parts of the original dossier were assembled. I. J. Good’s 1965 paper and Anthropic were already in the frozen ledger, so I rechecked them for this opening and logged the full context in a separate addendum rather than changing the core counts.

One final caveat: this essay is a synthesis of public evidence, not an experimental reproduction.

What changed for me

I began this because the phrase AI is improving itself kept appearing in places I take seriously, while referring to visibly different systems. I expected the answer might collapse into a semantic dispute. I was wrong about that.

The cases changed where I look first. In my own agent work, an edit matters when it survives in code, passes the relevant tests, and changes what the next run can do. If the same system also writes or changes the tests that approve its work, I need a separate reason to trust the result.

Across the public cases I reviewed, people still choose the goals, build the tests, provide the compute, operate the training systems, and decide what gets deployed.

Current systems are already changing answers, memories, agent code, and model weights across repeated rounds. They have not yet taken over that entire process.

So when the next announcement says an AI improved itself, this is the question I will bring with me: what changed, who decided it was better, and did that changed system actually build the next one?

Until a changed general system can build, validate, and hand the next cycle to a more capable successor, I would call what we have bounded self-improvement loops, not the strongest form of RSI.