Recursive self-improvement, explained honestly

What it means

Recursive self-improvement is a loop in which a system modifies its own code, prompts or tools, and each round of changes makes it better at making the next round. The recursion is the point: not just improving, but improving at improving.

Stated that way it sounds like a slope with no bottom. In practice every deployed instance has a floor, and the floor is usually obvious once you look for it.

Why every real loop is bounded

Four bounds show up in practice, and most systems have all four:

• The model is fixed. In production, agents rewrite prompts, procedures and tools — not weights. The reasoning ceiling is whatever the model could do on day one.
• The evaluation signal is narrow. A loop can only improve against something it can measure, and most real work has no clean score. Where the signal is a proxy, optimising it hard is reward hacking rather than progress.
• Compute is capped. Someone pays for each cycle. A daily budget is a hard limit on how many rounds happen.
• A human is in the loop somewhere. Reviewing, approving, or simply noticing that output got strange.

Remove all four and you have the thing the headlines are about. Nothing you can buy does.

What the impressive examples actually show

The genuinely striking results in this area — AI systems writing large fractions of the code in their own development, research loops closing benchmark gaps faster than human teams — are real and worth taking seriously. They are also all examples of bounded recursion: a fixed model, a well-defined target, a measurable signal, and people supervising.

That is not a criticism. A bounded loop with a good evaluation signal is the most useful version of this idea, and it is the one that shows up in products. The unbounded version is a research question, not a purchasing decision.

Reading a vendor claim

Three tests, applied in order:

• What is in the loop? If the answer is prompts, skills and memory, that is the normal, useful thing and the honest name for it is self-improvement, not recursion. If the answer is vague, nothing is in the loop.
• What is the evaluation signal? A loop without one does not improve; it wanders. Ask what tells the system a change was good.
• Where is the ceiling? Every real implementation has one. A vendor who cannot name theirs either has not built it or has not thought about it.

A vendor answering all three plainly is describing something real. The marketing tell is the passive voice: "the system continuously improves" with no subject, no signal and no limit.

Why bounded is the feature

Worth saying directly, because it inverts the usual framing. For anyone running a business on this, the bounds are not a limitation to apologise for — they are the product. A daily ceiling is what stops overnight drift. A fixed model is what makes behaviour predictable between releases. A human in the loop is what makes the whole thing accountable.

The interesting engineering question is not how to remove the bounds. It is how to get the most improvement inside them, and how to make what happens inside them visible. That is what the four safeguards are about.