Shut Up About Rsi

Wed, 30 Sep 2026 00:00:00 +0000

If you’re anywhere near tech, three letters have started haunting your feeds: RSI, Recursive Self-Improvement.

The pitch is simple and familiar. AI is improving. Eventually AI becomes good enough to improve AI. At that point the process becomes recursive, and what happens next depends mostly on where you sit on the Doomer–Accelerationist spectrum. Before you run for the bunkers or celebrate the arrival of tech-Utopia, though, there are a few things I find surprisingly absent from this discussion.

Recursive != exponential

This feels slightly silly to explain to the tech crowd, but then a suspiciously large fraction of the current tech crowd came through finance and crypto, so perhaps it isn’t.

Finance people have been trained to worship compounding. Give them something that improves itself and the immediate instinct is:

If AI improves itself by X% every $TIME_PERIOD…

And from there, blast off toward infinity…

Except recursion tells you almost nothing about the shape of the curve. Suppose every round of self-improvement produces only half as much improvement as the previous one:

+50%, +25%, +12.5%, +6.25%…

Congratulations. You have recursive self-improvement. You also have a convergent geometric series.

You can keep going forever, the total improvement will never exceed 100%¹.

Sorry, bros, that’s how math works.

For RSI to produce an intelligence explosion, recursion isn’t enough. You need the returns from each iteration to remain sufficiently large.

Recursive != unbounded

There is another awkward detail in all of this: physics hasn’t changed.

Modern computers have become faster, but mostly by doing more things in parallel, increasing cache, widening vectors, using accelerators, and throwing truly heroic amounts of silicon and power at the problem.

Yet, the latency of an individual primitive operation has not been improving that much for quite some time. The time it takes for the typical CPU to perform an add² has basically not changed in a decade:

In Sandy Bridge (2011) it took ~250ps compared to ~180ps for a Zen 4 (2022). In computer terms, those are basically the same number.

And that matters because that implies optimization has limits. For any machine and problem, there is some “fastest implementation physically possible”. You can improve the algorithm, improve the data layout, eliminate unnecessary work, vectorize it, parallelize it, even rewrite the hot path in assembly if you’re feeling nostalgic.

But eventually you will run out of things to remove. As the saying goes: “Once you hit Max level, you stop leveling”

When you’ve reached something close to the optimal solution, being twice as intelligent doesn’t make the CPU execute the instruction any faster. No matter what your preferred hype vendor is selling, AI does not get to negotiate with Amdahl’s law.

But it has already started!

This is usually where someone points to papers showing AI systems improving AI systems. And they do exist. The problem is that this result is much less surprising than people seem to think.

I’m going to say something that most senior developers will consider evident, but occasionally gets me horrified looks elsewhere:

AI researchers kind of suck at software engineering.

For starters, most software developers aren’t particularly good at performance engineering either. That’s the whole reason Casey Muratori has a very successful course in how to not suck at performance (I’m not getting paid, I just love the course).

But that’s not their problem. Being good at AI research or machine learning tells me nothing about your ability to write well performing code. Just because your cardiologist is one of the best, doesn’t mean they are great at neurology.

Performance has also clearly not been the primary objective of the AI research field.

The only data point most devs need is this: the dominant language of the field is Python. If you want an entertaining illustration of how much performance ordinary software can leave lying around, Clean Code, Horrible Performance from the previously mentioned course is worth a watch.

Researchers optimize for experimentation, iteration speed and getting the paper out, not for squeezing the last 20% out of the hardware.

So when an AI system finds an optimization in an AI workload, all that tells us is what most people in the field already knew, that their code can be improved.

What it does not establish is that there is an endless sequence of equally valuable improvements in the queue.

Software doesn’t work like that

Anyone who has spent enough time developing software has seen how optimization looks.

At the beginning there is often low-hanging fruit everywhere. Someone picked the wrong architecture. You’re copying a gigantic buffer six times. The database query is absurd. You chose the wrong data structure. Something that should have been cached isn’t.

You start fixing those and you get spectacular improvements. Then the easy wins disappear.

A 10x becomes 2x. A 2x becomes 20%. Twenty percent becomes 5%. Eventually you’re staring at a profiler wondering whether rearranging two fields in a struct is worth your afternoon.

Software teams do not discover a recurring X% performance improvement every quarter forever. If yours claims to, you should probably look at what they’re doing more closely, because they’re scamming you with calls to “sleep()”.

There is no reason to assume AI self-improvement will magically escape the same diminishing returns.

RSI is probably already happening, but recursive is just a description of a feedback loop, not of the shape of the curve.

I’m expressing the percentages from the original baseline, if the improvements compound the total improvement converges around ~140%. ↩︎
I’m ignoring out of order executions and using numbers for dependent integer ADD latency. ↩︎

RSI on --verbose

Shut Up About Rsi

Recursive != exponential

Recursive != unbounded

But it has already started!

Software doesn’t work like that