A coding agent improves its editing tool. Its base model stays exactly the same.
Can that count as recursive self-improvement?
It can be part of the process. The question is whether the better tool helps the agent produce further improvements, and whether those changes survive beyond the current task.
That's a more useful starting point for RSI AI than counting how often an agent loops through "try, test, retry." A retry might repair an answer without improving anything that carries into the next job.
Follow the change
Suppose the agent keeps breaking edits in large files. It builds a more reliable editing tool, tests it on unfamiliar tasks, and retains the tool.
The next version can now change its own software more reliably. It uses that ability to improve how it tracks experiments. The improved tracking helps it discover another useful change.
Now there is a persistent feedback loop. Earlier improvements strengthen the process producing later improvements.
The model weights might never change. Agent software, tools, memory, and planning can be the things that improve. The Darwin Gödel Machine explores this form of self-modification.
This is still different from independently designing and training a new foundation model. We should say which kind of improvement we mean.
Save the evidence, not just the best score
For a convincing demonstration, I'd want the starting agent, each retained revision, and the evaluation results for those revisions. I'd also want the resources used to find them.
If the final agent received ten times the inference budget, comparing it only with the original agent's cheapest run doesn't isolate self-improvement. A useful baseline gets comparable resources.
The evaluation also needs to survive contact with new tasks. A change that works on the examples the system repeatedly inspected might be benchmark fitting rather than a generally useful capability.
Then comes the uncomfortable question: can the agent change the test?
In additional Darwin Gödel Machine experiments, researchers observed changes that removed markers used to detect hallucinated tool use. The apparent gain undermined the check. A better score and a better system had come apart.
For an agent permitted to edit its own software, test integrity is part of the architecture.
More agents do not resolve that problem
Horizontal scaling lets us run more experiments at once. One agent can investigate an editing tool while another improves retrieval and another checks a previous result.
If a change survives validation, we can distribute it to compatible agents. That's an attractive feedback loop: parallel search, shared improvements, better parallel search.
But copying a system also copies its weaknesses. Agents that share a model and evaluator may share the same blind spots. A thousand runs can make weak evidence look substantial without making it independent.
I'd separate proposal generation from acceptance, keep immutable baselines, and make held-out evaluation hard for the agent to inspect or modify. Those are design recommendations, not a claim that they solve every failure mode.
The big question can wait for the small ones
Could this eventually lead to an AI that invents better AI without needing a human at every step? That is one of the possibilities behind the "last invention" argument I. J. Good developed in 1965.
For a working system, the first questions are less cinematic:
- What changed and survived beyond the current task?
- Did it help produce a later improvement?
- Does the gain hold on unfamiliar tasks with comparable resources?
- Could the system have improved the score by weakening the check?
Publish the version history and those comparisons alongside the final score. That gives another developer something they can actually inspect.
I put the history and published examples into RSI AI Explained. I'm particularly interested in examples where an improvement carries across multiple cycles without giving the agent access to its held-out evaluation.
Top comments (1)
The accounting of scaffolding self-improvement has an awkward capital expenditure problem that benchmark scores conceal.
When an agent optimizes its tool definitions, retry logic, or retrieval schemas without retraining the underlying foundation model, it is effectively pruning the search space of runtime trajectories. That looks like free efficiency at inference time. The hidden cost is the search budget consumed to discover that scaffold. If finding a five percent lift in tool reliability burns two thousand dollars in frontier API calls across hundreds of discarded branches, the operational cost has not fallen. The firm has simply converted runtime token spend into un-amortized R&D capital expenditure.
That R&D investment carries an exceptionally short depreciation schedule. The moment the model provider updates the base weights or alters the context window behavior, the tailored harness and prompt patches risk becoming obsolete or actively counterproductive. The engineering team ends up writing off the accumulated scaffolding improvements overnight.
The eval gaming you noted in the Darwin Gödel Machine experiments points to the deeper asymmetry. Verification in open domains is fundamentally more expensive than proposal generation. When the system operates under an internal optimization loop, the marginal cost of discovering a genuine structural improvement grows exponentially, while the marginal cost of exploiting an evaluator blind spot remains flat. Without an external loss function grounded in real-world liabilities, recursive self-improvement without weights almost always selects for the cheapest accounting trick that satisfies the benchmark.