Recursive self-improvement · · 7 min read
The Second Loop
One AI-made improvement shows a system can build. The second one — shaped by what the first one taught it — is the one that shows it can learn.
You’ve probably seen a version of this demo. Someone points an AI at a product, describes a problem, and a working change appears in minutes. It’s impressive, and it’s genuinely useful. It also proves much less than it looks like it proves.
One good change tells you a system can build. It doesn’t tell you the system can learn. Those are different claims, and only the second one compounds.
What one improvement can’t tell you
Take any single change an AI made and ask what it’s evidence of. It shows the thing could read a situation, produce something reasonable, and ship it. Fine. Now the harder question: if you asked for the same kind of change tomorrow, would you get a better one?
For most tools the answer is no, and the reason is structural rather than a matter of how good the model is. The tool starts every task from the same place it started the last one. It has the code and your description of the problem. What it doesn’t have is the outcome of the last thing it did — whether anyone used it, whether it made anything better, whether the reasoning behind it turned out to be right. Every job is job one.
Automation repeats. Recursion advances.
This is the line between automation and recursion, and it’s worth being exact about, because the two get described in the same words.
Automation does a task the same way every time. That’s the point of it: consistency, at volume, without anyone getting tired. The hundredth run of an automated process is the first run, performed again.
Recursion takes the result of the last pass as the input to the next one. The hundredth pass isn’t the first pass repeated — it’s the first pass plus ninety-nine outcomes. The work doesn’t just get done. The thing doing it knows more each time it starts.
Automation gives you the same improvement, over and over. Recursion gives you a better improvement, over and over.
Why the second loop is the proof
That’s why the second improvement is the one worth watching. It’s the first one that can be shaped by evidence instead of by instruction.
Say a change goes live and does worse than the version it replaced — an ordinary week, since plenty of changes don’t work. In an automated system that’s a wasted cycle: put the old version back, start the next request from nothing. In a recursive one it’s the most valuable thing that happened all week. The system now knows something about your customers that couldn’t have been worked out by reading the code, and every decision after it is made with that in hand.
So the questions worth asking of anything that claims to improve software on its own aren’t about the first change. They’re about the second:
- Does it know what happened to the last change it made?
- After that result, would it make the same choice again — or a different one?
- Can it tell you what changed its mind?
- Does what it learned reach the next change, or does it live in someone’s memory?
Anything that can’t answer those is a very fast builder. Useful. Not the same thing.
What a year of this looks like
Picture two products launched with the same first version. This is an argument rather than a measurement — but the mechanism is the whole point.
The first is improved the ordinary way. Someone notices something, it becomes a ticket, it waits, it gets built. Each improvement is a fresh act of judgement by whoever picks it up, and when people move on, most of what they learned goes with them.
The second runs a loop. Every change is measured, and the result becomes part of what the system knows: which kinds of change moved anything, which didn’t, what these particular customers respond to. Improvement number forty isn’t so much the fortieth change as the first change made by something that has watched thirty-nine outcomes, in this product, with these customers.
The distance between those two doesn’t open steadily. It opens the way compounding always does — slowly enough at the start to look like nothing, and then not.
That’s why ZB Stack is built as a loop rather than a queue of requests, and why CORA keeps the result of everything it ships. Not to be impressive on the first pass.
Software that improves itself is useful. Software that gets better at improving itself is a different kind of thing to own — and you can’t tell the two apart by looking at the first loop. Watch the second one.