Looping Casino

I've been watching the agent-pilled crowd for a while now. Every few months there's a new thing that's finally going to change everything, and right now it's autonomous coding loops: give the model a goal, let it run, wait for working software to emerge. I've spent time with these systems. The underlying idea is worth taking seriously. The conclusions people are drawing from it are not.

AI loops are genuinely useful in exactly two situations. The first is large-scale exploratory research, problems where the search space is so vast that discovery is the goal and correctness is secondary – the kind of space where you want a million experiments running rather than one careful engineer. The second is review and consensus, using a model as a judge on outputs it didn't produce, which we already knew was tractable when the prompting was tight. Those two cases are real. They are also narrow.

The hype really describes something different: a belief that code will simply improve itself if you run the right loop. If you wire the model's output back to its input, add some clever goal verification, and let it spin, quality will compound. I understand why this is appealing. It sounds like the last hard problem finally gets automated away.

But watch what this reasoning requires you to believe.

It requires you to believe that intelligence is reducible to speed. That if you can do something faster, you've done something smarter. That the difference between adequate and excellent is just iteration count.

It requires you to believe that the ingenuity accumulated over decades of engineering practice – the hard-won heuristics, the architectural instincts, the taste that tells you when a solution is fragile before it breaks – becomes irrelevant once the computer is fast enough.

It requires you to believe that brute force, given infinite compute, converges on the same outcome as careful thinking. Maybe eventually. Not yet.

What was intelligent yesterday doesn't become less intelligent today because we can do it faster.

The engineers who would be replaced by these loops are not slow. They are doing something the loop can't do: they are exercising judgment under conditions of ambiguity, holding context across real constraints, and knowing when the spec itself is wrong. Speed doesn't substitute for that. It just runs the wrong thing faster.

I'll allow that this will change. Loops will get better. And I'll allow something else: in small, tightly scoped problems — a single function with a clear spec, a test suite with deterministic pass conditions, a script where correctness is verifiable in seconds — loops can close the gap today. The smaller the scope, the more tractable the verification, the more the iteration actually compounds. That's real. The set of problems where autonomous iteration converges on something correct will expand. That's worth tracking.

But that's not what people are claiming. They are claiming it works now, broadly, for real software. And if that were true, we would all already be running everything in loops and hoping for the best.

We are not.

There is one more use I'll grant. If you just don't want to think — if you want something functional enough, fast enough, for stakes low enough that judgment doesn't matter — loops are a reasonable substitute for thinking. That's a legitimate choice. It's just not engineering anymore.

So be honest about where loops are useful: giant search spaces, constrained review tasks, problems where quantity of attempts matters more than quality of judgment. Everywhere else, ingenuity still matters.