Well Engineered Tech - Blog

Ralph Wiggum als Software-Entwickler

- Hamburg, Germany
This article is also available in English.

Meine Schwester ist Simpsons-Fan. Als ich ihr erzählte, dass es in Claude Code ein Plugin namens Ralph Wiggum gibt, dachte sie, ich mache einen Witz. Ralph ist der Junge, der “Me fail English? That’s unpossible!” sagt und Klebestifte isst.

Ralph Wiggum

Ende 2025 ging die Ralph-Wiggum-Technik viral1. Die Namensgebung ist kein Zufall, denn die Technik funktioniert genauso wie Ralph durch sein Leben stolpert, also ständig Fehler machen, nie aufhören, irgendwie ans Ziel kommen.

Geoffrey Huntley, ein australischer Entwickler, hat die Technik erfunden. Sie besteht aus einer einzigen Zeile Bash-Code2:

while :; do cat PROMPT.md | claude ; done

Das ist alles, eine Endlosschleife, die einem AI-Agenten immer wieder denselben Prompt füttert. Claude Code versucht die Aufgabe zu lösen, beendet die Session, die Schleife startet ihn sofort wieder. Bei jedem Durchlauf sieht der Agent seine bisherige Arbeit in den Dateien und der Git-Historie, lernt aus seinen Fehlern und wird ein Stück besser. Die Philosophie dahinter ist verblüffend einfach, denn Huntley nennt es “berechenbar fehlerhaft in einer unberechenbaren Welt”2, also die Idee, dass vorhersagbares Scheitern besser ist als unvorhersagbares Gelingen. Jedes Mal, wenn Ralph in die falsche Richtung läuft, liegt es nicht am Tool, sondern der Prompt wird nachgestimmt, wie eine Gitarre.

Das klingt nach Spielerei, doch die Ergebnisse sprechen eine andere Sprache. Huntley ließ Claude Code drei Monate lang in einer solchen Schleife laufen und erstellte damit eine funktionierende Programmiersprache im Gen-Z-Slang3. Beim Y Combinator Hackathon haben Teams mit Ralph-Schleifen sechs Repositories über Nacht fertiggestellt4. Ein Entwickler erledigte einen 50.000-Dollar-Vertrag für 297 Dollar API-Kosten.

Das Plugin

Anthropic hat die Technik inzwischen in ein offizielles Plugin für Claude Code überführt4. Der Mechanismus ist elegant in seiner Einfachheit. Ein Stop-Hook fängt jeden Versuch von Claude Code ab, die Session zu beenden, blockiert den Exit und speist denselben Prompt wieder ein, im Grunde ein while true für AI. Nach der Installation über /plugin install ralph-wiggum@claude-plugins-official startet ein Loop so:

/ralph-loop \
  "Baue eine REST-API für Todos mit folgenden Anforderungen:
   - POST /todos: Neuen Todo erstellen (title required, max 100 chars)
   - GET /todos: Alle Todos auflisten mit Paginierung
   - PUT /todos/:id: Todo aktualisieren
   - DELETE /todos/:id: Todo loeschen
   - Validierung mit Fehlermeldungen
   - Unit-Tests mit >80% Coverage
   - Alle Tests muessen gruen sein
   Gib <promise>COMPLETE</promise> aus wenn alle Anforderungen erfuellt sind." \
  --completion-promise "COMPLETE" \
  --max-iterations 50

Claude Code wird dann implementieren, testen, Bugs beheben. Das wiederholt sich so lange, bis alle Anforderungen erfüllt sind oder das Iterations-Limit erreicht ist. Die Kunst liegt im Prompt, denn vage Anweisungen wie “Baue eine gute API” führen zu endlosen Schleifen ohne Fortschritt, weil das Modell nicht weiß, wann es fertig ist. Klare Abbruchkriterien, inkrementelle Ziele und eine explizite Definition von “fertig” sind entscheidend.

Ralph eignet sich für Aufgaben mit automatischer Verifikation, also Tests, Linter, Build-Prozesse. Es eignet sich für Greenfield-Projekte, bei denen man den Rechner über Nacht laufen lassen kann. Und es eignet sich für Aufgaben, bei denen der erste Versuch selten perfekt ist. Für Design-Entscheidungen, bei denen menschliches Urteil gefragt ist, eignet sich die Technik dagegen nicht, denn dort ist gezieltes Vorgehen wichtiger als bloße Ausdauer.

Und dann sind da die Kosten. Autonome Schleifen verbrennen Tokens. Ein 50-Iterations-Durchlauf auf einer größeren Codebase kann schnell 50 bis 100 Euro kosten oder die aktuelle Claude-Session an ihr Nutzungslimit bringen. Das --max-iterations-Flag ist keine Nebensache, sondern der wichtigste Schutz vor bösen Überraschungen.

Das Plugin hat noch eine weitere Einschränkung, die mir aufgefallen ist. Alle Iterationen laufen im selben Kontextfenster, das irgendwann voll ist. Huntleys ursprüngliche Bash-Schleife startet bei jeder Iteration einen frischen Prozess, der nur über Dateien und Git-Historie weiß, was vorher passiert ist, aber das Plugin akkumuliert den gesamten Kontext.

Wer längere Läufe plant, fährt mit der klassischen Bash-Schleife besser. Eine Variante nutzt eine Markdown-Datei als externes Gedächtnis zwischen den Durchläufen5:

while true; do
  claude "Arbeite an der Aufgabe in TASKS.md. \
          Aktualisiere TASKS.md am Ende mit dem aktuellen Stand \
          und was als nächstes zu tun ist."
done

Jede Iteration startet mit frischem Kontext, liest TASKS.md, arbeitet und schreibt den neuen Stand zurück. Das Wissen überlebt nicht im Kontextfenster, sondern in der Datei.

Und damit ist die Ironie nicht zu übersehen. Die effektivste Methode, AI für komplexe Aufgaben einzusetzen, liegt auf der Hand: einfach weiterlaufen lassen bis es klappt. Keine ausgefeilte Orchestrierung, kein komplexes Prompt-Engineering, nur eine Schleife und Geduld. Ob das bei jeder Aufgabe funktioniert, weiß ich nicht, aber Ralph Wiggum ist nicht trotz seiner Naivität und Tollpatschigkeit erfolgreich, sondern weil er nie aufhört.

Meine Schwester fand das alles sehr amüsant.