Was passiert vor dem Loop? → In 4 Schritten vom Problem zum fertigen Bauplan
Max Fraunhofer / Methoden / Ralph-Loop
Ralph-Loop Maskottchen — Donut-Auto mit Infinity-Symbol

So jagst du Issues durch — mit einem stur laufenden Coding-Loop plus Review-Gate.

Geoffrey Huntleys Loop, Matt Pococks vier Zeilen Bash, mein Wrapper drumherum fürs automatische Review-Gate. Bau dir das nach — Setup-Prompt ist unten.

Stand: Mai 2026 · Phase 3 von 4 Im Einsatz für: Spurwert, automuc.de, mfraunhofer.de Token-Aufwand: moderat
Jetzt nachbauen — Bootstrap-Prompt holen ↓ oder erst lesen, was Ralph macht →
01Herkunft
Ralph-Loop in 3/4-Ansicht — selber Donut, anderer Winkel

Drei Phasen bisher. Vierte schon im Test.

Ich hab das nicht erfunden. Matt Pocock auch nicht. Der Loop kommt von Geoffrey Huntley, Mai 2025. Matt hat das im Workshop 2026 aufgegriffen, sauber strukturiert und mit einem TDD-Skill verknüpft. Ich hab Matts Variante übernommen und einen Wrapper davor gehängt, weil mein Use-Case anders ist: Software die ich verkaufen will, statt Wegwerf-Prototypen. Phase 4 läuft schon im Live-Test — paralleler Swarm.

Phase 1 · Mai 2025
Geoffrey Huntley
Erfand die Technik und gab ihr den Namen, nach Ralph Wiggum aus den Simpsons. Seine eigene Beschreibung: "crude but effective looping technique". Eine, die einen Coding-Agenten nicht aufhören lässt, bis die Aufgabe wirklich durch ist.
→
Phase 2 · 2026
Matt Pocock
Griff es in seinem AI-Engineer-Workshop auf, machte vier Zeilen Bash daraus, verknüpfte den Loop mit einem eigenen /tdd-Skill und einem File-Move-Tracker für den Done-State. Workshop-Stand: ai-engineer-workshop-2026-project.
→
Phase 3 · Mai 2026 · aktuell
Max Fraunhofer
Hab Matts Variante übernommen und einen Wrapper davor gehängt: Branch pro Issue, automatischer /code-review als Gate, CI grün Pflicht vor Merge. Weil ich Software baue, die echte Leute nutzen sollen.
→
02Der Loop

Kurz, stur, effektiv. Wie Ralph.

Derselbe Prompt läuft wiederholt gegen Claude Code. Der Agent liest die offenen Issue-Files, pickt das nächste Ticket, implementiert es per TDD, committet, nächste Runde. Sieht beim nächsten Durchgang die eigenen letzten Commits und macht weiter, bis nichts mehr offen ist.

Der Name ist die Pointe: Ralph Wiggum aus den Simpsons. Dumm aber stur effektiv. Der Loop trifft keine grandiosen Entscheidungen, er pickt halt das nächste Ticket. Weil er das tausendmal hintereinander macht, ist das Feature am Ende fertig. 

# once.sh — eine 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"

Das ist alles. In prompt.md steht: pick Issue, TDD, vor Commit alle Tests grün, fertiges Ticket nach issues/done/ verschieben. Done-State per File-Move, kein Status-Flag. Sehr 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

Genau das ist auch sein Limit. Matt selbst sagt's im Workshop ehrlich: "I don't honestly know what the answer to this yet. We just need to be ready to be doing more code review." Der Loop produziert Code schneller als man ihn lesen kann. Bei Wegwerf-Prototypen egal — bei Software, die echte Leute nutzen sollen, ist Code-Review der Bottleneck. Genau da setzt mein Wrapper an.

03Mein Wrapper

So läuft mein getunter Ralph in der Praxis.

Der Loop ist nicht das ganze Projekt — er ist der Entwicklungs-Pass pro Issue. Eine Phase (bei mir z.B. "Spurwert MVP") besteht aus 15–25 Issues. Jeder Issue durchläuft den gleichen Pass. Wie die Issues vor der Phase entstehen — Strategie, PRD, Issue-Schnitt — ist eine andere Geschichte und nicht Thema hier.

Phase Beispiel: Spurwert MVP
20 Issues · Goal: Wizard-Buchung pilotreif für Werkstatt-Tenants
#01
#02
#03
#04
#05
#06↓ aktuell
#07
#08
#09
#10
#11
#12
…
#20
Pro Issue läuft dieser Entwicklungs-Loop:
01
Branch von main
02
Issue + ADRs lesen
03
/tdd Pure-Function
04
Shim-Tests
05
Edge-Function bauen
06
Integration-Tests
07
Lint + Type + Build grün
08
Deploy + curl-Smoke
09
PR aufmachen
10
/code-review ≥ 75
11
CI grün → Merge
Ralph-Core (Huntley + Pocock)
Mein Wrapper (selber gebaut)
Steps 02–07 = Ralph-Core (TDD-Loop). 01 + 08–11 = Wrapper.
→ Konkretes Beispiel: Heute, Issue #06 aus Spurwert Phase 1

Die Update-Tasklist aus der Session: sieben Schritte Ralph-Core, eingerahmt von vier Wrapper-Schritten.

Issue #06 — getAvailableSlots Edge-Function
Read Issue #06 spec + relevante ADRs/PRD sectionsRalph
Branch von mainWrapper
Pure-function getAvailableSlots: Tests + ImplementationRalph
Deno-Shim availability + Shim-Consistency-Test erweiternRalph
Edge-Function /availability (Tenant + Query + Cache-Header)Ralph
Integration-Tests Endpoint (lokal supabase)Ralph
Lint + Typecheck + Build + Tests lokal grünRalph
Live-Deploy Edge-Function + curl-SmokeWrapper
Commit + PR aufmachenWrapper
/code-review <PR#> + Findings ≥ 75 fixenWrapper
CI grün, MergeWrapper
→ Selber ausprobieren

Setup in einem Paste — auch wenn du bei null startest

Diesen Prompt in deinen Coding-Agent paste (Claude Code, Cursor, Codex). Er geht eine Preflight-Checkliste durch — Git-Repo, Claude CLI, Test-Runner, Tickets, Review-Gate — meldet pro Punkt was schon da ist, und bietet bei allem was fehlt an, es anzulegen. Sagst du "hab ich", springt er weiter. Danach installiert er once.sh, loop.sh und wrapper.sh in der Variante, die zu deinem Setup passt — mit oder ohne Git-Remote, mit oder ohne /code-review-Gate. Am Ende ein 1x-Trockenlauf plus Status-Report.

Du startest bei null: Repo, Tests, Tickets — alles fehlt. Der Prompt fragt dich nach 1 Goal-Satz und schneidet daraus die ersten 3-5 Tickets. Du hast schon was: sag "hab ich", er springt drüber. Reiner Loop ohne Wrapper? Nimm direkt die 4 Zeilen Bash oben — Copy-Button am Code-Block.
←
Was vor der Phase passiert — wie Issues entstehen (Strategie, PRD, Issue-Schnitt) — ist eine eigene Geschichte. Hier zeigen wir nur den Entwicklungs-Loop pro Issue innerhalb einer Phase.
04Vergleich

Was ich anders mache und warum.

Pro Dimension einmal Standard-Ralph, einmal mein Setup, einmal Sand Castle. Damit man's wirklich vergleichen kann statt drei Listen nebeneinander lesen zu müssen.

Dimension
Standard-RalphHuntley + Pocock
Mein SetupRalph + Wrapper
Sand CastlePocock, parallel
Wie Code auf main landet
Direkt vom Loop Loop committet direkt auf main. Schnell, kein PR-Overhead.
Über PR + Review-Gate Branch pro Issue, eigener PR. Erst nach Review-Pass und CI auf main.
PR + Merger-Agent Mehrere Branches parallel, eigener Merger-Agent löst Conflicts und merged in Reihe.
Pre-Commit-Gate
Tests + Typecheck Lokal grün muss sein, sonst kein Commit.
+ Live-Deploy + curl-Smoke Edge-Functions können lokal grün sein und remote brechen. Smoke schließt die Lücke vor dem PR.
+ Live-Deploy + Smoke pro Branch Gleiches Gate, nur n-mal parallel auf eigenen Branches.
Code-Review
Offen, nachgelagert Matt selber: "we just need to be ready to be doing more code review."
/code-review als Pflicht-Gate Score ≥ 75 Pflicht, sonst fixe ich vor Merge.
Reviewer-Agent fest im Loop Du reviewst nur noch das Review des Agenten, nicht den Rohcode.
Container / Isolation
Docker für AFK-Nachtschicht Isoliert den Loop wenn er stundenlang autonom läuft.
Docker für lokalen Stack Lokales Supabase, Edge-Function-Runtime, Postgres in Containern für Integration-Tests.
Docker-Sandbox pro Agent (Pflicht) Jeder parallele Agent läuft in eigener Sandbox, damit sie sich nicht ins Gehege kommen.
Parallelität
Sequenziell, ein Agent Bewusst einfach gehalten.
Sequenziell, ein Agent Gleich. Parallelität kommt mit Phase 4 (mein Swarm-Skill, im Test).
Mehrere Agenten parallel Planner verteilt Issues, n Implementer arbeiten gleichzeitig auf eigenen Branches.
Token-Aufwand
Minimal Ein Agent macht alles. Kein Review-Pass dazu.
Etwas höher Plus ein Review-Pass pro PR. Kostet, gibt mir aber das Quality-Gate.
Deutlich höher n Agenten gleichzeitig, plus Reviewer, plus Merger. Volumen entsprechend.
Setup-Komplexität
Sehr niedrig Vier Zeilen Bash, ein Prompt-File, ein Issues-Ordner. Fertig.
Niedrig Bootstrap-Prompt oben legt alles an. Extra: PR-Setup + /code-review-Skill.
Hoch GitHub-Issues-Schema, Docker-Templates, Sandbox-Setup, npm-Package konfigurieren.
Wann sinnvoll
Prototypen, Lernen Wegwerf-Code, eigene Spielwiese. Geht nichts auf Kunden raus.
Solo-Bauer, Software für echte Nutzer Du baust allein und willst trotzdem das Quality-Gate, ohne dir n Agenten zu finanzieren.
Team-Last, viele Issues, Budget egal Mehr Output pro Stunde gewünscht, Token-Kosten sekundär.

Swarm-Skill im Live-Test. Sand Castle als Premium-Upgrade.

Mein eigener Swarm-Skill verteilt Issues auf mehrere Loops, die parallel laufen — Planner pickt, mehrere Implementer arbeiten gleichzeitig, Reviewer-Agent gated. Aktuell läuft er gegen Spurwert-Issues im Live-Test. Sobald er stabil sitzt, ersetzt er den sequenziellen Pass aus Sektion 03.

Wer's heute schon sauber gebaut haben will: Sand Castle von Matt Pocock ist die Industrie-Variante davon. Aufwendigeres Setup, mehr Token-Kosten, dafür fertig und durchgetestet. Aktuell für mich nicht das richtige Verhältnis — solange ich allein baue, ist mein eigener Swarm nah dran am Effekt ohne den Overhead. Bleibt im Auge für den Tag, an dem Issue-Menge oder Review-Last das rechtfertigen.

Stand Mai 2026 — wird hier aktualisiert, wenn sich was ändert.

↘Punchline

Im Kern: dumm, stur, effektiv. Wie Ralph Wiggum eben.

Drumherum: ein Gate, das nicht von meiner Aufmerksamkeit abhängt.
Ergebnis: ich review das Review, nicht den Rohcode.
Aktueller Stand: Wrapper läuft auf Spurwert, Swarm-Skill im Live-Test, Sand Castle als Premium-Pfad im Auge.
Jetzt nachbauen — Bootstrap-Prompt holen ↓

Quellen + Weiterlesen