The Ralph Wiggum Loop: The Dumbest AI Coding Technique That Actually Works

The most influential pattern in AI coding right now is a five-line bash script named after a Simpsons character who eats paste.

This is not a joke. Or rather — it is a joke, deliberately, but the joke is doing real work. Practitioners who initially dismissed it are now running it overnight and waking up to pull requests. A senior engineer at Anthropic called the technique “a vast improvement over any other AI coding orchestration setup I’ve ever tried.” The person who invented it declared “software development is dead — I killed it” and started pricing software at $10.42 an hour.

So let’s talk about Ralph.

The five-line version

Here is the entire technique in its purest form:

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

That’s it. An infinite bash loop. Every iteration reads the same prompt file and feeds it to a fresh Claude Code instance. The prompt never changes. The agent runs, does one thing, exits. The loop restarts. A new agent spawns with zero conversational history and reads the same prompt again.

Geoffrey Huntley, the Australian developer who invented this, describes Ralph as “deterministically bad in an undeterministic world.” The pattern isn’t smart. It doesn’t need to be. It runs the same dumb loop over and over, and the dumb loop produces software.

His favorite line for explaining it:

“Better to fail predictably than succeed unpredictably.”

Why “Ralph Wiggum”?

The name is a self-deprecating joke. Ralph Wiggum is the Simpsons character famous for earnest, unshakable persistence in the face of obvious failure — his catchphrase “me fail English? That’s unpossible” being the canonical example. Huntley picked the name because the technique is, on its face, ridiculous. A five-line bash loop shouldn’t work. But Ralph is persistent, and persistence with a fresh context window every iteration turns out to be enough.

The Tessl blog summarizes it neatly: Ralph embodies “ignorance, persistence, and optimism.” The joke in the name is the thesis of the technique.

How it actually works

Strip away the bash and you get the actual pattern:

1. Fresh context every iteration. A new Claude Code instance, zero conversational history, no memory of prior attempts.
2. State lives in files. Git history. Modified files. An IMPLEMENTATION_PLAN.md. A progress.txt. The filesystem is the memory layer.
3. One task per loop. Huntley is explicit: “You need to ask Ralph to do one thing per loop. Only one thing.”
4. Backpressure through tests. The agent runs the type-checker, the linter, the tests. Failing tests are a signal. The agent iterates on its own output until the checks pass.
5. Commit on green. When tests pass, commit. Git becomes the ratchet that prevents regressions.
6. Exit. Restart. Repeat. The outer loop starts a new agent, which reads the same prompt, looks at the filesystem, picks the next task, and does it.

The critical move is step 1. Every iteration is a blank slate. There’s no context rot because there’s no context to rot. The agent’s “memory” is whatever you wrote to disk last iteration. If you didn’t write it to disk, it’s gone.

Huntley puts it like this:

“Your files and git history are a better memory layer than the LLM’s context window.”

Steve Kinney gives the cleanest explanation of why this works: AI agents “get worse the longer you talk to them” because “every failed attempt, every tangent, every correction stays in the conversation history.” Ralph throws away the conversation history between every iteration, so it can’t hurt you.

The origin story

Ralph first appeared in public in May 2025 on Huntley’s blog. The technique went quietly viral in the back half of 2025 after Huntley demoed it at a small agentic coding meetup.

Dex Horthy at HumanLayer tells the origin story from the audience side. He describes an event with about fifteen people in June 2025, where Huntley arrived two hours late and “completely stole the show, diving deep on ralph, cursed lang, and the surrounding methodologies.” That was the inflection point. Within a few months, Ralph had its own tutorials, plugins, podcast episodes, and a small industry of blog posts.

It also had its own three-month case study. Huntley ran a single Ralph loop for three months that built an entire programming language from scratch. He called the language Cursed. His description:

“It’s cursed in its lexical structure, it’s cursed in how it was built, it’s cursed that this is possible.”

Make of that what you will.

What Ralph is actually good at

The technique is optimized for a very specific shape of problem: greenfield code, well-defined end state, lots of small steps, good test coverage as backpressure. When that fits, Ralph is genuinely remarkable.

The practitioner accounts all hit the same beats:

Rich Tabor wrote about waking up to “five pull requests this morning. Passing tests, clean commits, generated PR descriptions.” His framing of the shift:

“This is what product management looks like now. My job is less ‘writing specs’ and more thinking clearly, making good calls, and steering the system while it moves.”

Matt Pocock, who has become one of Ralph’s biggest amplifiers, puts it more bluntly:

“There’s an AI coding approach that lets you run seriously long-running AI agents (hours, days) that ship code while you sleep. I’ve tried it, and I’m not going back.”

The key Pocock insight that’s worth internalizing even if you never run Ralph:

“The rate at which you can get feedback is your speed limit.”

That’s the real argument for the loop. It’s not that Ralph is smarter than you. It’s that Ralph iterates at machine speed instead of human speed. If each iteration is mostly right, and the wrong iterations are cheap, the aggregate is better than what you’d get by hand.

What Ralph is bad at

Huntley himself is the loudest voice on Ralph’s limits. Two important ones:

“There’s no way in heck would I use Ralph in an existing code base.”

Ralph is for greenfield. The pattern depends on the agent being able to understand the full state of the project from the filesystem plus whatever’s in IMPLEMENTATION_PLAN.md. In a 300,000-line legacy codebase with implicit conventions, undocumented integrations, and historical scars, that’s not enough context. You’d want something more like Research-Plan-Implement there.

“You really want to babysit this thing.”

The AFK (“away from keyboard”) coding promise — sleep while your agents work — is overstated. Practitioners who’ve run Ralph seriously report that you need to be watching the logs, tuning the prompt, and intervening when the loop starts going sideways. The cost of a Ralph run that goes off the rails is measured in API tokens, and it adds up fast.

There are other specific failure modes the community has named:

Overcooking. The loop runs forever. The agent starts adding features nobody asked for. The end state is poorly defined, so the agent never decides it’s done.

Undercooking. The completion detection fires early. The agent declares success and exits, leaving the project half-finished. This is especially common with the Anthropic official Ralph plugin, which uses a <promise>DONE</promise> marker that agents are sometimes too eager to emit.

Markdown state corruption. LLMs introduce subtle formatting errors in state files. The next iteration misreads them. The loop degrades silently.

Cost. A 50-iteration Ralph run in Opus can cost $50–$100+. Overnight loops can be much more. People who’ve done this at scale tend to run cheaper models for most of the loop and escalate to Opus only for hard subtasks.

Vendor lock-in. The original flavor is Claude Code only. Variants exist for Goose, Codex, Copilot CLI, and Amp, but the tooling is still maturing.

Matt Pocock has also written a critical piece about Anthropic’s own plugin, arguing that it doesn’t actually reset context between iterations (it uses a hook-based mechanism inside a single session), which means it still suffers from context rot. His position is that the plain bash loop is superior to the official plugin. This is the kind of disagreement that tells you the pattern is being taken seriously.

Ralph and RPI: not opposites

A confusion worth clearing up: people sometimes frame Ralph and Research-Plan-Implement as competitors. They aren’t. They solve different problems.

• RPI is for complex tasks in existing codebases where you need to understand the terrain before you build on it. It’s human-driven, phase-based, structured.
• Ralph is for greenfield work where the end state is clear and the path to it is a lot of small steps. It’s agent-driven, iterative, uniform.

The overlap is context engineering. Both patterns exist because the naive approach — one long chat with the model, let it cook — breaks down past a certain complexity. Both of them work around the same underlying constraint: the model is better when its context window is fresh and focused.

Dex Horthy, who invented RPI, publicly endorses Ralph. Huntley, who invented Ralph, has talked about Dex’s work at HumanLayer. These are complementary tools in the same toolbox, and the people at the frontier use both depending on the job.

The bigger claim

The reason Ralph gets so much attention isn’t really the technique. It’s what Huntley argues the technique implies about the economics of software development.

His claim, which he makes loudly and repeatedly: if a $10.42/hour loop can produce working software autonomously, the pricing model for software engineering is going to change. Fast. He titled one of his posts “Software development now costs less than a minimum wage worker.”

“Software development is dead — I killed it. Software can now be developed cheaper than the wage of a burger flipper at maccas, and it can be built autonomously whilst you are AFK.”

This is the part where reasonable people disagree hard. Ralph working on a greenfield toy project is not the same as Ralph working on a Fortune 500 backend with compliance requirements. The claim is provocative and deserves skepticism. But it’s also not crazy. Ralph is a real thing that produces real code, and the cost curve is moving in a direction that makes the claim less crazy every quarter.

How to actually try Ralph

If you want to experiment with Ralph without committing to anything, the setup is almost embarrassingly simple:

# 1. Write PROMPT.md — describe the end state, not the steps
# 2. Write IMPLEMENTATION_PLAN.md — the agent updates this as it goes
# 3. Make sure your project has tests and lint/typecheck commands
# 4. Run:
while :; do
  cat PROMPT.md | claude-code
done

Things to include in PROMPT.md:

• The end state, in concrete terms (what should exist when this is done)
• The commands for tests, lints, typecheck — the agent uses these as backpressure
• Where to read state from (IMPLEMENTATION_PLAN.md, progress.txt, git log)
• The single rule: “Do one thing per iteration. Then exit.”

Things to watch:

• Token burn. Set a budget and check it.
• The git log. If the commits are making sense, Ralph is working. If commits are reversing each other, the loop is eating itself.
• The IMPLEMENTATION_PLAN.md file. It’s the agent’s working memory. If it’s getting incoherent, the prompt needs tuning.

Huntley’s GitHub playbook has more detailed templates and the community-maintained awesome-ralph list tracks variants across tools.

Why it matters even if you never run it

You might read all of this and decide Ralph isn’t for you. That’s a reasonable position. Greenfield projects where a bash loop can ship real features are not the majority of real-world engineering work.

But the pattern is teaching you something useful even if you never touch it:

1. Fresh context beats long context. Every pattern that’s working right now relies on this insight.
2. Files are a better memory than conversation. Anything important should be on disk, not in chat history.
3. Tests are your guardrails. The pattern only works because tests give the agent honest feedback. No tests, no Ralph.
4. Iterate cheaply. The speed limit on AI-assisted development is your feedback loop, not the model.

These are the same lessons the Research-Plan-Implement pattern teaches from a different angle. They’re the lessons of what the community is now calling context engineering, and they’re the closest thing the field has to a settled consensus right now.

Ralph is the dumbest implementation of those lessons. That’s why it’s named after Ralph Wiggum. That’s also, somehow, why it works.

---

LazyRalph takes the lessons from patterns like Ralph and RPI and makes them visual — you can see every iteration, every artifact, every decision the agent makes. Join the waitlist below.