Ship Code While You Sleep: The Ralph Wiggum Technique
There's an official Anthropic plugin for Claude Code named after Ralph Wiggum from The Simpsons.
Yes, really. And it might be the most important development in AI-assisted coding since... well, since AI-assisted coding.
The premise is absurdly simple: instead of Claude stopping after one attempt at your task, it keeps going. Iteration after iteration. Fixing its own mistakes. Building on previous work. Until the job is actually done.
Geoffrey Huntley, the developer who created the technique, describes it as "a bash loop that feeds an AI's output (errors and all) back into itself until it dreams up the correct answer. It is brute force meets persistence."
The name? A reference to both 1980s slang for vomiting and The Simpsons character known for his combination of ignorance, persistence, and optimism.
That combination turns out to be exactly what you want from an overnight coding agent.
How It Actually Works
The mechanism is almost embarrassingly simple:
- You give Claude Code a task with clear completion criteria
- Claude works on the task
- When Claude tries to exit, a Stop hook intercepts it
- The same prompt gets fed back in
- Claude sees the files it already modified and continues
- Repeat until completion criteria are met (or you hit max iterations)
Here's what it looks like in practice:
/ralph-loop "Migrate all tests from Jest to Vitest.
Output <promise>COMPLETE</promise> when all tests pass."
--max-iterations 50
--completion-promise "COMPLETE"
That's it. You run that before bed. You wake up to a completed migration.
Each iteration isn't starting fresh. Claude sees the git history, the modified files, the errors from previous attempts. It builds on what it learned. Failed attempts tell it what doesn't work. Over iterations, the solution converges toward success.
The Results People Are Actually Getting
This isn't theoretical. People are shipping real work:
Geoffrey Huntley ran a loop for three consecutive months. The prompt: "Make me a programming language like Golang but with Gen Z slang keywords." The result: Cursed, a functional compiler with LLVM compilation to native binaries, a standard library, and partial editor support. Keywords include slay (function), sus (variable), and based (true).
Three months. One prompt. A working programming language.
YC hackathon teams shipped 6+ repositories overnight for approximately $297 in API costs. Multiple complete projects running autonomously while humans slept.
One developer used Ralph to refactor integration tests, reducing runtime from 4 minutes to 2 seconds.
Matt Pocock, the TypeScript educator, put it bluntly: "How it started: Swarms, multi-agent orchestrators, complex frameworks. How it's going: Ralph Wiggum."
We built elaborate agent architectures. The solution turned out to be a bash loop and persistence.
What Tasks Actually Work
Not everything is a Ralph task. The technique shines for work that has two qualities: clear completion criteria and mechanical execution.
Good Ralph tasks:
- Large refactors (framework migrations, dependency upgrades, API version bumps across hundreds of files)
- Test coverage ("Add tests for all uncovered functions in src/")
- Batch operations (documentation generation, code standardization, support ticket triage)
- Greenfield builds with iterative refinement
Bad Ralph tasks:
- Anything requiring aesthetic judgment ("make the architecture cleaner")
- Performance optimization without specific metrics
- Tasks where "done" is subjective
- Authentication, payment processing, or data handling without extensive human review
The common thread: if you can describe "done" precisely and verify it programmatically (tests pass, build succeeds, linter approves), Ralph can iterate toward it. If you're relying on Claude to self-assess completion on something fuzzy, the loop will either run forever (burning tokens) or stop prematurely (declaring false victory).
The Cost Reality
Let's be direct about this: autonomous loops burn tokens.
A 50-iteration loop on a medium-sized codebase can easily cost $50-100+ in API credits. On a Claude Code subscription, you'll hit usage limits faster.
The --max-iterations flag isn't just a safety mechanism. It's cost control.
But here's the math that matters: a $100 loop that saves 20 hours of work is worth it. A $50 loop that burns through iterations without converging is not. The technique rewards prompt engineering. If the first attempt doesn't converge, refine your success criteria and try again.
Some practical cost controls:
- Start with lower iteration limits (10-20) for new task types
- Use specific completion criteria, not vague ones
- Break large tasks into phases
- Monitor progress.txt to catch loops that are stuck early
Setting It Up
Ralph Wiggum is an official Anthropic plugin. Installation:
/plugin marketplace add anthropics/claude-code
/plugin install ralph-wiggum@claude-plugins-official
Basic usage:
/ralph-loop "Your task description"
--max-iterations 30
--completion-promise "DONE"
Cancel an active loop:
/cancel-ralph
The <promise> tag pattern gives Claude a clear signal for when to output the completion marker:
/ralph-loop "Fix all ESLint errors in src/.
Output <promise>LINT_CLEAN</promise> when npm run lint passes."
--max-iterations 15
--completion-promise "LINT_CLEAN"
The Overnight Workflow
Here's how I've been using it:
Before bed: Identify a mechanical task that I've been putting off. Something tedious but well-defined. Write a clear prompt with specific completion criteria. Set reasonable iteration limits. Start the loop.
Morning: Check the results. Either the task is done, or I have a detailed log of where it got stuck. Either way, I'm further along than I would have been.
For batch work across multiple projects:
#!/bin/bash
cd /path/to/project1
claude -p "/ralph-loop:ralph-loop 'Task 1...' --max-iterations 50"
cd /path/to/project2
claude -p "/ralph-loop:ralph-loop 'Task 2...' --max-iterations 50"
Run it before bed. Wake up to commits.
The Philosophy Shift
This technique represents a fundamental change in how we work with AI coding assistants:
From interactive to autonomous. Instead of babysitting every step, you define the goal and let the AI iterate toward it.
From single-shot to iterative. Accept that complex tasks take multiple attempts, and build that into the workflow.
From human-paced to machine-paced. An overnight loop can accomplish what would take a human days of focused work.
The traditional back-and-forth of AI coding (you prompt, it responds, you review, you prompt again) is like playing table tennis. Ralph changes the game: you describe the outcome, set the boundaries, and walk away.
When You Don't Need It
Here's the interesting thing: with Opus 4.5, the Ralph Wiggum technique is becoming less necessary for many tasks.
The model's improved ability to maintain context and execute multi-step plans means tasks that used to require 20 iterations might now complete in 5, or even in a single pass.
But Ralph still shines for genuinely large refactors, overnight batch operations, and tasks where you want explicit iteration controls. It's a power tool for specific scenarios, not a replacement for the core workflow.
Try It Tonight
Pick something you've been putting off. A test migration. A linter cleanup. A documentation pass. Something mechanical with a clear definition of done.
Write the prompt. Set conservative iteration limits. Start the loop before bed.
The worst case: you wake up to a detailed log of what went wrong and where Claude got stuck. The best case: the work is done.
Either way, you'll understand why people can't stop talking about a technique named after a Simpsons character.
What's the most ambitious thing you'd trust to an overnight loop? I'm curious where people are drawing the line between "let it run" and "I need to watch this."