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. Je länger die Session läuft, desto vollgepackter wird dieser Speicher. Und irgendwann 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.

/compact hilft kurzfristig, ist aber verlustbehaftet. Größere Context-Windows sind keine Lösung - sie verschieben das Problem nur.

Die eigentliche Lösung ist: kein langer Kontext.

Die Antwort: Ralph Loops

Geoffrey Huntley hat die Technik erfunden und in seinem Blog-Post The Ralph Wiggum Loop beschrieben. 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.

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.

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.

Der Agent liest die Anforderungen, bestimmt den aktuellen Fortschritt, wählt die nächste offene Aufgabe, implementiert sie - und nur sie -, validiert das Ergebnis (Lint, Typecheck, Tests, Build) und dokumentiert den Fortschritt. Dann startet der nächste Loop.

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

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. Codebase durchsuchen
3. Interview mit dem AI-Agenten - offene Fragen klären
4. PRD erstellen - das Ziel klar formulieren
5. Plan erstellen - 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, implementiert den nächsten offenen Task, committet und schließt das Issue
• progress.md hält fest, was erledigt wurde und was der Agent bei der Iteration gelernt hat

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 Tech-Stack vorgeben
• Patterns und Best Practices in die Anforderungen schreiben
• HITL (Human in the Loop) für Planung und Technologie-Entscheidungen

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
• Ein neuer Kontext pro Aufgabe - das ist der Kern von Ralph
• AFK-fähig - Loop starten und Ralph arbeitet weiter
• Planung ist die eigentliche Arbeit - gute PRDs und klare Tasks machen den Unterschied
• Greenfield first - Ralph entfaltet sein Potenzial auf der grünen Wiese
• "Believe in the Process" - Iterationen brauchen Geduld und gelegentliches Fine-Tuning

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