Einblick in Ralph Loops

Du nutzt AI täglich. Du kennst das Gefühl: Am Anfang einer Session liefert Claude oder GPT saubere, durchdachte Antworten. Nach etwas Zeit, ein paar Fehlern und gefühlt zehn Kontextwechseln? Der Code wird schlechter. Die Antworten ungenauer. Die KI fängt an zu halluzinieren.

Das ist kein Bug. Das ist Context Rot.

Das Problem: Context Rot

Jede AI-Session hat ein begrenztes Kontextfenster. Darin landen: System Prompt, Tool-Definitionen, MCPs, dein Chat-Verlauf, Thinking-Blöcke, Agent-Ausgaben - alles. Daraus ergeben sich zwei Probleme.

Problem 1: Die Kontextgröße ist begrenzt. Je länger die Session läuft, desto vollgepackter wird dieser Speicher. Irgendwann ist schlicht kein Platz mehr.

Problem 2: Die Dumb-Zone. Lange bevor das Fenster voll ist, passiert etwas Unangenehmes - die KI verdummt. Mehr Kontext bedeutet nicht mehr Verstand. Im Gegenteil: je voller das Fenster, desto wahrscheinlicher verliert das Modell den roten Faden. Es vergisst früh definierte Anforderungen, wiederholt bereits gelöste Probleme, oder erzeugt AI-Slop, der aussieht wie Code, aber keiner ist.

Mehr Wissen ist nicht gleich besseres Ergebnis - entgegen aller Erwartung.

/compact hilft kurzfristig, ist aber verlustbehaftet: zu Beginn definierte Anforderungen gehen verloren. Und größere Context-Windows sind keine Lösung - sie sind sogar das Gegenteil. Mehr Tokens bedeuten mehr Context Rot und mehr Kosten. Die Anbieter werben gern mit riesigen Fenstern; die Gewinner sind vor allem sie selbst. Wer tiefer einsteigen will, dem sei der Chroma Technical Report empfohlen.

Die eigentliche Lösung ist: kein langer Kontext.

Ralph Loops

Geoffrey Huntley hat die Technik erfunden und in seinem Blog-Post The Ralph Wiggum Loop beschrieben - sowie in einem sehenswerten Vortrag "The Ralph Wiggum Loop from 1st principles". Der Name kommt von Ralph Wiggum aus den Simpsons - naiv, direkt, ohne Hintergedanken. Genau so soll der Agent denken.

Die Kernidee ist radikal einfach:

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

Ein Loop. Ein Prompt. Eine Aufgabe pro Iteration.

Statt einer langen, komplex angewachsenen Session startet jede Iteration mit einem frischen Kontext. Der Agent liest einen klaren Prompt, erledigt genau eine Aufgabe, validiert, dokumentiert, committet - und der nächste Loop startet von vorne. Ein Backlog füttert den Loop, der Loop arbeitet die Aufgaben einzeln ab. Ohne menschliche Interaktion, vollständig automatisiert.

Und das Entscheidende: Du musst nicht dabei sein. Ralph schläft nicht, fragt nicht, und testet immer bevor er committet. Loop starten und Schlafen gehen - am nächsten Morgen warten neue Commits. Der Night Shift Agent.

Wie ein Ralph Loop konkret aussieht

Das PROMPT.md ist das Herzstück. Ein einfaches Beispiel:

1. Read the @requirements.md and @progress.md files. Read the last 5 commits.
2. Find the next incomplete task and implement it.
3. Run all tests, type checks, and the production build successfully.
4. Update progress.md with what you did.
5. Commit your changes.
ONLY DO ONE TASK AT A TIME.

Das ist alles. Keine Magie. Wie Huntley sagt: Ralph is a technique - kein Tool, kein Framework, eine Denkweise.

Der Ablauf einer Iteration:

1. Loop startet, liest die offenen Tasks und bestimmt den Fortschritt
2. Agent wählt die nächste offene Aufgabe
3. Agent implementiert sie - eine Aufgabe
4. Validierung über Feedback Loops (Lint, Typecheck, Tests, Build)
5. Agent dokumentiert Fortschritt und Wissen
6. Agent committet die Änderungen
7. Nächste Iteration

Der Schlüssel: Eine Aufgabe pro Loop. Diesen Constraint aufzuweichen bedeutet schlechtere Ergebnisse. Das ist keine Empfehlung, das ist eine Regel.

Voraussetzungen und Safeguards

Viel braucht es nicht: ein "Backlog-System" mit Anforderungen und eine Möglichkeit, Fortschritt und Status zu dokumentieren. Wie Specs definiert und persistiert werden, bleibt dir überlassen.

Damit dir die KI nicht aus dem Ruder läuft, helfen ein paar Safeguards. Ralph läuft typischerweise mit --dangerously-skip-permissions - also ohne Rückfragen. Dem stellst du gegenüber:

• HITL (Human in the Loop) für Kontrolle und das Anpassen von Prompt/Steering
• Max Iterations bzw. Run-Once-Begrenzungen
• Sandboxing

Was das PRD dazu beiträgt

Ein Ralph Loop braucht ein gutes PRD (Product Requirements Document) - eine klare Definition des Ziels. Nicht "bau mir eine App", sondern: was soll das System können, welche Constraints gelten, was ist der Tech-Stack.

Der Weg dorthin folgt einem Schema:

1. Anforderung beschreiben
2. Explore - Codebase durchsuchen
3. Interview - offene Fragen mit dem AI-Agenten klären
4. PRD - das Ziel klar formulieren
5. Plan - den Weg dorthin festlegen

Aus dem PRD entstehen konkrete Tasks. Diese Tasks werden iterativ von Ralph abgearbeitet.

Meine Erfahrung: Basalt

Ich habe Ralph Loops für Basalt eingesetzt - meine eigene Notes- und Todo-App. Das Besondere: GitHub Issues als Backlog, direkt in meinen AI-Workflow integriert.

Das Setup war überschaubar:

• GitHub Issues definieren die Tasks
• Der Loop liest Issues per GitHub CLI, priorisiert die Liste, implementiert den nächsten Task und committet
• Anschließend schließt der Agent das Issue und kommentiert seinen Fortschritt

Was mich überrascht hat: Der Agent macht sinnvolle Entscheidungen zur Priorisierung, wenn der Prompt das richtig anleitet. Die meiste manuelle Arbeit war die Planung und das Fine-Tuning des PROMPT.md - nicht die Implementierung.

Greenfield vs. Brownfield

Huntley ist direkt:

There's no way in heck would I use Ralph in an existing code base.

Ich teile diese Einschätzung. Ralph funktioniert am besten auf grüner Wiese:

• Guardrails klar definieren
• Grundstruktur und Initial Setup als Basis vorgeben
• Patterns und Best Practices in die Anforderungen schreiben
• HITL für Planung, Technologie-Entscheidungen und Steering
• Project-Templates nutzen

In bestehenden Codebases ist das Risiko hoch, dass der Agent Konventionen ignoriert oder veraltete kopiert.

Dennoch: Ralph kann selektiv in Brownfield-Projekten funktionieren - für klar abgegrenzte Aufgaben wie technische Migrationen oder Refactorings. Beispiel: Migration von Options API zu Composition API in Vue, gesteuert über einen spezialisierten Skill. Aber das ist die Ausnahme, nicht der Regelfall. Für euer erstes Ralph-Projekt: nehmt ein Vibe-Projekt, ein Side-Project, etwas Eigenes.

Optimierung: Ralph wie eine Gitarre stimmen

Each time Ralph does something bad, Ralph gets tuned - like a guitar.

Wenn Ralph schlechte Ergebnisse liefert, liegt das meist an einer von drei Stellen:

1. Planung: Ist das Issue/Task korrekt und ausreichend definiert?
2. Steering: Sind PROMPT.md, Agents.md, Skills und Docs konkret genug?
3. Architektur: Ist der Code modular genug, dass Ralph isoliert arbeiten kann?

Falsches Verhalten ist kein Grund aufzugeben. Es ist ein Signal zum Fine-Tuning.

Takeaways

• Context Rot ist real - kenne das Problem, bevor du mit langen AI-Sessions kämpfst
• Neuer Kontext pro Aufgabe - das ist der Kern von Ralph
• Planen, Strukturieren, Delegieren - die Kernkompetenz verschiebt sich
• Ralph Loops - ein Konzept für dein nächstes Vibe-Projekt, aber vermutlich (noch) nicht dein neuer Kollege

Ralph Loops sind kein Framework und kein Tool. Es ist eine Technik. Eine Denkweise. Und mit dem richtigen Setup ist es das Mächtigste, was ich bisher in meinen AI-Workflows eingesetzt habe.

Den Ursprungspost von Geoffrey Huntley findet ihr hier: ghuntley.com/ralph