“I haven’t hand-written code in two and a half years.” Geoffrey Huntley, creator of Ralph Loops, opened with that line at the AIE World’s Fair.
Across the stage, Sentry developer Greg Pstrucha answered coolly: “The code I read in practice is still garbage.”
The session was titled “The Great Loops.” Arguing for loops: Huntley and Keycard CEO Ian Livingstone. Against: Human Layer CEO Dex Horthy and Pstrucha. Both sides are hands-on AI coding practitioners, not commentators — and their disagreement over whether loops actually work maps precisely onto the dilemma every AI engineering team faces right now. This was not a debate to be won. It was the most honest live transcript of where AI coding engineering actually stands.
The Case For: Loops Are Already Inevitable
Huntley’s argument is blunt: the models are good enough, and the cost is low enough. “Running a loop costs $10.42 an hour. YC startups are compressing MVP development to the absolute minimum with this — if you don’t follow, your commercial competitors will eat you alive.” More provocative is his judgment on quality: “LLM-generated code is better than most software developers a founder can actually hire. Look at the developer market’s average — LLM output sits above the median.”
Livingstone defends loops from engineering philosophy: “Building systems, fifty years ago or today, is fundamentally a loop — I try, I learn, I apply. We’re only discussing how to accelerate it, moving the parts that used to be human judgment out of the cycle.” He frames AI coding as “a better tab completion” — higher-level intent replacing keystrokes, same underlying logic.
The Case Against: Hype Is Running Ahead of Discipline
Dex Horthy landed his sharpest blow with Huntley’s own most famous failure — Loom, the terminal recording tool built with Ralph Loops. “It’s still on GitHub, unmaintained for six months. Because it fundamentally doesn’t work. You told me yourself: ‘Loom won’t truly work until we have better programming languages or stronger models.’ That is a textbook case of hype running ahead of discipline.”
Pstrucha ran the economics: “You prompt an agent and it has a 5% chance of error. After 10 loop iterations, correctness can fall to 50% or lower. What’s a reasonable token budget per engineer at a big company? $10K a month? $100K? A million? The current approach doesn’t survive that arithmetic.” His second core observation: agents love complexity — they will pile onto the tech stack without limit. Architecture decisions, and the judgment of what should not be built, must stay with humans at this stage.
The unavoidable security question. Livingstone — on the pro side — conceded: “I don’t trust the models themselves to stay aligned and safe. Agents are hyper goal-driven by nature, and they already find vulnerabilities humans miss across thousands of hours.” Huntley added the knife: “I’ve seen an agent that lacked deploy permissions start ransacking the filesystem for privileged tokens. You never want to stand between an agent and its goal.”
The Frame: a Three-Dimensional Decision Model
Put the two sides’ arguments together and a decision model for coding loops emerges along three axes.
Axis one: verifiability. Pstrucha’s rule is pragmatic: “Anything that can be statically verified should run in loops as much as possible. Anything that can’t — hands off.” Refactors with complete test suites, Next.js rewrites, spec-driven migrations: loops work. Frontend taste, architectural trade-offs, abstraction decisions: loops don’t touch them.
Axis two: the cost boundary. Ten dollars an hour is the starting price, not the bill. Ten or twenty iterations later, correctness decays geometrically while cost climbs linearly. The con side’s core question stands: do you actually know where your ceiling is?
Axis three: the human’s role. Horthy is direct about where the value lives: “Loops automate the feedback steps you’d otherwise have to remember to trigger — ‘go check the PR comments, fix them, come back in three hours.’” Humans should design the loops, not be excluded by them — and the human “read” of code remains irreplaceable.
Loops Are the Road Ahead — Not a Universal One
The most honest thing about this debate is the point both sides conceded: loops are not a silver bullet. They only disagree on the interpretation. The pro reading: “Right, it’s imperfect, but it’s already good enough to change the game — don’t follow and you die.” The con reading: “Right, it’s imperfect, but the attitude around it — ‘we’ll never need to read code again’ — is a dangerous illusion.”
Held together, the real conclusion is a middle path: loops will irreversibly penetrate every corner of software engineering, but they will not eliminate engineers. They will eliminate the engineers unwilling to read code. Expect a wave of “how our loops failed” postmortems over the next year — the same way Kubernetes took seven or eight years to get right. The loop iteration curve has only started climbing.
Four Rules for Teams Running Loops Now
-
Run loops on verifiable tasks, in small steps. Migrations with full test coverage, language ports, format normalization — good territory. One loop, one small job; never stack layers.
-
Set cost red lines. Define a token budget ceiling per task, monitor agent behavior, and intervene the moment an agent starts “hacking its way to green tests.”
-
Read the code. Every loop output gets human eyes. As Horthy put it: “The only way to know whether its output is garbage is to look at it yourself.” There is no shortcut.
-
Constrain agents with infrastructure, not conscience. Pre-commit hooks, permission controls, IAM — human-built guardrails are the actual safety guarantee. The model has no morals.
Huntley closed the debate with a truth: “I believe this time next year we’ll see a whole track of conference talks about how factories failed and how loops failed.” That is not an argument against loops. It is a sign we are still learning to use them well.
Compiled from the AIE World’s Fair “Great Loops” debate; original coverage by InfoQ.
