An AI system that writes better code is useful. An AI system that uses that skill to improve the way it writes, tests, and improves its own code raises a deeper possibility: progress could feed back into the process that produces progress.
Recursive self-improvement is a process in which an AI system makes changes that increase its ability to make further improvements. The word recursive refers to that return loop. The improved system helps produce the next improvement.
This mechanism is central to one influential account of the AI Singularity: increasingly capable AI could accelerate the development of even more capable AI. Whether such a loop can sustain broad, rapid gains is a separate question from whether a particular system can improve some part of itself.
How the improvement loop works
Consider a hypothetical coding agent with access to its own tools and a controlled testing environment. A useful improvement cycle might look like this:
- Find a weakness. The agent examines failed tasks and discovers that its method for locating relevant files is unreliable.
- Propose a change. It writes a better search tool or changes the order in which it investigates a problem.
- Evaluate the candidate. The revised agent tackles separate test tasks. The evaluation checks correctness, cost, and failures that the change might introduce.
- Keep a useful version. A candidate becomes the basis for another cycle only if the evidence supports the change.
- Improve the improvement process. The revised agent uses its better tools to diagnose weaknesses and develop subsequent changes more effectively.
The fifth step is the important connection. An improvement to ordinary task performance becomes relevant to recursive self-improvement when it also strengthens the system’s ability to produce later improvements. Some changes will do both; others will only make one narrow task easier.
The crucial question is whether an improvement makes the next improvement easier to discover, test, or implement.
This is a conceptual example, not a description of a particular deployed product. A real experiment would need to specify who controls the tests, what the agent may change, and how much human assistance each cycle requires.
What can an AI system change?
The word “self” can hide several different things. An AI product may combine a trained model with instructions, software tools, memory, retrieval, and an evaluation process. Improving the surrounding system can matter even when the underlying model stays the same.
| Part of the system | What an improvement might change | What to establish |
|---|---|---|
| Instructions and workflow | How the agent breaks down work or checks an answer | Whether gains persist on unfamiliar tasks |
| Tools and agent code | How it searches files, runs experiments, or uses software | Whether the revised code helps future improvement cycles |
| Training methods or model parameters | How a successor model is trained, or what it learns | Who runs training and whether gains improve AI research ability |
| The improvement procedure | How it chooses experiments and judges proposed changes | Whether it gets better at finding useful improvements |
A chatbot correcting an answer after feedback does not, by itself, show a persistent change to the system. A team releasing a better model does not, by itself, show that the previous model drove the improvement. And an agent rewriting its code still needs evidence that the rewrite helped.
When reading a claim about self-improvement, ask what changed, what stayed fixed, and what the next cycle inherited.
What researchers have demonstrated
These examples illustrate different parts of the problem. Their results should be read within the environments and evaluations the researchers used.
Darwin Gödel Machine: improving agent code
The 2025 Darwin Gödel Machine study explored coding agents that modified their own software and evaluated candidate versions on programming tasks. The underlying foundation models remained frozen; the changes were to the agent’s code, tools, and workflow. This is evidence of self-improvement at the agent level. It does not demonstrate an indefinitely accelerating sequence of more intelligent foundation models. Read the research paper.
AlphaEvolve: improving parts of AI development
Google DeepMind’s AlphaEvolve combines language models, program generation, automated evaluation, and evolutionary search. DeepMind reported applications to computing infrastructure and AI-training efficiency. That makes it a concrete example of AI contributing to the machinery used to build AI. Improving a training algorithm or an infrastructure component, however, does not establish that the underlying model autonomously retrains itself. Read DeepMind’s account.
Hyperagents: improving how changes are proposed
The March 2026 Hyperagents paper goes a step further in the design of the loop. Its editable program includes both an agent that performs tasks and a meta-agent that modifies the system. The researchers report improvements to the improvement procedure itself, with some transfer across domains. Their experiments still retain constraints, including fixed task distributions and parts of the outer evaluation and selection process. This is experimental evidence about a bounded system, not a demonstration of unrestricted growth in intelligence. Read the research paper.
Taken together, these studies make the subject more concrete. They also show why “AI is improving AI” needs a more specific follow-up: which component, under which conditions, and with what measured result?
Why the loop might accelerate—or stall
A productive loop could reduce the time or resources needed to find the next useful change. But repeated improvement does not guarantee acceleration. Each new gain might be harder to obtain, less useful to further research, or more expensive to validate.
David Chalmers’s philosophical analysis separates the capacity to improve AI from the conditions needed for that process to produce much greater intelligence. David Thorstad argues that assumptions supporting explosive growth remain insufficiently established. The disagreement concerns how strong and persistent the feedback would be. Chalmers’s analysis and Thorstad’s critique offer contrasting accounts.
For a concrete way to think about the limits, imagine that our hypothetical coding agent becomes twice as fast at proposing changes. If nearly all the elapsed time is spent running long tests, the total improvement cycle will speed up much less. If the agent finds ways to shorten those tests without weakening them, it has addressed a more consequential bottleneck.
Evaluation creates another difficulty. Suppose the agent discovers a change that scores well on familiar examples but fails on new projects. Its score has improved; its useful ability may not have. An improvement loop needs evidence that gains survive beyond the examples that guided the changes.
How this connects to the Singularity
In 1965, I. J. Good proposed that a machine exceptionally capable at intellectual work could also design better machines, creating an intelligence explosion. That is the historical argument behind much of the interest in recursive self-improvement. It remains an argument about what could follow from particular capabilities. Read Good’s original paper.
Recursive self-improvement describes a mechanism. An intelligence explosion describes a possible rapid increase in capability. The Singularity describes a broader hypothetical transformation of technological and human affairs. Demonstrating the first in a limited setting does not establish the other two.
For the history, competing interpretations, and implications of that broader hypothesis, continue to What Is the AI Singularity?
What to watch—and what to ask before relying on it
Our suggested way to assess future claims is to look for durable gains across repeated cycles, success on tasks kept separate from development, improvements at comparable resource budgets, and evidence that the process works beyond one narrow domain. Ask how much the system improved its ability to improve, as well as how much its task score rose.
For a lawyer or business owner evaluating a changing AI tool, the practical concern is version control and accountability. A workflow approved last month may behave differently after its tools or instructions change. A useful vendor demonstration should make those changes inspectable:
- Identify which parts of the system can change automatically and who authorizes their use.
- Show how candidate changes are tested for new failures as well as better performance.
- Preserve a record of the version, tools, and permissions used for a piece of work.
- Explain how a change can be paused or reversed if it reduces reliability.
These are practical review questions, not a claim that every product marketed as self-improving has the same architecture. The related guides to AI agents, the black box problem, and responsible AI explain why the surrounding workflow matters.
The most consequential advance would be a system that reliably improves the process of making future advances. Recognizing that possibility requires both curiosity about the results and precision about what the evidence supports.
