The Coming Loop: why outer loops are reshaping software development

Software developer Armin Ronacher published an essay on June 23 titled "The Coming Loop," arguing that the most consequential change in AI-assisted software development is not the coding agent itself, but the outer layer of automation built around it.

The piece opens with a quote attributed to Boris Cherny: "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."

Two loops, not one

Ronacher separates the agent loop inside every coding tool — the model calls a tool, reads the result, edits a file, runs tests — from the harness-level loop that surrounds it. In the second pattern, work goes into a queue, a machine picks it up and attempts it, and then a harness decides whether the task is actually finished. If it is not, the same session continues with an injected message, a fresh session starts with modified context, or the task is handed to another machine.

The outer loop is not new, Ronacher notes, but it has moved from the edges of agentic engineering to the centre of the discussion in recent weeks.

Where it works, and where it does not

The author is candid that hands-off loops have not worked well for him on code he deeply cares about, for reasons of both taste and control: he wants to be able to explain what a system does without asking a model to explain it back. Present-day models, he writes, tend to produce code that is too defensive and too local in its reasoning. They add fallbacks instead of making bad states impossible, duplicate logic and invent weak abstractions. He cites Andrej Karpathy's observation that models are "mortally terrified of exceptions" and argues that loops amplify the habit, because every iteration adds one more small defence.

The pattern works much better, he argues, where the output does not need a long shelf life: porting code between languages — he points to reported work moving Bun from Zig to Rust and to his own port of MiniJinja to Go — performance exploration, security scanning and research tasks. Many successful setups use another model as judge or orchestrator, and the harness only needs a signal strong enough to drive another iteration.

Software as an organism

Ronacher's central worry is a shift from software as a deterministic machine to software as an organism: systems that are monitored, stabilised and treated, but no longer fully understood. Opting out, he argues, is hard. Attackers and security researchers will run automated analysis against any codebase, and maintainers already feel the pressure — he points to Daniel Stenberg's account of the flood of reports reaching the curl project. Competitive pressure runs the same way, with very small teams shipping at speeds that once required far more people.

The essay closes by accepting that loops are coming and reframing the question: not whether teams will run them, but how to avoid abdicating judgement, keep the rules of good engineering, and let responsible humans keep supervising systems built this way.