ralph is a strange loop ?
12 January 2026 - Hugo O’Connor
I’ve been watching something strange happen. Geoffrey Huntley spent $14k and months tuning an AI agent in a bash loop (generate, critique, revise, repeat) until a working compiler emerged. He calls it the Ralph loop, and the language it produced, cursed.lang, actually compiles. It wasn’t autonomous, he had to tune it like a guitar, but a model talking to itself built something real.
What fascinates me isn’t just that it works. It’s that the same weights which produced an error can catch it on the next pass. The critic and the creator are the same system, displaced in time. I find this genuinely disorienting. Like watching someone proofread their own writing and find mistakes they made moments ago. How does that happen? What changes between passes?
When I try to explain it, I reach for analogies. This is what we do when confronted with something new; we map it onto concepts we already have.
Hofstadter’s strange loop was my first reach. Self-reference creating something emergent. It sounds right. But there’s no paradox here, no hierarchy folding back on itself. Just sequential processing with different prompts. The strange loop framing implies something almost mystical, and I don’t think that’s what’s happening.
Bergson’s memory cone gets closer. He imagined how we engage accumulated experience: quick habitual action at the tip, deep reflection toward the base. When a model generates, perhaps it’s acting from the tip, patterns flowing readily from training. When it evaluates, it moves up the cone; same weights, but engaged differently. This captures something real about depth of processing. But Bergson was describing human consciousness, not matrix multiplication.
What about a garden, where all paths exist before anyone walks through? The prompt determines your entrance, constraining which routes you can take. Generation walks one path; critique starts a new walk from where you ended up. You reach places inaccessible from the original entrance. This explains why the same model gives wildly different outputs for different prompts. Different entrances, different destinations.
We’re mapping an alien process onto human concepts, and the fit is always partial.
This is ontological shock: new technology, old mental models. We have a thing that works, and our concepts haven’t caught up. Our perceptions are further obscured by marketing hype from startups selling the future, or by limited hands-on experience from engineers who tried it once, didn’t get the result they wanted, and wrote the whole thing off. Neither extreme sees clearly. Old habits need breaking. Ideas that seemed stupid before (100% test coverage, for instance) start making sense when a machine can write the tests. And rituals we take for granted need questioning: Agile was built around the economics of software development before AI. Sprint planning, story points, velocity tracking: all assume predictable human capacity. What happens when months of work can be achieved in hours? When the time spent in meetings could just produce the outcomes instead? Communication overhead becomes the bottleneck. How do SaaS companies maintain value when their product can be replaced for less than a single annual subscription? We used to mock ourselves for endlessly tweaking our dev environments, customising Emacs when we should have been shipping. Now a new blog post about LLM techniques can genuinely transform how you work. The tweaking is the work. That has downstream consequences.
But even without the right framework, we can observe when it works and when it doesn’t. The conditions are clearer than the mechanism.
- Checking is easier than generating. Finding a bug is easier than writing bug-free code.
- The knowledge exists but wasn’t activated. The model knows about edge cases, it just didn’t think to check.
- There’s something concrete to check against. Code can be run. Tests can fail. Ground truth, not vibes.
- The knowledge isn’t there. You can’t critique your way to facts you don’t have.
- Sycophancy kicks in. Models talk themselves out of correct answers to satisfy the implicit “this needs fixing” frame.
There’s a deeper issue here: these systems amplify. They amplify understanding when you’re on the right track, and they amplify misunderstanding when you’re not. Ubiquitous access to knowledge doesn’t mean we understand it. Knowledge is having the information; understanding is grasping what it means, why it matters, how to apply it. You can generate a thousand lines of code without understanding what any of it does. The model has knowledge but perhaps not understanding. And if you just accept its output, neither do you.
Then there’s the practical question of how to use this thing. Too specific and you spend more time directing than doing. Too vague and it goes off the rails. The sweet spot exists, but you can’t reason your way to it. You find it through experimentation, through repetition, through learning the craft.
I’m writing this down because working through analogies is how I process the unfamiliar. None of them are quite right. All of them help a little. But there’s an irony here: we can get so caught up in finding the right mental model that we forget to just use the thing. The Ralph loop itself is a kind of “suck it and see”: try it, check what happened, adjust. Perhaps that’s the real lesson.
A little less conversation, a little more action.
Co-written with Claude Opus 4.5.