The Ralph Loop: Brute-Force Autonomous Coding by Just Repeating the Prompt

The first time someone described this technique to me I assumed they were joking. "You just... run the same prompt in a loop, over and over, and walk away?" No context management, no elaborate planning agent, no orchestration graph — just a `while true` wrapped around a coding agent CLI, fed the identical instructions every single iteration. It sounded like the kind of thing that works in a demo and falls apart the moment a real codebase gets involved. Then I actually tried it on a well-scoped greenfield service, with a real test suite gating each iteration, and it did something I didn't expect: it kept making forward progress for far longer, and far more reliably, than a single long agent session doing the same work ever had.

This is the Ralph Wiggum technique — usually shortened to "the Ralph loop" — coined and popularized by Geoffrey Huntley, who wrote it up on his blog as "Ralph Wiggum as a 'software engineer.'" The name is doing double duty: it's a nod to the Simpsons character, and it's an honest description of most engineers' gut reaction to how simple-sounding the mechanism is. I've covered the harness patterns that make a single agent session reliable in a separate deep-dive on agent harness design, and the externalized-memory argument in a piece on agent memory — Ralph is worth its own article because it takes a genuinely different position on the central problem those two pieces both wrestle with: what do you do when an agent's context starts filling up with noise.

What is the Ralph loop, mechanically?

Ralph, in its purest form, is a bash while-loop. You feed a coding agent CLI — Claude Code is the obvious fit — the exact same prompt on every iteration, let it run to completion or a stopping condition, and then start over with a fresh invocation. The core rule that makes this work rather than just re-doing the same work forever: progress accumulates in files and git history, not in the agent's own context window. Each iteration starts cold, reads the current state of the repository and the git log to figure out what's already been done, and does the next increment of work — then commits, and exits.

#!/usr/bin/env bash
# Ralph, in its purest form -- a bash while-loop around a coding agent CLI.
# The prompt never changes. The repo and git history are the only state
# that carries between iterations.

PROMPT_FILE="PROMPT.md"
MAX_ITERATIONS=200
i=0

while [ "$i" -lt "$MAX_ITERATIONS" ]; do
  echo "=== Ralph iteration $i ==="

  # Fresh context every time -- the agent re-reads the repo and git log
  # from disk, it does not inherit any conversation state from before.
  claude --dangerously-skip-permissions -p "$(cat "$PROMPT_FILE")"

  # The verification step is what makes this something other than noise:
  # a real, deterministic check of whether the last iteration actually
  # moved the codebase forward.
  if ! npm test --silent; then
    echo "tests failing after iteration $i -- next loop picks this up from git state"
  fi

  # Stop condition lives outside the model's own say-so.
  if git log -1 --pretty=%B | grep -q "RALPH_DONE"; then
    echo "completion marker found in last commit, stopping"
    break
  fi

  i=$((i + 1))
done

Note what isn't in that loop: no summarization step, no compaction logic, no attempt to keep one conversation alive across iterations. That's deliberate, and it's the whole point.

graph TD
    START["Fresh context
each iteration"] --> READ["Read repo state
+ git log from disk"]
    READ --> PLAN["Pick the next
increment of work"]
    PLAN --> ACT["Agent does the work
edits, runs commands"]
    ACT --> VERIFY["Verify: run the
real test suite / build"]
    VERIFY -->|"passes"| COMMIT["Commit progress
to git history"]
    VERIFY -->|"fails"| COMMIT2["Commit or revert
state reflects reality"]
    COMMIT --> LOOP["Exit this iteration"]
    COMMIT2 --> LOOP
    LOOP -->|"loop again"| START
          

Why does throwing away context on purpose actually help?

Because a single long-running agent session degrades in quality well before it hits a hard token limit. This is the "context rot" problem: as a conversation grows, it accumulates stale reasoning, half-finished exploration paths, decisions that got superseded but never got cleanly removed, and tool output that was relevant three steps ago and is now just noise the model has to read past on every subsequent turn. My harness piece covers the mainstream answer to this — compaction, summarizing the older parts of a session so the important facts survive while the noise gets dropped. Compaction is real engineering, and done well it's invisible. But it's also trying to solve a genuinely hard problem: deciding, automatically, what's still load-bearing in a growing transcript and what's safe to discard.

Ralph sidesteps that problem instead of solving it. Huntley's framing, and it's the one that made this click for me, is to stop thinking of a context window as the agent's memory at all — think of it as something closer to a working-memory array you allocate fresh for each unit of work, use, and then release. Nothing about the previous iteration's reasoning needs to survive in the conversation, because nothing important was ever supposed to live there in the first place. The plan lives in a file. The history of what's been tried lives in git log and commit messages. The actual state of the code is the code. A fresh context each iteration isn't losing anything, because the durable record was never the conversation — it was always the repository.

That reframing has a concrete practical benefit: it makes the failure mode of "the agent forgot something important ten turns ago" structurally impossible in the way it's structurally possible with compaction. There's no ten-turns-ago to forget. Every iteration starts by reading the same durable ground truth the previous iteration left behind.

What does Ralph depend on to not just loop in circles?

Everything, honestly, rides on one thing: a real, deterministic verification step each iteration that can't be talked out of its answer. This is the exact same lesson I named in the harness piece — self-report is not evidence — just showing up at loop-scale instead of turn-scale. Inside one agent turn, the failure mode is a model claiming a fix worked without re-running the failing test. In the Ralph loop, the failure mode is an agent claiming an iteration made progress, moving on to the next task in the plan, and having every subsequent iteration build on a foundation that was never actually solid. Without tests, a build, or some other grounded check the loop can run and trust, "keep looping" degenerates into "keep confidently generating plausible-looking commits that don't actually work," and a hundred iterations of that is a hundred iterations closer to a codebase that looks progressed and isn't.

What kinds of tasks is this actually good at?

Well-scoped, decomposable, test-gated work — greenfield services, a clearly defined feature with acceptance criteria you can encode as tests, a large but mechanical migration where "keep chipping away and check against the suite" is a coherent strategy end to end. The common thread is that "correct" has a cheap, automatable definition the loop can check against every single iteration without a human in the room.

It's noticeably worse at tasks that need sustained, coherent architectural reasoning held across the whole scope at once — the kind of decision where iteration 40 needs to remember a subtle constraint from the design conversation in iteration 3, and "it's written down in a file somewhere" isn't quite the same as "the same reasoning process that originally understood the trade-off is still active." Ralph is fantastic at grinding through a big, mechanical, well-specified backlog. It's a worse fit for the kind of work where the hard part is holding an evolving mental model of a system's design, not executing a known plan against it.

Has it evolved past a raw bash loop?

Yes, at least in Claude Code's case — by mid-2026 Anthropic packaged the same idea into an official ralph-wiggum plugin rather than leaving it purely a shell-script pattern. The plugin implementation swaps the literal external while-loop for a stop hook inside the CLI session itself: the agent attempts to exit, the hook checks for a completion signal, and if that signal isn't present, the same prompt gets fed back in and the loop continues — functionally the same shape, minus the need to babysit an external script. The fact that Anthropic built first-party tooling around a pattern that started as "just wrap this in bash" is a reasonable signal that the underlying idea — fresh context per unit of work, durable state on disk, real verification gating progress — was solving something real rather than being a novelty.

What to carry away

The Ralph loop's actual insight isn't "let an agent run unsupervised" — plenty of things have tried that and failed. It's a specific claim about where an agent's state should live: not in an ever-growing conversation that needs increasingly clever management to stay coherent, but in the filesystem and git history, which are durable, inspectable, and don't degrade the way a transcript does. Treat the context window as disposable scratch space you reallocate per unit of work rather than a memory you have to carefully curate, and a lot of the context-management problem simply doesn't arise. None of that works without a real, deterministic verification step gating every iteration — take that away and you have an expensive way to generate confident-sounding commits that don't actually converge. If you're choosing between managing one long session well and looping short sessions against solid tests, the honest answer by mid-2026 is: it depends on whether the task decomposes cleanly enough to trust the loop, and whether you've actually got the tests to make "trust" a fact instead of a hope.