Die Ralph-Wiggum-Schleife, Von Den Ersten Prinzipien

Wenn du einen AI-Coding-Agenten für mehr als ein paar Stunden verwendet hast, kennst du die „Mauer“: der Agent macht sichtbare Fortschritte, bleibt dann stehen — und du endest damit, die Arbeit selbst zu flicken und zu beenden.

Wie es bei KI-Ingenieuren oft der Fall ist, hat sich ein Muster herausgebildet, um dieses Problem zu lösen: Lasse den Agenten einfach so lange gegen externe Überprüfungen laufen, bis der Job tatsächlich bestanden ist.

Der Ansatz setzte sich so stark durch, dass er einen Namen bekam — Ralph Wiggum.

Und das Meme setzte sich durch, weil das Muster funktionierte. Bis Ende 2025 hatte Anthropic es in ein offizielles Claude Code Plugin formalisiert.

Ralph repräsentiert eine Veränderung in der Art und Weise, wie Entwickler vorhandene Werkzeuge nutzen. Anstatt KI-Systeme als interaktive Assistenten zu behandeln, werden sie als langfristige Prozesse ausgeführt, die durch Tests, Linter und explizite Stoppbedingungen geleitet werden.

Also, dieser kurze Leitfaden ist die praktische Version. Wir werden sehen, was Ralph eigentlich ist, warum es funktioniert, wie es sich verbreitet hat und was sich geändert hat, als es produktisiert wurde.

Was Ist „Ralph“ Wirklich?

Im Kern ist das, was Ralph ist: Führe einen Agenten in einer Schleife aus, prüfe das Ergebnis gegen etwas, das nicht lügen kann, wie einen Test, einen Linter, einen Typ-Checker; und fahre mit der Schleife fort, bis es bestanden ist.

Das war’s.

Das ursprüngliche Beispiel, das Geoffrey Huntley im Juli 2025 teilte, war absichtlich direkt:

while :; do cat PROMPT.md | npx --yes @sourcegraph/amp ; done

Claude-Codevarianten folgen derselben Form, nur mit mehr Schutzmaßnahmen. Aber das Prinzip ändert sich nicht: Füttere einen festgelegten Prompt immer wieder in den Agenten, bis die externe Realität sagt, dass Du fertig bist.

Die Schleife selbst ist fast irrelevant, und was zählt, ist der Vertrag:

• Zustand befindet sich im Repository: Dateien, Differenzen, Protokolle, Git-Verlauf; alles Dauerhafte gehört hierher.
• Abschluss liegt außerhalb des Modells: Tests, Linters, Typ-Checker; der Agent entscheidet nicht, wann es fertig ist; das macht das Testsystem.
• Der Agent ist austauschbar: Er ist ein Arbeiter, der wiederholt aufgerufen wird, bis das Tor passiert ist; wenn er heute langsam oder dumm ist, tausche ihn morgen gegen etwas Schnelleres aus.

Betrachtet man es so, wird Ralph zu einem Designprinzip: Hör auf, das Modell zu bitten zu wissen, wann es fertig ist. Erwarte nicht, dass es sich über Kontextzurücksetzungen hinweg an Einschränkungen erinnert.

Baue stattdessen das System so auf, dass das Modell auf diese Weise nicht versagen kann.

Warum Hält Die Schleife Stand?

Einige Gründe:

1. Kontextfenster Verhalten Sich Wie Puffer

Huntley rahmt Kontextfenster oft in niedrigen Ebenen:

„Denke wie ein C- oder C++-Ingenieur. Kontextfenster sind Arrays.“

Sie haben eine feste Größe; sie gleiten; sie überschreiben; sie vergessen.

Lange Sitzungen setzen eine Kontinuität voraus, die nicht existiert. Daher führt die Behandlung des Puffers als dauerhaften Speicher zu Drift, verpassten Einschränkungen und inkonsistentem Verhalten.

Ralph beugt sich der Realität des Systems. Anstatt so zu tun, als wäre das Kontextfenster stabil, behandelt er es als wegwerfbar.

Der temporäre Speicher des Agenten wird zwischen den Durchläufen zurückgesetzt, während der dauerhafte Zustand auf der Festplatte erhalten bleibt. Das Repository sammelt Wahrheiten über die Läufe hinweg. Dies macht das Neustarten des Agenten routinemäßig anstatt verschwenderisch; jede Schleife beginnt frisch, baut jedoch auf dem auf, was tatsächlich bestehen blieb.

2. Externe Überprüfungen Übertreffen Internes Überlegen

Viele Agent-Frameworks reagieren auf Fehler, indem sie Struktur in das Modell einbauen: Planer, Zusammenfassungen, interner Zustand und Reflexionsschleifen.

Ralph hält die Intelligenz außerhalb des Agenten. Er stützt sich auf:

• Ein fixierter Spezifikationspunkt, der nicht driftet
• Konkrete Beweise vom letzten Durchlauf
• Ein deterministisches Tor, das den Erfolg bewertet

Der Agent entscheidet nicht, wann die Arbeit beendet ist – das Geschirr tut es.

Deshalb ist Ralph hervorragend in mechanischer Arbeit: Refaktorisierungen, Migrationen, Aufräumarbeiten, Konformitätsaufgaben… Überall dort, wo Erfolg durch ein Skript und nicht durch Urteilsvermögen gemessen werden kann, wird Iteration zuverlässig.

Das Modell kann sich nicht aus den Anforderungen herauswinden, weil die Anforderungen außerhalb seiner Argumentation liegen.

3. Verdichtung Erodiert Einschränkungen

Eine wiederkehrende Kritik von Huntley zielt auf Zusammenfassung und Verdichtung ab.

Wenn ein System das Modell auffordert zu entscheiden, was wichtig genug ist, um es zu behalten, gehen Informationen verloren — Einschränkungen lockern sich, Randfälle verschwinden und Pins fallen heraus.

Ralph umgeht dies, indem er die Eingaben buchstäblich hält:

• Die Spezifikationen bleiben wörtlich, anstatt zusammengefasst zu werden, 
• Die Fehlerausgabe bleibt roh und ungefiltert; und 
• Die Speicheraufbereitung wird nie in das Modell überführt.

Das Geschirr bewahrt die Genauigkeit; der Agent arbeitet darin, beschränkt durch das, was tatsächlich vorhanden ist, anstatt durch das, was das Modell denkt, was dort sein sollte.

Wie Hat Sich Die Idee Verbreitet?

Der Zeitplan ist ziemlich komprimiert.

• 19. Juni 2025: Bei einem Treffen in San Francisco diskutieren etwa 15 Ingenieure über agentic coding. Huntley präsentiert Ralph, Cursed (die von Ralph entwickelte Programmiersprache) und livestreamt autonome Codierung über Nacht, während er in Australien schläft. Im Raum findet ein beunruhigendes Gespräch darüber statt, wie einfach es ist, 80%-90% einer SaaS zu kopieren und wie viele Arten von Arbeit vollständig verschwinden werden.
• Juli 2025: Huntley veröffentlicht den ursprünglichen Blogbeitrag mit der grundlegenden Bash-Loop-Struktur. Der Beitrag enthält ein leichtgewichtiges Beispiel und eine Bitte: „Du könntest wahrscheinlich das cursed lang repo auf GitHub finden, wenn Du danach suchst, aber bitte teile es noch nicht.“
• August 2025: Der YC agents Hackathon findet statt — Teams führen Claude Code in kontinuierlichen Schleifen aus. Das Ergebnis ist die Übernachtung von 6 Repositories. Dexter Horthy führt eine experimentelle Ralph-Schleife für ein React-Codebase-Refactoring durch. Über 6 Stunden entwickelt er einen vollständigen Refactoring-Plan und führt ihn aus.
• September 2025: Huntley startet offiziell Cursed Lang, die von Ralph entwickelte Programmiersprache. Sie existiert in drei Implementierungen (C, Rust, Zig), verfügt über eine Standardbibliothek und einen Stage-2-Compiler, der in Cursed selbst geschrieben ist.
• Oktober 2025: Dexter präsentiert Ralph bei Claude Code Anonymous in San Francisco. Die Frage aus dem Publikum: „Empfiehlst Du dies also?“ Seine Antwort: „Einfache Dinge können erstaunlich gut funktionieren. Was könnten wir von einer intelligenten Version erwarten?“
• Dezember 2025: Anthropic veröffentlicht ein offizielles Ralph Wiggum Plugin. Das Plugin übernimmt Huntleys Bash-Loop und formalisiert ihn mit Stop Hooks und strukturierten Fehlerdaten.
• Januar 2026: Huntley und Horthy führen eine ausführliche YouTube-Diskussion durch, in der sie die ursprüngliche Bash-Loop-Implementierung von Ralph mit der Anthropic Stop-Hook-Implementierung vergleichen.

Bash-Loop Ralph Vs. Plugin Ralph

Der ursprüngliche Ralph ist eine 5-zeilige Bash-Schleife. Du gibst eine Prompt-Datei ein, leitest sie an Claude weiter, prüfst, ob die Ausgabe Deinen Test besteht, und wiederholst den Vorgang, bis dies der Fall ist. Alles befindet sich auf der Festplatte, alles ist sichtbar. Wenn etwas kaputt geht, kannst Du genau sehen, warum.

Das Anthropic-Plugin kehrt dieses Modell um, sodass es statt die Schleife von außen auszuführen, einen Stop-Hook in Deiner Claude-Sitzung installiert. Wenn Claude versucht zu beenden, unterbricht der Hook dies, überprüft Deine Abschlussbedingungen und speist denselben Prompt wieder ein, wenn noch Arbeit übrig ist. Die Dateien, die Claude modifiziert hat, sind immer noch da.

Die Git-Historie ist noch vorhanden, aber die Mechanik des Harness ist jetzt undurchsichtig — verborgen in einer Markdown-Statusdatei, abhängig von Berechtigungen, leicht zu beschädigen, wenn Du nicht weißt, was Du tust.

Dies ist der klassische Abstraktionskompromiss.

Das Plugin senkt die Einführungskosten. Du musst kein Bash schreiben und Du musst nicht über Schleifen nachdenken. Aber wenn der Mechanismus verborgen wird, kann die ursprüngliche Einsicht leichter übersehen werden.

Die Bash-Loop-Version zwingt dich dazu, das Testsystem zu entwerfen. Die Plugin-Version ermöglicht es dir, diesen Schritt zu überspringen, was in Ordnung ist, bis du auf einen Sonderfall triffst und nicht sehen kannst, was tatsächlich passiert.

Dexter Horthy hat es getestet und festgestellt, dass es auf kryptische Weise abstürzt, es sei denn, Du verwendest „–dangerously-skip-permissions“. Das Plugin installiert Hooks an seltsamen Stellen, verwendet undurchsichtige Zustandsdateien und wenn Du die Markdown-Datei löschst, bevor Du es stoppst, zerstörst Du Claude in diesem Repository, bis Du das Plugin vollständig deaktivierst.

Also, was ist die Lehre? Beides funktioniert, aber aus unterschiedlichen Gründen. Die Bash-Schleife funktioniert, weil sie einfach und transparent ist. Das Plugin funktioniert, wenn die Abstraktion nichts Wichtiges verbirgt.

Was Lernst Du Daraus, Es Zu Betreiben?

Ralph nimmt Abstand zwischen dem Menschen und dem Agenten an. Du sitzt nicht in der Sitzung und lenkst sie. Stattdessen startest Du sie, gehst weg, inspizierst die Artefakte, wenn sie fertig ist, und passt die Beschränkungen für die nächste Iteration an.

Die Interaktion erfolgt auf der Harness-Ebene — der Aufforderung, den Tests, den Stoppbedingungen — nicht innerhalb des Gesprächs.

Im Laufe der Zeit zeigt sich ein Muster: Die meisten Ausfälle sind keine Modellausfälle; es sind Ausfälle der Ausrüstung.

Die Spezifikation war unklar, der Test zu umfassend, oder die Erfüllungsbedingung beschrieb nicht wirklich, was „fertig“ bedeutet.

Sobald Du das ein paar Mal gesehen hast, verschiebt sich Dein Instinkt. Du hörst auf zu fragen „Wie mache ich Claude schlauer?“ und beginnst zu fragen „Wie mache ich die Einschränkungen enger?“

Hier werden die technischen Daten entscheidend.

Spezifikationen Als Steuerungsoberflächen

Huntley definiert Spezifikationen nicht als Dokumentation, sondern als feste Steuereingaben. Du erstellst sie durch Gespräche mit Claude, bearbeitest sie gezielt, bis sie präzise sind, und dann heftest du sie an. Einmal angeheftet, ändern sie sich nicht mehr für den gesamten Zyklus.

Dies ist wichtig, weil Spezifikationen gleichzeitig drei Dinge tun:

1. Sie binden, was der Agent erfinden kann: Ohne eine genaue Spezifikation fügt Claude defensive Schichten, Abstraktionen oder Funktionen hinzu, die nie angefordert wurden, und erweitert den Umfang mit jeder Iteration. 
2. Sie verankern Suche und Wiederfindung: Damit der Agent keine neuen Anforderungen halluziniert.
3. Sie stabilisieren das Verhalten über Durchläufe hinweg: Jede Iteration löst dasselbe Problem, nicht eine leicht abweichende Interpretation davon.

Wenn deine Spezifikation unklar darüber ist, was „fertig“ bedeutet, wird der Agent es bei jeder Schleife anders interpretieren. Du endest mit Drift, Umfangserweiterung und Iterationen, die sich widersprechen.

Wie Führst Du Die Schleife Verantwortungsvoll Aus?

Ein minimales Ralph-Setup sieht oft wie folgt aus:

MAX_ITERS=30
for i in $(seq 1 $MAX_ITERS); do
  cat PROMPT.md | claude
  if ./ci.sh; then exit 0; fi
done
exit 1

Die Mechanik der Schleife ist weit weniger wichtig als die Regeln, die sie umgeben:

• Halte die Spezifikation unveränderlich; passe sie nicht mitten in der Schleife an, basierend darauf, was Claude tut. 
• Kodiere die Vollständigkeit als ausführbare Überprüfungen.
• Setze Grenzen für Iterationen und Zeitlimits, damit die Schleife nicht endlos läuft und dein Token-Budget aufbraucht. 
• Bewahre Protokolle und Unterschiede, damit du nachvollziehen kannst, was schiefgelaufen ist, falls dies passiert. 

Weiterhin hat die betriebliche Praxis einige Heuristiken offenbart, die von Bedeutung sind:

• Bevorzuge kleine, regelmäßige Diffs gegenüber großen Überarbeitungen, da große Änderungen Fehler verstärken und schwerer zu debuggen sind. 
• Führe auf dem aktuellen Hauptzweig erneut aus, statt neu zu verzweigen, weil Merge-Konflikte Iterationen verschwenden.
• Und vermeide es, Ralph für explorative Arbeiten zu verwenden, denn wenn du keine klaren Akzeptanztests hast, erhältst du nur eine chaotische Schleife, die Dinge erfindet, die du nicht angefordert hast.

Die Einschränkung ist die Funktion.

Die Schleife Ist Die Lektion

Als Ralph an Fahrt gewann, entstanden Variationen. Einige Teams bauten strukturierte äußere Schleifen um Werkzeug-aufrufende Agenten herum. Andere fügten separate Verifizierungskomponenten hinzu: ein anderes Modell, das die Ausgabe des Arbeiters überprüft, bevor die Schleife sich entscheidet zu beenden. Diese Erweiterungen funktionieren, ja, aber nur, wenn sie die ursprüngliche Einsicht respektieren.

Die Regel ist einfach: Die Verifikation muss deterministisch bleiben, und Zusammenfassungen dürfen niemals primäre Eingaben ersetzen.

• Wenn Du einen Verifizierer hinzufügst, sollte dieser konkrete Dinge prüfen: Tests bestehen, Linter beendet sich ordnungsgemäß, git diff entspricht den Erwartungen. 
• Wenn Du strukturierte äußere Schleifen hinzufügst, sollten sie immer noch die rohe Ausgabe und die rohen Protokolle sehen, nicht eine aufgeräumte Zusammenfassung dessen, was schiefgelaufen ist. 

Huntleys Hauptargument ist, dass die Softwareentwicklung als Beruf effektiv tot ist, aber Softwareengineering – die Praxis, Systeme gut zu bauen – lebendiger ist denn je.