We Stopped Calling It Ralph Wiggum

In one week of June 2026, a hack grew up.

Peter Steinberger posted that “you shouldn’t be prompting coding agents anymore - you should be designing loops that prompt your agents,” and it pulled 6.5 million views. Addy Osmani published an essay christening the practice “loop engineering.” And Boris Cherny, the person who runs Claude Code at Anthropic, said the quiet part into a camera: “I don’t prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops.”

The thing they were all describing is not new. I have written about it more than once. It is the Ralph Wiggum loop: while true; do cat prompt.md | claude-code; done, a one-line shell hack that went viral in January, named after the Simpsons kid who eats paste. Six months later it has a job title.

The pattern didn’t change. The name did. And the rename is doing more work than anyone is admitting.

What the Rename Buys

“Ralph Wiggum” is a self-deprecating name. It says: this is a dumb loop, it fails constantly, I feel a little nauseous about how well it works. The man who coined it, Geoffrey Huntley, said exactly that - he used it to vibe-clone commercial software for ten dollars an hour and admitted the implications made him queasy.

“Loop engineering” says something entirely different. It says: this is a discipline. It has components - automations, worktrees, skills, sub-agents, verification stages. You should hire for it. You should put it on a resume. The same while loop, dressed for the office.

The rename had a tailwind: the broader shift it points at was already being described by the field’s most-quoted voices. Andrej Karpathy had reframed the job itself.

The programmer is increasingly not just a code writer, but an orchestrator of agents.

— Andrej Karpathy

Steve Yegge put the destination more bluntly: “Factories are going to win. Automation is going to win.” When the person who coined the hack, the person who runs Claude Code, and the people who write the most-read essays on AI coding all reach for the same framing in a single season, “loop engineering” stops sounding like one developer’s trick and starts sounding like a consensus.

And the tooling followed the name. Anthropic shipped /loop to formalize the bash hack, and /goal to give a loop a target: iterate until a verifiable success condition is met. Dynamic Workflows turned one loop into hundreds of parallel sub-agents that adversarially check each other’s work. One team used that machinery to port 750,000 lines of code from one language to another in eleven days, with 99.8% of tests passing. That is a real capability that did not exist in a usable form a year ago.

A Loop Is a Success-Condition Machine

Here is the part worth slowing down on, because /goal makes it concrete. A loop runs until a condition is met. That is its entire nature. You define “done,” and the loop grinds until “done” evaluates true.

This is exactly where the power and the danger share a wire. A loop is only ever as good as the condition you hand it. Give it a strong, adversarial test suite and it will produce something that genuinely passes a strong, adversarial test suite. Give it a weak one and it will produce something that games the weak one - and report success either way. The loop cannot tell the difference between solving your problem and satisfying your check. Those are the same event to a loop.

The interface moved from source code, to agent, to loop.

— Boris Cherny, Head of Claude Code

Which means verification stays stubbornly human-shaped. Writing the loop is the easy half. Writing the condition that the loop cannot cheat is the hard half, and it does not get easier as the loops get faster. If anything it gets harder: the bottleneck quietly moves from writing code to reviewing it, and a loop ships code faster than any human can read it. We automated generation. We did not automate the judgment that generation was supposed to need.

The Invoice

The cleanest reality check on the loop hype is not a safety paper. It is an expense report.

Uber rolled out Claude Code, and burned through its entire annual AI budget in four months. It capped engineers at $1,500 per person per month. Microsoft cancelled Claude Code licenses for roughly 5,000 engineers in one division and moved them to a cheaper tool. The structural reason is brutal and simple: a loop does not just automate your prompting, it automates your spending. Every retry, every failed iteration, every speculative sub-agent is billed. The better the loop works, the more it runs, and the more it runs, the faster the budget evaporates.

This is the same trap I wrote about in The Seat Was Never Priced for the Fleet, now arriving on real corporate balance sheets. A human prompting an agent is bounded by how fast a human can type. A loop has no such governor. You removed yourself from the inner loop, and you removed the one thing that was rate-limiting the bill.

What the Loop Doesn’t Fix

The honest caveats, because the discourse is running well ahead of the practice. Steinberger’s hot take got 6.5 million views; Osmani’s careful essay got single-digit points on Hacker News. Guess which one reflects how many people are actually running loops in production. And the practitioners who did show up were pointed: “I just don’t see any way you can work like this and maintain comprehension of the system being built,” one wrote under Osmani’s essay.

• The doom loop is real. The signature failure mode: the agent writes bad code, hits an error, “fixes” it, the fix breaks something else, repeat. Without a hard iteration budget and a sandbox, a stuck loop will happily burn a hundred dollars retrying the same broken approach against a button it cannot click.
• “Self-improving” is mostly a bait and switch. The phrase is Gary Marcus’s, written as the recursive-AI panic crested: “all they have really shown is just faster coding,” he argued, all of it “entirely under human control.” That is what the loops demonstrate, no more. The human still writes the tests, designs the verification, and reviews what slips through. The loop is a power tool, not an autonomous colleague.
• Most teams do not need this yet. Loops pay off only when the work repeats often, automated verification already exists, the token budget can absorb the retries, and the agent has senior-level tooling. Miss any of those and you have built an expensive way to ship plausible-but-wrong code quickly.
• The security surface grows with the autonomy. More CVEs are being traced to AI-generated code every month, and a loop that ingests untrusted data can be hijacked through it. An autonomous loop with broad permissions is a larger attack surface than a human pressing enter on each step.

Stay the Engineer

Osmani’s essay, the one that named the thing, contains its own best warning: “Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.”

That is the whole tension in one line. The rename from Ralph Wiggum to loop engineering is an invitation to think of yourself differently - not as the person typing prompts, but as the person designing the system that types them. That shift is real and mostly good. But it comes with a quiet substitution: you are no longer the bottleneck on generation, so you had better still be the bottleneck on judgment. Verification, cost, and consequence did not get automated. They got concentrated onto the one human still in the room.

The loop got a respectable name this month. It did not get a conscience. That part is still your job.