"The Coming Loop" — Armin Ronacher

Verdict: READ (shorter than Osmani's, ~10-15 min). Not a how-to — an argument. It is the sharpest available external articulation of exactly the failure mode RDCO's brigade ceremony (gates, work log, critic/expo split, execution-eval) exists to prevent. Worth reading end to end once rather than skimming; it doesn't decompose into a checklist the way Osmani's does.

Why this is in the vault

Companion read to Osmani's practitioner "how" ([[2026-07-04-addy-osmani-loop-engineering]]) — Ronacher is the "should we, and what does it cost us" counterweight. Published 2026-06-23. Do not assume he's a knee-jerk skeptic going in: read what he actually says. He does not dispute that loops work. His unease is about what looping does to code comprehension, human judgment, and long-term maintainability — directly relevant to why RDCO built the ticket as an append-only build record with a critic that only advises.

The core argument

Ronacher's own framing is mixed, not a flat "no": "I have not had much success with this way of working for code I deeply care about," but also "I have little doubt that this is where things are going." His stated posture: "I'm very uneasy about this future. Not cause of fear, but because of caution."

He opens with the same Boris Cherny epigraph Osmani's essay orbits ("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.") — but uses it as evidence the trend is real, not as an endorsement.

His argument runs through five moves:

1. "I Am Not Good At This Yet." Present-day models, in his experience, produce code that is "too defensive, too complex, too local in its reasoning" — models are, in his phrase, "mortally terrified of exceptions," papering over unclear design with fallback branches rather than making bad states structurally impossible.
2. "Where Loops Work." He's specific about the category where he thinks loops genuinely earn their keep: porting, performance exploration, security scanning, and other work that produces "artifacts without necessity of longevity." He cites his own successful MiniJinja-to-Go port and the Bun (Zig-to-Rust) port as concrete examples where this held.
3. "Software As Organism." The deeper shift: software stops being a machine you comprehend and becomes something closer to an organism you manage without fully understanding — "we treat it, we monitor it, we stabilize it, but we do not necessarily comprehend it."
4. "You Cannot Quite Opt Out." Competitive and security pressure forces adoption regardless of personal taste: "if attackers and reporters loop, defenders will eventually need to loop too" — he cites AI-generated security-report noise overwhelming maintainers (naming curl's Daniel Stenberg) as an already-live instance.
5. "Controlling Loops." His core fear, stated plainly: harness-level loops (external orchestration, work queues, context injection — distinct from the agent's own internal tool-call loop) risk reducing the human to "a messenger," merging code nobody on the team can fully explain.

Author bio / bias read

The essay itself does not disclose institutional affiliation — no mention of Sentry, Flask, or any employer in the fetched text. Outside-context flag, not sourced from the piece: Armin Ronacher is widely known as the creator of Flask/Jinja2 and a co-founder of Sentry; that vantage point on open-source maintenance plausibly informs the curl/security-noise point, but the essay doesn't say so and this note can't verify how much it shaped the argument — treat the connection as plausible context, not a disclosed conflict.

Bias read: this is the cleaner of the two pieces on bias grounds specifically because it isn't selling a taxonomy, a product, or a company — no sponsor block, no vendor pitch, a personal essay grounded in his own porting projects (MiniJinja, and his stewardship of a project he calls "Pi," where he states he "would not want Pi to… promote this type of engineering" unreservedly). If anything his incentive runs the other way from hype: as someone who built and maintains real infrastructure, he has more to lose from comprehension debt than to gain from boosting the trend.

What's genuinely new vs. repackaged

• New signal for RDCO: "comprehension debt" and "software as organism" as an explicit named articulation of the exact risk the brigade's audit-trail design already exists to counter — the ticket's append-only work log, the resolved-context snapshot, and the critic-ADVISES/expo-DECIDES separation are structurally built to prevent "my role is reduced to that of a messenger." This doesn't change RDCO's design, but it's a sharp external validation worth quoting back when explaining why the ceremony exists to someone skeptical of process overhead.
• Genuine gap worth naming: a disposability/longevity axis. Ronacher's "where loops work" (disposable, exploratory, non-permanent artifacts) vs. "where they don't" (code you deeply care about, needs invariants) is a real distinction the brigade's ticket schema doesn't currently make explicit — see the mapping note for detail.
• Repackaged from RDCO's vantage: his implied verification methods (binary test cases, LLM judges/orchestrators, mechanical translation checks for ports) map directly onto execution-eval's two-arm ablation and fixture suite, which RDCO already built and which is arguably a more rigorous answer to his concern than anything he describes in the essay — see mapping note.

Related

• [[2026-07-04-addy-osmani-loop-engineering]] — the practitioner "how"; read as a pair with this "should we" piece
• [[2026-07-04-loop-engineering-vs-agent-brigade]] — full anatomy-to-brigade mapping table, including honest gap-check
• [[2026-06-29-cherny-five-archetypes-agent-native-roles]] — Cherny's role-taxonomy piece; his "I don't prompt Claude anymore" line is the epigraph this essay opens with