The patch opens the attack window.

"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."

That line, from Boris Cherny, opens Armin Ronacher's June 23, 2026 essay on where agentic coding is heading. Ronacher's point is that a second loop has grown up around coding agents. The first loop is familiar: inside a coding agent, the model calls a tool, reads the result, edits a file, runs tests, and eventually produces an answer. The newer loop sits outside that. A harness pulls work off a queue, lets a machine attempt it, and then decides whether the machine was actually finished. If it decides the answer is not good enough, it continues the same session, injects another message, starts a fresh session with modified context, or sends the task to a different machine. The work stays alive past the point where the model on its own would have said it was done.

For code he cares about, Ronacher does not trust this yet. His complaint about current models is specific. They write code that is too defensive, too complex, and too local in its reasoning. They avoid strong invariants. They add fallbacks instead of making bad states impossible to write. They duplicate code and invent abstractions to paper over unclear design. He cites Karpathy's description of models as "mortally terrified of exceptions." In systems that depend on real invariants, like persisted data formats or core infrastructure, the correct fix is usually to make a malformed state unrepresentable, not to add a handler for it. Models rarely produce that kind of code, and when they do, they still bolt on handlers for the cases they have just made impossible. Run that behaviour inside a loop and every iteration tends to add one more small defence, so the system drifts toward something harder to understand while looking more solid.

The loop pattern already works well in places, and Ronacher is clear about which. Porting is one: he points to the reported effort to move parts of Bun from Zig to Rust, and to his own port of MiniJinja to Go. Performance work is another, since a machine can try an experiment, benchmark it, throw away the failures, and keep searching. Security scanning fits the same shape, as does research that explores a problem and reports back without committing lasting code. What these share is that they either transform code that already exists or produce artifacts with a short shelf life, proof of concepts rather than something meant to be maintained for years. Many of them use another model as the judge. The harness does not need an objective, binary signal. It needs a signal good enough to justify the next iteration.

The part that reaches everyone is security. You can decline to build with loops and still have loops aimed at you, because other people will run them against your software. Attackers will run machines continuously, and so will security researchers, whose automated work surfaces both real bugs and noise, arriving at a volume that is hard to handle without a machine on your side. Ronacher points at curl. Daniel Stenberg's "summer of bliss" post describes maintainers already swamped by reports, most of them now AI-generated, even though AI plays little part in curl's own development. His expectation is that once attackers and reporters loop, defenders loop too, if only to triage and reproduce what lands in the queue.

Some teams have already pushed loops into incident response. Ronacher describes a workflow where a production issue is met first by a model that reads the logs, proposes root causes, and puts up a patch. Another machine reviews that patch, and sometimes lands it on main with no human looking at it.

That is where his unease sharpens. A codebase written, reviewed, patched, and kept running by loops assumes machine participation as part of how it is maintained. His question is what happens when that assumption breaks: when the cost becomes too high, when trade restrictions cut off the most capable models, or when a team loses the ability to read its own code without one. He sees smaller versions of it already, people merging changes they cannot explain and rephrasing their own bug reports and chat messages through a model before sending them.

Ronacher expects this future regardless of his discomfort with it, and says so plainly. He does not offer a way out of looping. The useful part for anyone already running these systems is the set of problems he says the tooling has not solved: keeping a human able to supervise, making the changes a loop produces legible over time, and architecting code so it stays comprehensible once the loops are doing most of the writing.