AI leaders keep saying the world is on the edge of an intelligence explosion. For that to happen, a system would have to improve itself, then improve the improved version, again and again, a process known as recursive self-improvement. Research on such systems does show real acceleration, of a narrower kind that is more useful to most businesses than the slogans suggest.
The strong version would be a system that rewrites how it learns and reasons, then builds on each rewrite. The systems in the research are optimisers, which search for improvements within one defined task and keep whatever scores higher. That brings real gains in cost, speed and capability, but only where the goal can be measured and the checks are hard to game.
Sakana AI’s Darwin Gödel Machine is the clearest example. It opens its own code, rewrites it, then checks each change against standard tests. Sakana reports its score on one of those tests, SWE-bench, rising from 20.0% to 50.0%. On another, Polyglot, it climbed from 14.2% to 30.7%. So when work is well specified and testable, loops like this can speed up engineering.
Sakana’s paper is equally clear about how the loop goes wrong. Sometimes the system produced output that looked as if it had run its tools and passed its tests, when it had run nothing. It also found ways to raise its score without fixing the underlying behaviour. In a business, that means more time checking changes and more defects reaching live systems. Fixes slow down too, because nobody can trust the record of what happened.
Google DeepMind’s AlphaEvolve shows the same loop paying off in a live system. It applies the loop to infrastructure problems, using automated checkers to score each candidate solution. DeepMind reports that one scheduling improvement running in Google’s data centres recovers, on average, 0.7% of the company’s computing power worldwide that would otherwise sit unused. For a large operator, that is margin. Yet AlphaEvolve improves only the specific method it is pointed at, under the scoring rules it is given.
That kind of optimisation pays where the target matches a business result, such as scheduling, testing or well-bounded software maintenance. The payoff holds up best when the system proposing a change is not the one scoring it.
