The Coming Loop | Armin Ronacher's Thoughts and Writings

Armin Ronacher's Thoughts and Writings

blog<br>archive<br>projects<br>travel<br>talks<br>about

The Coming Loop

written on June 23, 2026

I don’t prompt Claude anymore. I have loops running that prompt Claude and<br>figuring out what to do. My job is to write loops.

— Boris Cherny

Over the last months I have watched more and more people build something on top<br>of coding agents that feels meaningfully different from just using a coding<br>agent. Some of this happens on top of Pi which is cool to<br>see for sure! The pattern is the same everywhere though: work is put into a<br>queue of sorts, a machine picks it up, attempts it, stops, and then some harness<br>decides whether that was actually the end.

If not, the harness continues the same session, injects another message, starts<br>a fresh session with modified context, or sends the task to another machine. The<br>task stays alive beyond the point where the model by itself would normally have<br>said: "I am done."

I think about that type of loop more than I want to admit.

There is already an agent loop inside every coding agent. The model calls a<br>tool, incorporates the result, calls another tool, reads a file, edits a file,<br>runs tests, and eventually produces some answer. That loop is one we have been<br>quite familiar with for a long time. The other loop is the harness level loop:<br>the loop outside the agent loop. That loop is also not<br>new. We have been doing versions of this since<br>early Claude Code days, but that loop is becoming ever more present in agentic<br>engineering and in recent weeks it has started to dominate the Twitter<br>discourse.

I Am Not Good At This Yet

My current status is that I have not had much success with this way of working<br>for code I deeply care about which turns out to be quite a lot of code.

Part of that is taste and part of it is control. I attempt to set a high bar<br>for what I want code to look like, and I want to understand the code I ship.<br>Under pressure, or in a discussion with another human, I want to be able to<br>explain what the system does without first having to ask a clanker to explain it<br>to me. Now there is obviously a question if this desire to understand the code<br>is one that I will still have a few years from now. For now I have not moved<br>past the point of comprehension being important to me.

Given this desire, there is something I lack with my experience of code written<br>without me paying attention, particularly from loops. Present-day models tend<br>to produce code that is too defensive, too complex, too local in its reasoning.<br>They avoid strong invariants. They add fallbacks instead of making bad states<br>impossible. They duplicate code, invent bad abstractions, and paper over<br>unclear design with more machinery. Worse though: I so far see very little<br>progress of this improving. If anything, on that front it feels to me that<br>we might even be making steps in the wrong direction. At least for my taste,<br>present-day hands-off harnesses like Claude Code with ultracode produce worse<br>code than what we were producing last autumn. That’s because Claude Code, with<br>Fable for instance will be working uninterrupted on a problem for thirty minutes<br>or more, when previously the process would have been much more human in the<br>loop.

Furthermore it’s well understood that models tend to observe some local failure<br>and add a local defense. Karpathy<br>mentioned how they are<br>“mortally terrified of exceptions”. In systems with important invariants,<br>especially persisted data formats or core infrastructure, the right fix is not<br>"handle every malformed case." The right fix is to make the malformed case<br>unrepresentable or impossible to write in the first place. Yet even with a lot<br>of manual steering, that type of code does not come out of LLMs naturally, and<br>even if the code comes out naturally like that, they will still attempt to<br>handle now impossible errors.

When you take that behavior and you put it behind loops, you tend to amplify it.<br>If each iteration adds another small defense, the system slowly becomes less<br>understandable while appearing more robust. The more hands-off you are, the<br>more that happens. It also teaches really bad practices when tools like this<br>are given to juniors without clear guidance. Because if you ask them, why they<br>are doing all that, they will convincingly argue their case.

Where Loops Work

At the same time, it would be dishonest to pretend the loop pattern does not<br>work because it already works astonishingly well in some domains.

Porting code one of them. There are already impressive examples of large<br>automatic porting efforts, including the reported work around moving parts of<br>Bun from Zig to<br>Rust. I have<br>used it with success myself to port MiniJinja to<br>Go. Performance explorations are another case<br>where this works beautifully. A machine can try experiments, benchmark them,<br>discard failures, and keep searching. Security scanning fits naturally too and<br>so does almost any type of research: asking a...