Recursive Self-Improvement: The Loop That Improves Itself

October 12, 2026

Recursive self-improvement drawn as an outward spiral, each turn wider and heavier than the last

Most improvement is linear. You fix a bug, the product is slightly better, and tomorrow you fix the next one at the same speed.

Recursive self-improvement is different. It is improvement that makes the next round of improvement faster. The system doesn’t just get better. It gets better at getting better.

That idea has a dramatic version, which hasn’t happened, and a modest version, which is quietly happening on my laptop and in every good engineering team I’ve worked with. This post is about both, and about what the modest one means if you own a product.

The dramatic version

The term comes from AI. In 1965 the mathematician I.J. Good wrote that an “ultraintelligent machine” could design even better machines, and that there would then be an “intelligence explosion”, with the intelligence of humans left far behind.

That is the thought experiment: a model that can do AI research improves itself, the improved model does better research, and the loop runs away. Every discussion of AGI, superintelligence and AI risk eventually comes back to it. I wrote about where we are on that road in AI and AGI.

It is worth being precise about what the loop requires, because the requirements are what make it hard:

A system that can propose changes to itself. Not just to its outputs, but to the thing that produces the outputs.
A way to judge whether a change is actually better. Not “looks better”, but measurably better on the thing you care about.
The ability to apply the change and run again. Cheaply enough to iterate.

Today’s models are strong on the first. They are weak on the third, because retraining a frontier model costs tens of millions and months. And the second one, judging, is the hard part everywhere, not just in AI.

Why it hasn’t run away

People expected the explosion to come from the weights. A model rewrites its own training process, trains a smarter successor, repeat.

That is not how the gains are showing up. The weights change slowly, on a schedule set by labs with large budgets. What changes fast is everything around the weights: the prompts, the tools, the memory, the evaluation harness, the scaffolding that turns a model into an agent.

And a model is extremely good at improving that layer, because that layer is just software, and the model is good at software.

So the loop exists. It is just running on the outside of the model rather than the inside, and it is bounded by how good your judgement is, not by how clever the model is.

The version that is already here

I build software with agents every day. The platform behind Koppa now gets a meaningful part of its changes written by an agent that I steer. Over a few months a pattern emerged that I didn’t plan, and it is recursive self-improvement in miniature.

It works like this:

The agent does a task and gets something wrong.
I correct it, and the correction goes into a project file the agent reads at the start of every session.
The agent writes a small reusable skill, a script or a checklist, so the next time the same task is faster and the same mistake is harder to make.
Next session, the agent reads its own notes, uses its own tools, and does the task better.

None of those steps is impressive on its own. Together they mean the thing doing the work is also maintaining the environment it works in, and the environment makes the work better. That is the loop. The weights never changed. The harness did.

Three things make it actually compound rather than just accumulate:

What	Why it matters
Memory that persists between sessions	Without it every session starts from zero and nothing compounds.
Tests and checks the agent can run itself	This is the judge. Without a judge, “improvement” is just change.
Permission to change its own tooling	Skills, scripts, config. If the agent can only touch product code, the loop stays linear.

The judge is the one I would fight for. An agent with good tests, a working build and a clear definition of done will improve. An agent without them will produce confident changes at great speed, which is a different thing entirely. I’ve seen that version too, and I wrote about it in Vibe Coding.

Teams do this too

Strip the AI out and the shape is familiar.

A retrospective is a system proposing changes to itself. A team that acts on the retro, and then checks next sprint whether it helped, is running the loop. A team whose retro produces the same three complaints every fortnight has the proposal step and nothing else.

The teams that pull ahead are not the ones with the best engineers on day one. They are the ones where fixing the process is treated as real work, with the same priority as fixing the product. Every improvement to the build, the deploy, the test suite or the on-call rota makes every future change cheaper. After a year, that team is not slightly faster. It is in a different league, and it got there one small loop at a time.

This is also why feedback loops are the thing I keep coming back to. The length of the loop sets the speed at which the loop can improve itself. Shorten it and everything else follows.

What this means if you own a product

If you are a CTO or product lead putting agents into your delivery process, the recursive version is where the return is, and it needs a few deliberate decisions:

Invest in the judge before the agent. Evaluations, tests, clear acceptance criteria. An agent is only as good as the signal telling it whether it did well. This is the same advice I’d give a human team, and it is cheaper to set up now than after the first confident mess.

Give the agent somewhere to write things down. Project instructions, memory, a skills directory. Treat them as part of the codebase and review changes to them like code.

Let it improve its own tools, within a boundary. Scripts, checks, templates. Keep it out of production config and credentials. The point is a loop that compounds, not one that escapes.

Keep a human on the judge’s seat for anything that matters. The loop is bounded by the quality of judgement, and the model’s judgement of its own work is the part I trust least. Mine isn’t perfect either, which is why the tests exist.

Measure the loop, not just the output. Is the second time you do a kind of task faster than the first? Is the tenth faster than the second? If not, you have an assistant, not a loop.

Conclusion

The intelligence explosion is a thought experiment about weights. The loop that is actually running is about harnesses, tooling and judgement, and it is available to any team willing to treat improvement of the process as real work.

It won’t run away. It will compound, slowly at first and then noticeably, and the teams and products that set it up now will be hard to catch later.

If you want help setting up that loop, with evaluations, MCP servers and agents that do real work, that is what my agentic engineering practice is for. Have a look at my availability and get in touch.