Der Ralph Wiggum Loop: Autonome Code-Generierung mit frischem Kontext

Ralph Wiggum ist der einfältige Junge aus den Simpsons, der Sätze sagt wie "I'm learnding!" und Kleber isst. Ausgerechnet er ist jetzt Namensgeber für eine Technik zur autonomen Code-Generierung. Die Idee dahinter: Wenn dir der Gedanke, Code autonom generieren zu lassen, den Magen umdreht, dann ist das genau das Gefühl, das du systematisch adressieren solltest.

Geoffrey Huntley, ein australischer Open-Source-Entwickler, hat die Idee Mitte 2025 entwickelt und ihr den Namen gegeben. Die treibende Frage dahinter war einfach. Wie weit kommt man, wenn man KI-Agenten einfach laufen lässt, ohne ständig einzugreifen?

Der Loop

Der Ralph Loop ist kein Ersatz für einen strukturierten Entwicklungsansatz, sondern ein Ausführungsmotor für einen, den du bereits hast. Die Grundidee ist denkbar einfach:

1while has_more_todos; do
2  code-agent --prompt "Bearbeite den nächsten Task aus todo.md" --non-interactive --yolo
3done

Ein Skript startet den KI-Agenten und übergibt ihm einen Prompt. Sobald der Agent fertig ist und sich beendet, startet das Skript ihn erneut. Wieder mit demselben Prompt, wieder mit frischem Kontext. Nach jedem Durchlauf prüft es, ob noch offene Tasks vorhanden sind. Wenn nicht, beendet sich der Loop.

Konkret funktioniert das mit Agenten wie Claude Code oder OpenCode. Sie lassen sich im Non-Interactive-Modus starten. Prompt rein, autonom abarbeiten, terminieren. Damit der Agent selbstständig arbeiten kann, muss er alle Berechtigungen haben und alles ausführen dürfen. Das ist der --yolo-Modus. Dateien schreiben, Shell-Befehle ausführen, Änderungen vornehmen. Ohne Rückfragen. Sandboxing wird damit essentiell. Der Agent braucht eine isolierte Umgebung, in der er keinen Schaden anrichten kann.

Für einfache Projekte reicht ein minimales Skript. Für komplexere Workflows kannst du dir das Skript von der KI generieren lassen. Vielleicht hat dein Loop mehrere Schritte pro Durchlauf, etwa Implementierung und Review. Vielleicht nutzt du auch ein Spec-Framework wie BMad. Die Grundidee bleibt dieselbe.

Warum ein Loop? Das frischer-Kontext-Prinzip

Context Windows sind der "Arbeitsspeicher" eines LLMs während einer Session. Die Größe ist begrenzt. Die Qualität der Ergebnisse nimmt ab, je mehr davon genutzt wird. Zusätzlich gehen Details verloren, wenn das LLM den Kontext zusammenfassen (Compacting) muss. Das Modell verliert den roten Faden. Halluzinationen nehmen zu, frühere Entscheidungen werden vergessen.

Der Ralph Wiggum Loop löst dieses Problem. Jede Iteration startet einen neuen Prozess mit einem frischen, leeren Kontext. Statt immer mehr Kontext zu akkumulieren, beginnt jede Iteration bei null. Nur die Specs und der Implementierungsplan landen im Kontext, alles andere ist weg. Eine Aufgabe pro Durchlauf, dann Reset.

Wie du mit dem Ralph Wiggum Loop arbeitest

Spezifikationen als Fundament

Der Loop ist nur die Automatisierung. Das Fundament ist eine gute Spezifikation mit einer abhakbaren Aufgabenliste. Im Ralph Loop wird pro Iteration genau eine Aufgabe implementiert, als erledigt markiert und der Agent neu gestartet. Die Aufgaben müssen gut spezifiziert und klar abgrenzbar sein.

Wie du zu dieser Struktur kommst, ist offen. Du erstellst die Spezifikation im Dialog mit der KI. "Ich will X bauen. Stell mir Fragen. Erstelle eine Spezifikation und einen Implementierungsplan." Oder du nutzt ein Framework wie BMad, das diesen Prozess formalisiert und am Ende Stories und Tasks produziert, die abgearbeitet werden können.

Das Format ist zweitrangig. Entscheidend ist: eine Aufgabe, ein Durchlauf.

On the Loop

Kief Morris beschreibt auf martinfowler.com drei Modelle, wie Menschen mit KI-Agenten zusammenarbeiten. Out of the Loop bedeutet, der Mensch definiert nur das Ziel. Den Rest macht der Agent alleine. Das ist "Vibe Coding". In the Loop bedeutet, der Mensch prüft jeden einzelnen Output des Agenten. Das klingt sicher, skaliert aber nicht. Agenten generieren Code schneller, als Menschen ihn reviewen können. Der Mensch wird zum Flaschenhals.

Das dritte Modell ist On the Loop. Statt jeden Output zu inspizieren, baut der Mensch den Rahmen, in dem der Agent arbeitet: Spezifikationen, automatisierte Qualitätsprüfungen, Workflow-Regeln. Wenn das Ergebnis nicht stimmt, wird nicht der Code manuell behoben, sondern der Agent verbessert, sodass das Problem nicht wieder auftritt.

Harness Engineering

Die KI macht Fehler. Die Frage ist nicht, wie du diese Fehler verhinderst, sondern wie der Agent Feedback bekommt und den Fehler selbst behebt.

Stell dir eine Rakete vor, die einen weit entfernten Himmelskörper erreichen soll. Jede Abweichung sorgt dafür, dass sie weit am Ziel vorbeifliegt. Was sie braucht, sind automatische Kurskorrekturen. Automatisierte Tests stellen sicher, dass die Anwendung funktioniert. Security-Scans verhindern, dass unsichere Dependencies in die Anwendung gelangen. Code-Quality-Checks fangen Fehler ab, bevor sie im Build landen. Wenn eine Prüfung fehlschlägt, bekommt der Agent das Feedback und behebt den Fehler.

Morris, Anthropic und OpenAI nennen es Harness Engineering. Huntley nennt es Back Pressure Engineering. Die Begriffe sind unterschiedlich. Die Kernaussage ist dieselbe: Je besser der Rahmen, desto zuverlässiger die Agenten.

Von Attended zu Unattended

Zurück zur Rakete. Am Anfang der Flugbahn sind Kurskorrekturen besonders kritisch, weil sich kleine Abweichungen über die Strecke multiplizieren. Am Anfang startest du den Loop manuell und beobachtest jeden Durchlauf. Du bewertest, ob die automatischen Feedback-Mechanismen greifen. Wenn nicht, passt du die Specs oder den Prompt an. Das ist "Attended". Du sitzt daneben und schaust zu.

Mit der Zeit werden die Kurskorrekturen zuverlässiger. Du investierst in automatisiertes Feedback statt den Agenten manuell zu korrigieren. Irgendwann startest du den Loop abends und schaust morgens, was er gebaut hat. Das ist "Unattended". Du prüfst nur noch das Ergebnis.

Der Übergang ist graduell und erfordert Vertrauen. Es gibt keine feste Regel, wann du bereit bist, die KI alleine arbeiten zu lassen. Nur die Erfahrung, die du durch das Beobachten sammelst.

Ein Beispiel: Eine Ralph Wiggum Zitat-App

Um den Ralph Loop in der Praxis zu testen, habe ich eine kleine App bauen lassen: Umpossible. Eine Web-App, in der man Ralph-Wiggum-Zitate durchstöbern und voten kann.

Die Spec habe ich im Dialog mit der KI erstellt. Meine Anfangsbedingungen waren:

1## Umpossible – Ralph Wiggum Zitat-App
2- Zeigt zufällige Ralph-Wiggum-Zitate mit Staffel und Episode
3- Voting: Upvotes pro Zitat, ein Vote pro Session
4- Zitat-Übersicht mit Filter und Sortierung
5- Admin-Bereich für Zitat-Verwaltung
6- Dark Mode mit System-Erkennung
7- Responsive, barrierefrei (WCAG 2.1 AA)

Alle weiteren Details habe ich mit der KI im Dialog erarbeitet. Die fertige Spec enthält den Tech-Stack, Seitenstruktur, Accessibility-Anforderungen und mehr. Daraus habe ich mit der KI zusammen einen Implementierungsplan mit 16 Phasen generieren lassen. Von der Projektstruktur über Backend-API, Frontend-Komponenten und Barrierefreiheit bis zu Tests und Dokumentation.

Jede Phase wurde in einem eigenen Loop-Durchlauf abgearbeitet. Das Skript dafür ist simpel: Es prüft, ob noch offene Phasen im Plan stehen, startet Claude Code mit dem Prompt, und wiederholt das bis alles erledigt ist. Ein frischer Kontext pro Phase, keine Altlasten aus vorherigen Iterationen. Nach 16 Durchläufen hatte ich eine funktionierende, getestete App. Nach etwa vier Stunden hatte der Loop alle Phasen abgeschlossen. Die API-Kosten für das gesamte Projekt, von der Spezifikation bis zur fertigen Implementierung, lagen bei rund 70 Euro.

I Bent My Wookiee

Ralph stolpert, stürzt, und sagt dann: "I bent my Wookiee." Jeder, der einen KI-Agenten zu lange in einer Session hat arbeiten lassen, kennt das Gefühl. Irgendwann verbiegt sich alles, und dann fällt es hin. Was ich aus dem Experiment mitgenommen habe, lässt sich auf zwei Prinzipien eindampfen: Frische Kontexte halten den Agenten auf Kurs. Der Harness fängt ihn auf, wenn er trotzdem stolpert. Beides klingt trivial. Die Disziplin, es konsequent umzusetzen, ist es nicht. Nimm dir ein kleines Projekt, schreib eine Spec, und lass den Loop laufen. Das Gefühl, morgens auf funktionierenden Code zu schauen, den du nicht selbst geschrieben hast, muss man einmal erlebt haben.