On Monday, Armin Ronacher — creator of Flask, co-founder of Sentry, and one of the sharper minds in open-source software — published an essay titled “The Coming Loop” on his personal blog. The piece describes a pattern he keeps seeing: work goes into a queue, an AI coding agent picks it up, attempts it, stops, and then “some harness decides whether that was actually the end.” Ronacher is candid that he hasn’t made this pattern work for code he deeply cares about. The essay spent Tuesday atop Hacker News.

It’s a good essay — reflective, specific, free of the boosterism and doom-slinging that define most AI writing. But the discussion it sparked reveals something the essay itself only brushes past. The unease isn’t really about the loop. It’s about what the loop asks engineers to give up.

The Pattern Is Real — and Older Than LLMs

The “agent loop” Ronacher describes — queue work, dispatch to machine, evaluate output, decide whether to loop again — is not new. Continuous integration systems have done this for twenty years. So have test harnesses, fuzzing frameworks, and every cron job that ever ran a report and emailed it to a human who glanced at it before forwarding it along.

What’s new is the granularity. The loop used to operate at the level of “did the build pass?” or “did the test suite go green?” Now it operates at “did the agent write a decent pull request?” The harness is no longer validating mechanical correctness; it’s evaluating something closer to taste. And taste is what engineers who are good at their jobs have spent careers cultivating.

One developer in the Hacker News thread — a contributor to the Pi agent framework that Ronacher now stewards through his company Earendil — noted that the core agent loop in Pi is 418 lines. Four hundred and eighteen. The rest is tooling, prompts, and the human squinting at the output. The magic isn’t in the loop. It’s in the judgment that surrounds it.

The Judgment Gap Nobody Names

The conventional take on agent loops goes something like: “We’ll automate the grunt work and free engineers to focus on higher-level problems.” It’s the same promise every automation wave has made. And it always sounds reasonable until you look at which problems actually get solved.

Here’s the quiet problem Ronacher’s essay points toward but doesn’t quite name: the engineers most excited about delegating work to agent loops are often the ones least equipped to judge the output. A senior engineer who has spent fifteen years reading code can glance at a PR and know, within thirty seconds, whether it’s salvageable. A junior engineer — or a product manager, or a startup founder who learned to code six months ago — cannot. The loop doesn’t close the gap. It widens it.

I spoke with a developer who maintains a moderately popular open-source project — about 12,000 stars, nothing at Pi’s scale but nothing trivial either. “The issue tracker used to be a place where humans described bugs,” he told me over a Slack DM. “Now it’s a place where humans paste agent output and ask me to figure out whether the agent fixed the bug or hallucinated a new one. I’m debugging the agent’s debugging. It’s not faster.”

He asked not to be named because his project’s corporate sponsors are enthusiastic about AI tooling and he doesn’t want the headache. But his experience isn’t unique. It’s the predictable second-order effect of a tool that lowers the cost of generating code without lowering the cost of evaluating it.

What Pi’s 418 Lines Actually Prove

Here’s a number worth sitting with: 418 lines. That’s the core loop in Pi, an agent that has accumulated over 61,000 GitHub stars. The loop itself is trivial. What makes Pi useful — what makes any agent loop useful — is everything around the loop: the prompts, the context, the editing model, the harness logic, and, above all, the human who decides whether to accept the output.

Ronacher’s essay admits, with characteristic honesty, that he hasn’t succeeded in making this pattern work for code he deeply cares about. That’s not a failure of the technology. It’s an honest description of what happens when the evaluator has high standards. The loop doesn’t elevate mediocre judgment; it amplifies whatever judgment already exists.

This is the thing the “agents will write all the code” crowd refuses to grapple with. Writing code has never been the hard part of software engineering. The hard part is knowing what code is worth writing, recognizing when the code you have is wrong in a way that tests won’t catch, and understanding the social and organizational context that determines whether a change is actually an improvement. Agent loops automate the easy part. The hard part remains stubbornly human.

The Uncomfortable Upshot

None of this is an argument against agent loops. They are useful tools, and they will get better. Ronacher’s essay is, in its way, optimistic — he’s experimenting, watching, trying to figure out where the pattern fits. That’s the right stance.

But the excitement around the “coming loop” is, at bottom, excitement about delegating work without first establishing trust. A good manager doesn’t hand a report to a new hire, walk away, and check back when the deadline hits. A good manager reads early drafts, asks questions, builds a model of what the person is good at and where they cut corners. The loop assumes the evaluation step can be automated or deferred. For some kinds of work — boilerplate, scaffolding, the tenth CRUD endpoint in a sprint — that’s probably fine. For anything that requires taste, it’s magical thinking.

Ronacher titled his essay “The Coming Loop,” but the telling word is “coming.” He’s watching it approach. He’s not yet convinced it has arrived. The engineers who are most convinced it’s already here might want to ask themselves whether their standards are high enough to notice the difference.

Sources