Ralph Wiggum Technique: Iterative AI-Loops mit Claude Code

“Ich bin dabei und ich bin dabei und ich bin dabei…” — Ralph Wiggum, vermutlich über seine eigene Technik

Das Problem

Du gibst Claude Code eine Aufgabe. Claude schreibt Code, ändert Dateien, committet vielleicht sogar. Dann sagt Claude “Fertig!” — und du schaust dir das Ergebnis an.

Tests laufen nicht. Edge Cases fehlen. Die Architektur ist… kreativ.

Also gibst du den nächsten Prompt: “Fix die Tests.” Dann: “Jetzt auch den Edge Case.” Dann: “Das Error Handling fehlt.” Du bist der Loop. Du bist die Iteration. Du bist das teuerste Bauteil in der Pipeline.

Was ist die Ralph Wiggum Technique?

Geoffrey Huntley hat das Konzept beschrieben und den Namen gewählt — bewusst provokant. Die Idee ist brutal simpel:

while :; do
  cat PROMPT.md | claude-code --continue
done

Derselbe Prompt. Immer wieder. Claude sieht seine eigene vorherige Arbeit in den Dateien und der Git-History, nicht durch Output-Piping. Die Selbstreferenz kommt aus dem Dateisystem.

Huntley beschreibt die Technik als “deterministically bad in an undeterministic world” — die Fehler sind vorhersagbar, was systematische Verbesserung durch Prompt-Tuning ermöglicht.

Warum “Ralph Wiggum”?

Weil es sich dumm anfühlt. Denselben Prompt wiederholen wie ein Kind, das immer wieder “Sind wir schon da?” fragt. Aber genau wie Ralph Wiggum gelegentlich versehentlich brillant ist, produziert die Technik durch stumpfe Wiederholung oft bessere Ergebnisse als ein einzelner perfekt formulierter Prompt.

Wie funktioniert der Loop?

Iteration 1: Claude liest PROMPT.md → schreibt Code → ändert Dateien
Iteration 2: Claude liest PROMPT.md → sieht vorherigen Code → verbessert
Iteration 3: Claude liest PROMPT.md → Tests laufen → fixt Fehler
...
Iteration N: Claude liest PROMPT.md → alles grün → signalisiert Completion

Wichtig: Claude bekommt nicht seinen eigenen Output als Input. Claude bekommt denselben Prompt — aber die Dateien auf der Festplatte haben sich verändert. Claude sieht git diff, liest den aktuellen Stand, und baut darauf auf.

Das ist der Unterschied zu naivem Retry: Der Kontext verändert sich mit jeder Iteration, weil Claude aktiv Dateien modifiziert.

Praktisches Setup mit Claude Code

Der Prompt — das Herzstück

Die PROMPT.md muss klar definieren:

1. Was gebaut werden soll
2. Wann es fertig ist (messbar!)
3. Wie Fertigstellung signalisiert wird

# Aufgabe

Implementiere eine Cache-Schicht für die API-Responses in `src/cache/`.

## Anforderungen

- Redis-basierter Cache mit TTL
- Cache-Invalidierung bei Write-Operationen
- Fallback auf Direct-Query wenn Redis down
- Unit Tests mit >90% Coverage

## Erfolgskriterium

Alle Tests grün. Coverage über 90%. Kein Linting-Error.

## Completion

Wenn ALLE Kriterien erfüllt sind, gib aus:
<promise>CACHE COMPLETE</promise>

Completion Promises

Der Stop-Hook sucht nach einem <promise>-Tag im Output. Ohne dieses Tag (oder ein --max-iterations Limit) läuft Ralph unendlich weiter — wie ein Droide ohne Restraining Bolt.

# So signalisiert Claude, dass er fertig ist:
# <promise>CACHE COMPLETE</promise>

# Der Stop-Hook fängt das ab und beendet den Loop

Starten

# Einfacher Start
/ralph-loop "Refactor the auth module" --max-iterations 15

# Mit Completion Promise
/ralph-loop "Add comprehensive tests for src/api/" \
  --completion-promise "TESTS COMPLETE" \
  --max-iterations 20

Abbrechen

# Wenn Ralph in einer Endlosschleife festhängt
/cancel-ralph

Wann Ralph, wann nicht?

Faustregel: Wenn du das Erfolgskriterium als Shell-Command ausdrücken kannst (pytest, npm test, eslint .), ist Ralph geeignet.

Prompt-Tuning: Der eigentliche Skill

Die Technik ist nur so gut wie der Prompt. Schlechte Prompts produzieren Endlos-Loops oder sinnlose Änderungen.

Schlecht

Verbessere den Code in src/.

Ralph wird ewig laufen und abwechselnd Kommentare hinzufügen und entfernen.

Gut

Refactore src/api/handlers.py:
- Extrahiere duplizierte Error-Handling-Logik in eine Middleware
- Alle bestehenden Tests müssen weiterhin grün sein
- Keine neuen Dependencies
- mypy --strict darf keine neuen Errors zeigen

Wenn fertig: <promise>REFACTOR DONE</promise>

Konkretes Ziel, messbare Kriterien, klares Exit-Signal.

Profi-Tipp: Iteration Awareness

Füge dem Prompt einen Hinweis hinzu, dass Claude seine vorherige Arbeit prüfen soll:

## Arbeitsweise

1. Prüfe den aktuellen Stand der Dateien und Git-History
2. Identifiziere was bereits erledigt ist
3. Arbeite am nächsten offenen Punkt
4. Wenn alles erledigt: <promise>DONE</promise>

Lessons Learned

Max-Iterations ist dein Sicherheitsgurt

Ohne Limit läuft Ralph bis zum Heat Death des Universums (oder bis dein API-Budget aufgebraucht ist — was früher kommt). Starte konservativ mit --max-iterations 10 und erhöhe bei Bedarf.

Ein Prompt, ein Ziel

Versuche nicht, drei Features in einem Ralph-Loop zu bauen. Ein Prompt = ein klar abgegrenztes Ziel. Für mehrere Features: mehrere sequentielle Loops.

Git ist dein Undo-Button

Ralph committet Änderungen. Wenn nach 15 Iterationen nur Chaos rauskommt: git log, finde den letzten sinnvollen Stand, git reset. Deshalb immer in einem Feature-Branch arbeiten.

Der Prompt ist das Produkt

Nach ein paar Sessions merkst du: Die eigentliche Arbeit ist nicht Coden — sondern den Prompt so zu formulieren, dass Ralph zuverlässig zum Ziel kommt. Ein gut getunter Prompt ist wiederverwendbar.

Verifikation

Ob dein Ralph-Setup funktioniert:

# 1. Testlauf mit trivialem Task
/ralph-loop "Create a file called test.txt with 'Hello World'" \
  --completion-promise "FILE CREATED" \
  --max-iterations 3

# 2. Prüfen ob Completion erkannt wurde
# Loop sollte nach 1-2 Iterationen stoppen

# 3. Aufräumen
rm test.txt && git checkout .

Referenzen

• Geoffrey Huntley: Ralph — Originaler Artikel zur Technik
• Ralph Orchestrator (GitHub) — Tooling für Ralph-Loops
• Claude Code Dokumentation — Stop Hooks und CLI-Optionen