What happens before the loop? → From problem to finished plan in 4 steps
Max Fraunhofer / Methods / Ralph-Loop
Ralph-Loop mascot — donut car with infinity symbol

How to grind through issues — with a stubborn coding loop plus review gate.

Geoffrey Huntley's loop, Matt Pocock's four lines of bash, my wrapper around it for the automatic review gate. Build it yourself — setup prompt is below.

As of: May 2026 · phase 3 of 4 In use for: Spurwert, automuc.de, mfraunhofer.de Token cost: moderate
Build it yourself — grab the bootstrap prompt ↓ or first read what Ralph does →
01Origin
Ralph-Loop in 3/4 view — same donut, different angle

Three phases so far. Fourth already in testing.

I didn't invent this. Neither did Matt Pocock. The loop comes from Geoffrey Huntley, May 2025. Matt picked it up in his 2026 workshop, structured it cleanly, and tied it to a TDD skill. I took Matt's version and bolted a wrapper in front of it, because my use case is different: software I want to sell, not throwaway prototypes. Phase 4 is already running in a live test — parallel swarm.

Phase 1 · May 2025
Geoffrey Huntley
Invented the technique and gave it its name, after Ralph Wiggum from The Simpsons. His own description: "crude but effective looping technique". One that doesn't let a coding agent stop until the task is actually done.
→
Phase 2 · 2026
Matt Pocock
Picked it up in his AI Engineer workshop, turned it into four lines of bash, wired the loop to his own /tdd skill and a file-move tracker for the done state. Workshop state: ai-engineer-workshop-2026-project.
→
Phase 3 · May 2026 · current
Max Fraunhofer
Took Matt's version and bolted a wrapper in front of it: branch per issue, automatic /code-review as the gate, CI green required before merge. Because I'm building software real people are supposed to use.
→
02The loop

Short, stubborn, effective. Like Ralph.

The same prompt runs against Claude Code over and over. The agent reads the open issue files, picks the next ticket, implements it with TDD, commits, next round. On the next pass it sees its own latest commits and keeps going until nothing's left.

The name is the punchline: Ralph Wiggum from The Simpsons. Dumb but stubborn-effective. The loop doesn't make grand decisions, it just picks the next ticket. Because it does that a thousand times in a row, the feature is finished at the end. 

# once.sh — one iteration
issues=$(cat issues/*.md)
commits=$(git log -n 5 --format="%H%n%ad%n%B---" --date=short)
prompt=$(cat ralph/prompt.md)
claude --permission-mode acceptEdits "Previous commits: $commits Issues: $issues $prompt"

That's all of it. prompt.md says: pick issue, TDD, all tests green before commit, move finished ticket to issues/done/. Done state via file move, no status flag. Very clean.

"If your code base doesn't have feedback loops, you're never ever ever going to get decent output out of AI. The quality of your feedback loops is the ceiling." Matt Pocock, Workshop 2026

That's also exactly its limit. Matt says it honestly in the workshop: "I don't honestly know what the answer to this yet. We just need to be ready to be doing more code review." The loop produces code faster than you can read it. For throwaway prototypes that's fine — for software real people are supposed to use, code review is the bottleneck. That's where my wrapper comes in.

03My wrapper

How my tuned Ralph runs in practice.

The loop isn't the whole project — it's the development pass per issue. A phase (for me e.g. "Spurwert MVP") is 15–25 issues. Every issue goes through the same pass. How the issues come into being before the phase — strategy, PRD, issue cutting — is a different story and not the topic here.

Phase Example: Spurwert MVP
20 issues · Goal: wizard booking pilot-ready for workshop tenants
#01
#02
#03
#04
#05
#06↓ current
#07
#08
#09
#10
#11
#12
…
#20
Per issue, this development loop runs:
01
Branch from main
02
Read issue + ADRs
03
/tdd pure function
04
Shim tests
05
Build edge function
06
Integration tests
07
Lint + type + build green
08
Deploy + curl smoke
09
Open PR
10
/code-review ≥ 75
11
CI green → merge
Ralph core (Huntley + Pocock)
My wrapper (built myself)
Steps 02–07 = Ralph core (TDD loop). 01 + 08–11 = wrapper.
→ Concrete example: Today, issue #06 from Spurwert phase 1

The update tasklist from the session: seven Ralph-core steps, framed by four wrapper steps.

Issue #06 — getAvailableSlots edge function
Read issue #06 spec + relevant ADRs/PRD sectionsRalph
Branch from mainWrapper
Pure-function getAvailableSlots: tests + implementationRalph
Deno shim availability + extend shim-consistency testRalph
Edge function /availability (tenant + query + cache header)Ralph
Integration tests for endpoint (local supabase)Ralph
Lint + typecheck + build + tests locally greenRalph
Live-deploy edge function + curl smokeWrapper
Commit + open PRWrapper
/code-review <PR#> + fix findings ≥ 75Wrapper
CI green, mergeWrapper
→ Try it yourself

Setup in a single paste — even if you're starting from zero

Paste this prompt into your coding agent (Claude Code, Cursor, Codex). It runs a preflight checklist — git repo, Claude CLI, test runner, tickets, review gate — reports per item what's already there, and for anything missing it offers to create it. Say "already have it" and it skips ahead. After that it installs once.sh, loop.sh and wrapper.sh in the variant that fits your setup — with or without a git remote, with or without the /code-review gate. At the end a one-time dry run plus status report.

You're starting from zero: repo, tests, tickets — everything missing. The prompt asks you for 1 goal sentence and cuts the first 3–5 tickets from it. You already have something: say "already have it", it skips. Pure loop without wrapper? Take the 4 lines of bash above directly — copy button on the code block.
←
What happens before the phase — how issues come into being (strategy, PRD, issue cutting) — is its own story. Here we only show the development loop per issue inside a phase.
04Compare

What I do differently, and why.

Per dimension: standard Ralph, my setup, Sand Castle. So you can actually compare instead of reading three lists side by side.

Dimension
Standard RalphHuntley + Pocock
My setupRalph + wrapper
Sand CastlePocock, parallel
How code lands on main
Straight from the loop Loop commits directly to main. Fast, no PR overhead.
Through PR + review gate Branch per issue, its own PR. Only on main after review pass and CI.
PR + merger agent Multiple branches in parallel, a dedicated merger agent resolves conflicts and merges in order.
Pre-commit gate
Tests + typecheck Local green is required, otherwise no commit.
+ live-deploy + curl smoke Edge functions can be green locally and broken remotely. Smoke closes the gap before the PR.
+ live-deploy + smoke per branch Same gate, just n times in parallel on separate branches.
Code review
Open, deferred Matt himself: "we just need to be ready to be doing more code review."
/code-review as mandatory gate Score ≥ 75 required, otherwise I fix before merge.
Reviewer agent baked into the loop You only review the agent's review, not the raw code.
Container / isolation
Docker for AFK night shifts Isolates the loop when it runs autonomously for hours.
Docker for local stack Local Supabase, edge-function runtime, Postgres in containers for integration tests.
Docker sandbox per agent (required) Every parallel agent runs in its own sandbox so they don't step on each other.
Parallelism
Sequential, one agent Kept deliberately simple.
Sequential, one agent Same. Parallelism comes with phase 4 (my swarm skill, in test).
Several agents in parallel Planner distributes issues, n implementers work simultaneously on their own branches.
Token cost
Minimal One agent does everything. No review pass on top.
A bit higher Plus one review pass per PR. Costs more, but gives me the quality gate.
Substantially higher n agents at once, plus reviewer, plus merger. Volume scales accordingly.
Setup complexity
Very low Four lines of bash, one prompt file, one issues folder. Done.
Low Bootstrap prompt above creates everything. Extra: PR setup + /code-review skill.
High GitHub issues schema, Docker templates, sandbox setup, configure npm package.
When it makes sense
Prototypes, learning Throwaway code, your own playground. Nothing ships to customers.
Solo builder, software for real users You build alone and still want the quality gate without funding n agents.
Team load, many issues, budget irrelevant More output per hour wanted, token cost secondary.

Swarm skill in live test. Sand Castle as the premium upgrade.

My own swarm skill distributes issues across multiple loops that run in parallel — planner picks, several implementers work at the same time, reviewer agent gates. Right now it's running against Spurwert issues in a live test. Once it sits stable, it replaces the sequential pass from section 03.

If you want the clean version today: Sand Castle by Matt Pocock is the industrial variant of this. Heavier setup, more token cost, but ready and battle-tested. For me right now not the right ratio — as long as I build alone, my own swarm gets close to the same effect without the overhead. Worth keeping an eye on for the day when issue volume or review load justify it.

As of May 2026 — updated here when something changes.

↘Punchline

At the core: dumb, stubborn, effective. Like Ralph Wiggum himself.

Around it: a gate that doesn't depend on my attention.
Result: I review the review, not the raw code.
Current state: wrapper runs on Spurwert, swarm skill in live test, Sand Castle on the radar as the premium path.
Build it yourself — grab the bootstrap prompt ↓

Sources + further reading