Armin Ronacher on where letting coding agents loop goes wrong

Armin Ronacher, the engineer behind Flask, has written a careful piece on what happens when coding agents run in loops with little human review. He separates two kinds. The inner loop is an agent calling tools inside one session. The outer loop is a harness that runs an agent again and again, with a human or another machine judging each pass. The outer loop is the one taking over, and it worries him.

His sharpest observation is about how the code degrades. A model, he writes, tends to notice some local failure and add a local defense, then another, then another. Across many iterations this produces systems that are defensive, duplicative, and complex, the opposite of clean design built on strong invariants. The result is hard for a human to hold in their head. Loops do work well, he argues, on tasks that are mechanical or disposable: porting code between languages, exploring performance changes, scanning for security issues, doing research where the output is temporary. They struggle exactly where long-lived architecture and human comprehension matter most.

Ronacher does not think anyone can opt out. Teams that use loops well will move faster than teams that do not, the same way an attacker running automated loops forces defenders to answer in kind. His real concern is comprehension: codebases that assume a machine will always be present to diagnose and maintain them, becoming organisms to be monitored rather than machines a person can fully understand. The question he leaves open is how to keep human judgment in a process designed to run without it.

Why it matters

If you are deciding where to let agents run unattended, this gives you a usable line: mechanical or throwaway work is fair game, but core architecture you will maintain for years is where the loop quietly costs you. Watch for the pattern of stacked local fixes in agent output, because that is the early sign your codebase is drifting toward something only a machine can read.