Who Invented the Ralph Technique? Geoffrey Huntley and the Bash Loop That Stuck
Geoffrey Huntley invented the Ralph technique, and he summed it up in five words: “Ralph is a Bash loop.” He popularized the idea in his original writeup in 2025, after he used a loop like this to build a working programming language overnight. The name is a joke that turned into a method. The method is now so common that Anthropic ships an official version of it.
This post covers who built it, how it started, why the Simpsons name fits so well, and how the same idea grew from a one liner into a Claude Code plugin without losing its plot.
Who invented the Ralph technique?
Section titled “Who invented the Ralph technique?”Geoffrey Huntley. He is the engineer who named it, wrote it down, and showed what it could do. His framing is deliberately blunt: there is no agent framework, no orchestration layer, no graph of cooperating models. There is a prompt and a while loop.
The core claim in his Ralph writeup is that you can take a single coding agent, feed it the same instruction over and over, and let the filesystem carry the state between runs. Each pass starts fresh. Each pass does a little more. You wake up and the work is done.
That is the whole invention. The hard part was believing it would work.
The origin story: a programming language built overnight
Section titled “The origin story: a programming language built overnight”The story that made people pay attention involved Huntley pointing a loop at a serious task and walking away. Not a toy. He ran an agent in a loop to build a working programming language, compiler and all, across a long unattended run in 2025.
The mechanics were almost insultingly simple. Wrap an agent invocation in a shell loop. Give it a prompt that describes the goal and the current state. Let it write code, run the compiler, read the errors, and try again. The agent does not need to remember the previous attempt, because the previous attempt is already on disk as committed code and failing tests.
Here is the shape of the thing, reduced to its essence:
while :; do cat PROMPT.md | your-coding-agentdoneThat is not a metaphor. That is close to the literal idea. The agent reads the prompt, does one chunk of work, exits, and the loop hands it the prompt again with the repository in a slightly better state than before. Run that for a few hours and the diff is real.
The reason a compiler is a good demo is that a compiler tells you the truth. It either parses the input or it does not. The tests either pass or they do not. A loop that can read its own compiler errors has a tight feedback signal, and a tight feedback signal is what keeps an agent from drifting.
Why the Simpsons name stuck
Section titled “Why the Simpsons name stuck”Ralph is named after Ralph Wiggum, the cheerfully clueless kid from The Simpsons. The joke writes itself. The technique looks too dumb to work. It has no planning module, no memory of its past, no clever coordination. It just keeps trying with earnest, undirected persistence.
That naive persistence is the point. Ralph Wiggum does not get discouraged. He does not overthink. He shows up again on the next frame as if nothing happened. A Bash loop around a coding agent has the same energy. It does not carry yesterday’s frustration into today’s attempt. Every iteration is a clean start with fresh eyes.
The name stuck because it is honest about the trick. The strength of the method is that it looks like it should not work, and then it does. People remember the gap between “this is obviously too simple” and “wait, it shipped the feature.” Naming it after a character famous for guileless repetition makes that gap easy to talk about.
There is a real engineering reason underneath the joke. Long agent sessions suffer from context rot: the agent fills its context window with old reasoning, half-finished plans, and stale assumptions, and slowly loses the plot. Ralph sidesteps that by throwing the context away on every pass. The agent never gets the chance to talk itself into a corner.
flowchart TD
Start([Start]) --> Prompt["Send the prompt to a fresh agent"]
Prompt --> Work["Agent does one task, runs tests, commits"]
Work --> Check{"Completion promise emitted?"}
Check -->|No| Prompt
Check -->|Yes| Done([Stop])
The loop has exactly one decision: did the agent signal that it is done, or not. If not, it runs again with a clean context. The repository on disk is the memory layer, so nothing important lives in the chat history.
The whole thing really is one Bash loop
Section titled “The whole thing really is one Bash loop”The Ralph technique survives translation into a real script without gaining any conceptual weight. In this repo the loop is ralph.sh, and you can read every line of it. There is no hidden orchestration. You install it and point it at a project:
npx @pageai/ralph-loopThen you run the loop with a cap on iterations so it cannot run forever:
./ralph.sh -n 50Each iteration follows the same handful of steps:
- Find the highest-priority incomplete task in
.agent/tasks.json. - Work the steps in
.agent/tasks/TASK-{ID}.json. - Run tests, linting, and type checking.
- Complete the task, take a screenshot, update the task status, and commit.
- Repeat until every task passes or the iteration cap is reached.
The prompt that drives all of this lives in .agent/PROMPT.md. The agent reads it on every pass, reorients from the files on disk, and picks up where the git history left off. You can run a single pass to sanity check the setup:
./ralph.sh --onceYou can also pick which agent does the work, since the loop does not care which CLI it wraps:
./ralph.sh --agent codex -n 5Supported agents include claude (the default), codex, copilot, cursor, gemini, and opencode. The loop knows when to stop because the agent emits a completion promise, a small semantic tag like <promise>COMPLETE</promise>, rather than ending on a vibe. The exit code tells you what happened: 0 for complete, 1 for hitting the iteration cap, 2 for blocked, 3 for a decision it needs from you.
If you want the full mental model of how the pieces fit together, read the Ralph technique explained. This post is the history; that one is the architecture.
How Ralph evolved: Anthropic’s Stop Hook
Section titled “How Ralph evolved: Anthropic’s Stop Hook”The clearest sign that a hack has become a pattern is when the platform vendor ships it for you. Anthropic released an official Claude Code plugin that runs the same loop using a Stop Hook. When the agent finishes a turn, the hook fires and re-injects the prompt, so the agent starts the next pass instead of stopping. You can read how hooks work in the Claude Code docs.
The Stop Hook version and the ralph.sh version are the same idea wearing different clothes. One re-injects the prompt from inside the agent runtime. The other re-injects it from a shell loop outside the agent. Both rely on fresh context per pass and on-disk state.
The reason to keep a script around even when an official plugin exists is control. ralph.sh is hackable. You can see exactly when it commits, how it caps iterations, how it isolates each run in a sandbox, and how it reads the completion promise. When a loop does something surprising, you want to be able to open the thing that drives it and read it top to bottom. That is harder to do with a closed plugin.
Ralph versus agent swarms and orchestrators
Section titled “Ralph versus agent swarms and orchestrators”A lot of money and engineering has gone into the opposite bet: multi-agent orchestrators, planner and worker hierarchies, shared scratchpads, role-playing crews of specialized models. The pitch is that a team of agents beats a lone one. Sometimes it does. Often it just adds coordination overhead, more places to fail, and more state to keep in sync.
flowchart LR
subgraph Ralph["Ralph: one loop"]
A["Fresh agent"] --> B["One task"]
B --> C["Commit"]
C --> A
end
subgraph Swarm["Orchestrator: many agents"]
P["Planner"] --> W1["Worker 1"]
P --> W2["Worker 2"]
P --> W3["Worker 3"]
W1 --> M["Shared state"]
W2 --> M
W3 --> M
end
The left side has one moving part and one source of state, your git history. The right side has a planner, several workers, and a shared store they all have to read and write correctly. Every arrow on the right is a chance for two agents to disagree about what is true.
Ralph wins on simplicity, and simplicity is what you want on an unattended run. A loop you can read in one sitting is a loop you can debug at 2 in the morning. It has fewer failure modes, and the failure modes it does have are legible: it ran out of iterations, it got blocked on a task, or it thrashed because the task was poorly scoped. None of those require you to untangle which agent corrupted the shared plan.
This is also why Ralph beats firing a single giant prompt and hoping. A one-shot prompt cannot see its own mistakes, so it cannot fix them. A loop lets the agent read the failing test it just caused and correct course on the next pass. For the full comparison, see Ralph loop versus one-shot prompting.
None of this means Ralph is foolproof. It fails in specific, predictable ways when you leave the guardrails off. If you want to know what goes wrong and how to prevent it, read Ralph loop failure modes before you start a long run.
When the loop is the right tool
Section titled “When the loop is the right tool”The Ralph technique earns its keep on work that is large, well specified, and verifiable. A backlog of tasks with clear acceptance criteria. A refactor with a test suite that proves correctness. A migration where each step can be checked. The loop grinds through those because each pass has a clean signal telling it whether it succeeded.
It is the foundation for running an agent for hours or days at a time. If your goal is to start a job before bed and review a stack of commits in the morning, the loop plus on-disk state plus a sandbox is the architecture that holds up. That longer story lives in how to run an AI coding agent overnight.
Geoffrey Huntley’s contribution was not a new model or a clever framework. It was the confidence to write down the dumbest thing that could possibly work, show that it actually works, and give it a name that admits how dumb it looks. The Bash loop stuck because the joke was true.
Frequently asked questions
Who invented the Ralph technique?
Geoffrey Huntley popularized the Ralph technique in 2025. He described it as a Bash loop around a coding agent and demonstrated it by building a working programming language overnight. His original writeup lives at ghuntley.com/ralph.
Why is it called Ralph?
It is named after Ralph Wiggum from The Simpsons, a character known for cheerful, naive persistence. The technique looks too simple to work, just a loop that keeps trying with fresh context each time, which is exactly the joke and exactly the point.
Is the Ralph technique really just a Bash loop?
Yes. At its core it is a shell loop that feeds the same prompt to a fresh agent on every iteration while the filesystem and git history hold the state. The ralph.sh script in this repo adds task tracking, verification, sandboxing, and completion promises, but the underlying idea is still a loop.
Did Anthropic adopt the Ralph technique?
Anthropic shipped an official Claude Code plugin that uses a Stop Hook to re-inject the prompt after each turn, which is the same loop pattern implemented inside the agent runtime. The ralph.sh script implements the same idea as a hackable shell script you can read and modify.
How is Ralph different from multi-agent orchestrators?
Orchestrators coordinate several agents through a planner and shared state, which adds overhead and more ways to fail. Ralph runs one agent in a loop with one source of truth, the git history. It is simpler to debug and has fewer failure modes on long unattended runs.