Ralph Wiggum as a Software Engineer

My sister is a Simpsons fan. When I told her there’s a plugin called Ralph Wiggum in Claude Code, she thought I was joking. Ralph is the kid who says “Me fail English? That’s unpossible!” and eats glue sticks.

In late 2025, the Ralph Wiggum technique went viral¹. The naming is no coincidence, because the technique works exactly like Ralph stumbles through life, meaning constantly making mistakes, never stopping, somehow reaching the goal.

Geoffrey Huntley, an Australian developer, invented the technique. It consists of a single line of Bash code²:

while :; do cat PROMPT.md | claude ; done

That’s all, an endless loop feeding the same prompt to an AI agent over and over. Claude Code tries to solve the task, ends the session, the loop restarts it immediately. With each iteration, the agent sees its previous work in the files and Git history, learns from its mistakes and gets a little better. The philosophy behind it is surprisingly simple, because Huntley calls it “predictably broken in an unpredictable world”², meaning the idea that predictable failure is better than unpredictable success. Every time Ralph runs in the wrong direction, it’s not the tool, the prompt gets tuned, like a guitar.

This sounds like a gimmick, but the results tell a different story. Huntley ran Claude Code in such a loop for three months and created a working programming language in Gen-Z slang³. At the Y Combinator Hackathon, teams using Ralph loops completed six repositories overnight⁴. One developer finished a 50,000 dollar contract for 297 dollars in API costs.

The Plugin

Anthropic has since turned the technique into an official plugin for Claude Code⁴. The mechanism is elegant in its simplicity. A stop hook intercepts every attempt by Claude Code to end the session, blocks the exit and feeds the same prompt back in, essentially a while true for AI. After installation via /plugin install ralph-wiggum@claude-plugins-official, a loop starts like this:

/ralph-loop \
  "Build a REST API for todos with the following requirements:
   - POST /todos: Create new todo (title required, max 100 chars)
   - GET /todos: List all todos with pagination
   - PUT /todos/:id: Update todo
   - DELETE /todos/:id: Delete todo
   - Validation with error messages
   - Unit tests with >80% coverage
   - All tests must pass
   Output <promise>COMPLETE</promise> when all requirements are met." \
  --completion-promise "COMPLETE" \
  --max-iterations 50

Claude Code will then implement, test, fix bugs. This repeats until all requirements are met or the iteration limit is reached. The art lies in the prompt, because vague instructions like “Build a good API” lead to endless loops without progress, since the model doesn’t know when it’s done. Clear exit criteria, incremental goals and an explicit definition of “done” are crucial.

Ralph works well for tasks with automatic verification, meaning tests, linters, build processes. It works for greenfield projects where you can let the computer run overnight. And it works for tasks where the first attempt is rarely perfect. For design decisions where human judgment is needed, the technique is less suitable, because there targeted action matters more than mere persistence.

And then there are the costs. Autonomous loops burn tokens. A 50-iteration run on a larger codebase can quickly cost 50 to 100 euros or push the current Claude session to its usage limit. The --max-iterations flag is not a minor detail but the most important safeguard against nasty surprises.

The plugin has another limitation I’ve noticed. All iterations run in the same context window, which eventually fills up. Huntley’s original Bash loop starts a fresh process with each iteration, one that only knows what happened before through files and Git history, but the plugin accumulates the entire context.

For longer runs, the classic Bash loop works better. One variant uses a Markdown file as external memory between iterations⁵:

while true; do
  claude "Work on the task in TASKS.md. \
          Update TASKS.md at the end with the current status \
          and what needs to be done next."
done

Each iteration starts with fresh context, reads TASKS.md, works and writes the new status back. The knowledge survives not in the context window but in the file.

And with that, the irony is hard to miss. The most effective method for using AI on complex tasks is obvious: just keep running until it works. No sophisticated orchestration, no complex prompt engineering, just a loop and patience. Whether this works for every task, I don’t know, but Ralph Wiggum succeeds not despite his naivety and clumsiness but because he never stops.

My sister found all of this quite amusing.