Agentic Engineering

RALPH Loops

The brute-force agent technique: the same prompt, an infinite shell loop, and a completely fresh context every iteration. Geoffrey Huntley’s method, documented accurately, including where it breaks and how to run it without handing your machine away.

Explore DCENT_ADE Read Huntley's Original Post

Task per loop iteration

Conversation carried between runs

170k

Usable context Huntley targets

2025

Published by Geoffrey Huntley

What A RALPH Loop Actually Is

A RALPH loop is a shell loop that runs the same prompt against a coding agent over and over, forever, with a brand new context window every time. That is the entire technique. No orchestrator, no scheduler, no message bus, no agent-to-agent protocol. The loop starts the agent. The agent reads the repository to work out where things stand. It does one thing. It exits. The loop starts it again.

The technique is not ours. It comes from Geoffrey Huntley, who published Ralph Wiggum as a “software engineer” on 14 July 2025. Read the original. Our page is a reference, not a replacement, and Huntley’s write-up carries detail and hard-won operator judgement that no summary preserves.

RALPH is not an acronym. It has no expansion. If someone hands you a backronym, they made it up. The name is a reference to Ralph Wiggum from The Simpsons, and the joke is load-bearing: the technique looks far too stupid to work. Huntley’s own framing is that “Ralph is a technique. In its purest form, Ralph is a Bash loop,” and that its strength is being “deterministically bad in an undeterministic world.” Predictable failure is tunable. Creative failure is not.

# Huntley's minimal form, verbatim from the original post
$ while :; do cat PROMPT.md | claude ; done

# What people actually run unattended, with a bound on it
$ ITER=0
$ while [ $ITER -lt 20 ]; do
>   cat PROMPT.md | claude -p --dangerously-skip-permissions
>   git push origin "$(git branch --show-current)" || true
>   ITER=$((ITER + 1))
> done

The loop is deliberately harness-agnostic. Huntley’s constraint is only that “Ralph can be done with any tool that does not cap tool calls and usage.” People run it with Claude Code, Amp, Codex and OpenCode. Which harness, which model and which permission posture you pick is a separate decision with its own trade-offs, covered on harness engineering.

One point of honesty about the record. The first public write-up is dated 14 July 2025 and we can verify that directly. Community histories place an earlier public demonstration in June 2025, and at least one secondary account dates the original discovery to early 2024. Those earlier dates are plausible but we could not corroborate them from a primary source, so we are not going to assert them as fact.

Why Throwing Away The Context Is The Feature

The instinct is that restarting the agent destroys everything it learned. It does. That is the point.

A long-running agent session degrades. Huntley’s working rule is that you have roughly 170k of context to play with and that “the more you use the context window, the worse the outcomes you’ll get.” Community playbooks put the reliable band lower still, treating the first half of the window as the zone where the model is genuinely sharp. Past that, the agent is reasoning over a transcript stuffed with its own dead ends, abandoned hypotheses and file contents that were true forty minutes ago. It repeats itself. It re-solves solved problems. It describes code that no longer exists, confidently.

RALPH sidesteps all of that by never letting a session get long enough to rot. Every iteration is short, clean, and starts from the same known state. The memory does not live in the transcript. It lives in the repository: the source tree, the test suite, the git history, and a plan file the agent maintains for itself. The window economics behind this trade are covered on context engineering.

The Three Properties That Make It Work

Short Runs Beat Long Ones

An agent thirty minutes into a session is arguing with its own history. An agent thirty seconds into a session is reading the actual files. The bet is that a clean short run outperforms a cluttered long one, and in practice it usually does.

The Repository Is The Memory

State survives on disk, not in the model. Commits, tests, a plan file and an agent instructions file are the handoff between iterations. Anything not written down did not happen.

Determinism Of Setup

Every iteration loads the same prompt, the same instructions file and the same specs. Huntley calls this allocating the stack the same way every loop. Only the repository state differs, which is exactly the variable you want.

The Prompt Must Be Idempotent And State-Derived

Because every iteration is byte-identical, the prompt cannot say “now do step four.” It has no idea which step it is on. It has to say something closer to: read the current state, decide what matters most, do exactly one thing, prove it, write down what you did.

Idempotent

Running the prompt twice on the same repository must not duplicate work. This is why “do not assume it is not implemented” is the single most repeated guardrail in the whole technique. Huntley: “A common failure scenario for Ralph is when the LLM runs ripgrep and comes to the incorrect conclusion that the code has not been implemented.” He calls that nondeterminism the Achilles heel of the method.

State-Derived

The next action has to be readable off disk. A plan file is the shared state between otherwise isolated runs, and the agent both consumes it and updates it. Huntley watches his plan file “like a hawk” and throws it out often. Regenerating a plan costs one loop. Letting a wrong plan drive fifty loops costs a night.

Self-Documenting

The next iteration will not remember why. So the current one must record it. Huntley instructs the loop to capture the reasoning behind a test inside the test itself, so a future iteration can judge whether a red test means the code is wrong or the test is obsolete. Without that, loop fifteen deletes the test loop four wrote for a good reason.

And one item per loop. Huntley repeats himself on purpose: “One item per loop. I need to repeat myself here, one item per loop.” You may loosen it as a project stabilises. The moment things go sideways, tighten it back down. The instruction itself, its constraints and its acceptance criteria are the subject of prompt engineering.

Read specs/ to understand the requirements.
Read IMPLEMENTATION_PLAN.md to understand the plan so far.
Read AGENTS.md to learn how to build and test this project.

Choose the single most important unfinished item from the plan.
Before changing anything, search the codebase to confirm it is not
already implemented. Do not assume it is missing.

Implement it fully. No placeholders, no stubs, no TODO markers.
Run the tests for the unit you changed.
If the build or the tests fail, fix them before you finish.

When the tests pass: update IMPLEMENTATION_PLAN.md, run git add -A,
and commit with a message describing what changed.
If you could not commit, say so plainly and state what blocked you.

If you learn something about how to build or test this project,
append it to AGENTS.md. Keep it short.

Backpressure, And Telling Progress From Thrash

Generation is cheap now. Verification is the entire job. Huntley splits the technique into two phases: generate, then backpressure. Backpressure is anything that mechanically rejects invalid work. A type system. A compiler. A test suite. A linter, a static analyser, a security scanner. His constraint is that “the wheel has got to turn fast,” so you balance strictness against cycle time rather than maximising either.

Without backpressure a RALPH loop does not fail loudly. It thrashes quietly, and it bills you for the privilege. Learn to read the difference from outside the loop.

Progress looks like: the commit graph advances every few iterations. The plan file gets shorter. Test count rises. Version tags increment. The agent instructions file accumulates real operational detail about how to build the thing.

Thrash looks like: the same file rewritten in alternating directions across iterations. Plan items marked done, then quietly re-added. A second implementation of something that already exists, because a search came back empty. Stub functions and placeholder returns. Huntley’s counter-prompt against that last one is deliberately shouty, and his diagnosis is worth internalising: the models chase a reward function, and the reward function is code that compiles, not code that works.

The gate we would treat as non-negotiable before leaving a loop unattended: an iteration that cannot commit has not made progress, no matter how good its closing summary sounds. Require a clean build before commit. Require a scoped test run for the unit just changed. Then read the git log, not the agent’s prose. The general theory of termination, oscillation and evidence across all loop shapes is covered on loop engineering.

How To Make It Stop, And What It Costs

while : has no exit condition. That is a design choice rather than an oversight, and it makes termination your problem. Three bounds are worth wiring in before you walk away.

An iteration cap. Community loop scripts wrap the core loop in a counter. Anthropic’s official Ralph Wiggum plugin exposes a --max-iterations flag and its own documentation calls it “your primary safety mechanism.” Note carefully what the cap bounds: it limits the outer loop, meaning tasks attempted, not tool calls inside a single iteration. One iteration can still run away on its own.

A completion signal. A phrase the agent emits once acceptance criteria are met, which the loop checks for. Useful, but brittle alone. Exact string matching cannot tell “finished” apart from “gave up,” which is exactly the distinction you care about at 4am.

A spend ceiling. Tokens are the real limit. Huntley has reported roughly ten and a half US dollars an hour for a mid-tier model running in a loop, and separately a fifty-thousand-dollar contract delivered as a tested MVP for two hundred and ninety-seven dollars of model spend. Both figures come from one operator on greenfield work. We have not reproduced either and we are not presenting them as a quote you can plan against. Treat them as evidence that the technique is cheap relative to a contract, not as a rate card.

Watch the first hour yourself. The prompts you start with will not be the prompts you finish with. They evolve by observing exactly how the loop fails and adding a guardrail for each failure. Huntley describes it as tuning a guitar, and there is no shortcut past sitting there and watching the stream for a while.

The Safety Warning This Technique Deserves

To loop unattended, the agent cannot stop and ask. In practice that means --dangerously-skip-permissions or its equivalent on whatever harness you run. The flag does precisely what its name says. It removes the approval step from every tool call, including file writes, arbitrary shell commands and network access.

The published playbook is blunt about the consequence and we agree with it word for word: once you bypass permissions, the sandbox is your only security boundary. Running without one exposes credentials, browser cookies, SSH keys and access tokens sitting on your machine. The framing to hold onto is that it is not a question of whether something gets popped, but when, and what the blast radius is when it does.

The practical minimum before you start a loop:

Not your main checkout. A container, or at minimum a dedicated git worktree on its own branch. The blast radius should be one directory you are willing to delete.
Commit or stash first. git reset --hard is your undo button and it only works from a clean baseline.
Minimum viable credentials. Only the keys the task needs. No production secrets. No deploy keys it will never use.
Restrict network egress where the platform lets you.
Know the stop. Ctrl+C ends the loop, but only between iterations. An iteration already running will finish what it started.

One more limit, from the author himself, and we have not seen a convincing counter-argument: “There’s no way in heck would I use Ralph in an existing code base.” He positions it as a greenfield bootstrapping technique that gets you roughly ninety percent of the way, and he is equally direct that this is not autonomy. His words: anyone claiming engineers are no longer required, and that a tool does one hundred percent of the work, is selling you something.

When A Gauntlet Loop Is The Better Tool

RALPH’s judge is mechanical. A test passes or it does not. That is a strong signal and a narrow one. A green suite cannot tell you the API is confusing, the copy is wrong, the layout collapses at 360px, or the abstraction you just committed is a trap that costs you six months.

When the acceptance criteria resist automated checking, the loop needs a different kind of judge: an adversarial one. That is what we call a Gauntlet Loop, a pattern named publicly by Matt Shumer that we run as standing build doctrine. A builder produces a real artifact. A separate critic receives fresh context, judges the actual result rather than the builder’s description of it, and has the authority to reject. The largest gap goes back to a builder and the loop repeats.

The difference is not the shape of the loop. It is who decides. RALPH trusts the compiler. The Gauntlet trusts an independent reviewer with fresh eyes and a real veto. If you are running many agents against a dependency graph rather than a single repeating task, that is a third shape again, covered on graph engineering.

RALPH Loop Versus Gauntlet Loop

	RALPH Loop	Gauntlet Loop
Origin	Geoffrey Huntley, published July 2025	D-Central internal build doctrine
Shape	One agent, same prompt, infinite restart	Builder, then independent critic, then rebuild
Who decides it is done	The build and the test suite	A separate agent with fresh context and a real veto
Memory between passes	The repository, git history and a plan file	The artifact plus a written review packet
Best for	Greenfield bootstrapping with mechanical acceptance criteria	Work whose quality bar a compiler cannot check
Breaks down when	Correctness is subjective, or the codebase is large and established	The critic is not genuinely independent or cannot reject
Stops when	Iteration cap, completion phrase, or you hit Ctrl+C	The artifact clears the bar, or a human declines to co-sign

Running Loops In DCENT_ADE

DCENT_ADE is terminal-first, so the honest answer is that a RALPH loop runs the way it always has. A shell in a terminal tab, native PTY, nothing clever required. Shells are part of the native host’s harness catalog alongside Claude Code, Codex, Gemini and OpenCode, so the loop you paste is the loop that runs.

What the environment adds is the part a bare bash loop never had.

Isolation is the default, not a discipline you have to remember. Mission Control’s worktree isolation means a loop works in its own checkout rather than your main one.
Observation you can trust. Orion’s awareness layer distinguishes busy, idle, awaiting input and finished from real terminal behaviour rather than from optimistic guesses. A loop that has silently gone to sleep on a permission prompt looks different from a loop that is working, which is precisely the distinction that matters when you check on it in the morning.
Authority stays native. The Tauri and Rust host owns spawn, egress and tool server registration. The WebView gets no general spawn, SQL or fetch authority. Turning off an agent’s own permission prompts does not turn off the host’s controls.
Local inference where it fits. Ollama and LM Studio discovery with model-role assignment means a local model can take a loop’s high-volume, low-stakes iterations. Cloud is an explicit, consented boundary and never an invisible fallback.
No fake success. The current catalog execution layer refuses to claim a git merge it did not perform. In a loop, a false success report is worse than a failure, because the next iteration builds on top of it.

We build DCENT_ADE with Gauntlet Loops rather than RALPH loops, for the reason set out above: most of our acceptance criteria are not compiler-checkable. That is a fit judgement about our work, not a criticism of the technique. For greenfield code with a fast, strict test suite, RALPH is remarkably hard to beat on cost.

DCENT_ADE is free, open and as-is. No paid tier, no gatekeeping, no features held back for a licence. If you use it commercially or it earns you money, a voluntary subscription or donation is expected and never enforced: d-central.tech/fund. Start at the agentic engineering hub if you want the rest of the ladder.

Is RALPH an acronym? What does it stand for?

It is not an acronym and it does not stand for anything. Geoffrey Huntley named the technique after Ralph Wiggum from The Simpsons, because the method looks far too dumb to work and keeps cheerfully going anyway. His original post never expands the letters. Any backronym you have been shown was invented after the fact by somebody else.

Who invented the RALPH loop, and when?

Geoffrey Huntley. The primary source is his post Ralph Wiggum as a software engineer at ghuntley.com/ralph, dated 14 July 2025. Community histories place an earlier public demonstration in June 2025 and at least one secondary account dates the discovery to early 2024. We can verify the July 2025 publication directly and cannot verify the earlier dates, so we cite the one we checked.

Do I need the official Claude Code plugin to run a RALPH loop?

No. A shell loop is the original and it works with any agent that does not cap tool calls. Anthropic does ship an official ralph-wiggum plugin, and it credits Huntley directly, but it implements the idea differently: a Stop hook blocks the session from exiting and re-feeds the prompt inside the same session. That is convenient and it gives you an iteration cap for free, but an in-session loop does not give you a genuinely fresh context each pass, which is the defining property of the bash version. Huntley has been publicly critical of treating the two as equivalent. Run either one, but know which one you are running.

Is it safe to run an agent with permission prompts disabled?

Only inside a boundary you chose on purpose. Bypassing permissions is what makes unattended looping possible, and it also removes every approval gate on file writes, shell commands and network calls. Once you do it, the sandbox is your only security boundary. Run the loop in a container or a dedicated git worktree, give it only the credentials the task actually needs, restrict network egress where you can, and start from a clean commit so git reset –hard is a real undo. On your main checkout with your real SSH keys present, the flag is genuinely reckless.

Will a RALPH loop work on my existing production codebase?

Huntley says no, and he built a whole programming language with the technique. His closing line is that there is no way in heck he would use it in an existing code base. The reason is structural rather than stylistic: the loop depends on a search step to answer whether something is already implemented, and that search gets less reliable as a codebase grows. On a large established repo the loop starts building second copies of things that already exist. Use it to bootstrap greenfield work, expect roughly ninety percent, and take the last ten percent by hand.

How do I tell whether the loop is making progress or just spinning?

Read the git log, not the agent summaries. Progress looks like commits landing, the plan file shrinking, test count rising and version tags incrementing. Thrash looks like the same file rewritten in opposite directions across iterations, plan items marked done then re-added, duplicate implementations of existing functionality, and placeholder returns. Treat an iteration that could not commit as an iteration that made no progress, whatever its closing message claims.

Related products, repair, and setup paths

Last reviewed August 13, 2026.