Die Ralph-Wiggum-Technik

Update (Jan 2025): Anthropic hat natives Task-Management mit Abhängigkeiten, Blockern und Multi-Session-Koordination über CLAUDE_CODE_TASK_LIST_ID eingebaut. Viele Ralph-Workarounds sind jetzt direkt im Produkt. Die Kernprinzipien unten gelten weiterhin. Das neue System übernimmt nur das Klempnerhandwerk.

Gib einem Agenten eine Aufgabenliste. Er schnappt sich eine, schreibt den Code, führt die Tests aus, committed. Dann die nächste. Und die übernächste. Das ganze Ding läuft, während du schläfst.

Das ist Ralph Wiggum. Kein Bezug zum Simpsons-Kind. Es ist der autonome Coding-Loop, der leise umschreibt, wie Engineers Software ausliefern.

Was Ralph anders macht

Die meisten Leute nutzen Claude Code wie eine Chat-App. Prompt. Warten. Lesen. Nochmal prompten. Für schnelle Jobs reicht das. Wenn du aber echte Features ausliefern willst, wirst du zum langsamen Teil.

Ralph dreht das um. Statt jeden Schritt zu steuern, baust du einen Loop, der Claude am Laufen hält, bis die Arbeit erledigt ist. Der Trick steckt in Claude Codes Stop-Hooks: Sie feuern genau dann, wenn der Agent versucht aufzuhören, und du kannst diesen Versuch abfangen und den Agenten zurück an die Arbeit schicken.

Das Kernmuster:

1. Claude arbeitet an einer Aufgabe
2. Claude versucht aufzuhören (gibt Abschluss aus)
3. Ein Stop-Hook greift ein und prüft: Ist die Arbeit wirklich fertig?
4. Wenn nicht, Prompt zurückgeben und weitermachen
5. Wenn ja, beenden lassen

Schritt 4 ist alles. Dein Agent hört nicht auf, sobald er denkt, er ist fertig. Er hört auf, wenn die Arbeit verifiziert ist.

Das Completion-Promise

Ralph setzt auf ein "Completion-Promise". Ein bestimmtes Wort oder eine Phrase, das wirklich "fertig" bedeutet. Wenn Claude überzeugt ist, dass die Aufgabe abgeschlossen ist, gibt es dieses Promise aus (meistens nur das Wort "complete").

// In your Ralph loop configuration
completion_promise: "complete"
max_iterations: 25

Jedes Mal, wenn Claude versucht aufzuhören, scannt der Hook nach diesem Promise. Fehlt es? Der Loop läuft weiter. Vorhanden? Loop endet. Vorzeitige Exits werden blockiert, echte kommen sauber durch.

Wichtige Regel: Kein Promise, kein Stopp. Das zwingt den Agenten weiterzumachen, bis er wirklich denkt, die Arbeit ist fertig.

Verifikation: Der unverzichtbare Kern

Boris Cherny, der Claude Code erschaffen hat, hat eine Regel, die er nie bricht: Gib Claude immer eine Möglichkeit, seine Arbeit zu verifizieren.

Diese Regel ist der Grund, warum Ralph überhaupt funktioniert. Lass die Verifikation weg und du kriegst einen Loop, der entweder ewig läuft oder viel zu früh aufhört. Füge sie hinzu, und der Loop weiß wirklich, wann er fertig ist.

Drei Verifikationsansätze passen gut zu Ralph:

1. Test-getriebene Verifikation

Schreib die Tests zuerst. Claude führt sie aus, sieht sie scheitern, schreibt Code, führt sie wieder aus. Der Loop läuft weiter, bis alles grün ist.

Workflow:
1. Run all tests in /tests/feature-x/
2. If tests fail, implement code to make them pass
3. Run tests again
4. Repeat until all tests pass
5. Output "complete" only when test suite is green

Das ist der zuverlässigste Weg. Tests lügen nicht. Bestanden oder nicht. Nichts Vages.

2. Background-Agent-Verifikation

Starte einen zweiten Agenten, dessen einziger Job es ist, die Arbeit des Hauptagenten zu prüfen. Boris nutzt das für lange Läufe:

After completing work, use a background agent to:
1. Review all changed files
2. Run the full test suite
3. Check for regressions
4. Report any issues found

Du bekommst eine unabhängige Prüfung. Findet der Background-Agent Probleme, geht der Hauptloop sofort wieder an die Arbeit.

3. Stop-Hook-Validierung

Der Stop-Hook selbst kann Validierung laufen lassen. Prüf eine Progress-Datei, starte den Linter, verifiziere den Build. Validierung schlägt fehl? Den Stopp blockieren und den Agenten zurückschicken.

// Stop hook pseudocode
if (agent_trying_to_stop) {
  validation_result = run_tests();
  if (validation_result.failed) {
    return { decision: "block", reason: "Tests failing, continue work" };
  }
  return { decision: "allow" };
}

Der Zwei-Phasen-Workflow

Erster Fehler, den die meisten machen: Planen und Implementieren im gleichen Kontext-Fenster.

Trenn sie voneinander.

Phase 1: Planning-Session

• Spezifikationen durch Gespräch generieren
• Von Hand reviewen und bearbeiten
• Einen Implementierungsplan mit expliziten Dateireferenzen erstellen
• Den Spec als "Pin" behalten, der Erfindungen verhindert

Phase 2: Implementierungs-Session

• Frischer Kontext (vorherige Konversation löschen)
• Nur das Plan-Dokument einspeisen
• Den Ralph-Loop laufen lassen
• Den Agenten iterieren lassen, bis er fertig ist

Warum der Schnitt? Weil Kontext-Fenster-Degradierung real ist. Nach genug Hin und Her fängt Claude an, sich auf veraltete Nachrichten von früher zu stützen. Ein sauberer Start mit nur dem Plan hält den Fokus eng.

Dein Plan wird zum Anker. Jede Iteration des Loops schaut darauf zurück. Das verhindert, dass der Agent in etwas abrutscht, das du gar nicht wolltest.

Praktische Umsetzung: Der PRD-Ansatz

Ryan Carsons Version sieht so aus:

1. Mit einem PRD starten (Product Requirements Document)

• Was bauen wir?
• Was ist im Scope?
• Was ist explizit außerhalb des Scopes?

2. In User-Stories mit Akzeptanzkriterien umwandeln

• Jede Story ist eine kleine, testbare Einheit
• Akzeptanzkriterien definieren "fertig"

3. Für Agent-Konsum strukturieren

• JSON- oder Markdown-Format
• Klare Checkboxen für Progress-Tracking
• Links zu relevanten Code-Stellen

4. Den Loop starten

• Agent holt sich die nächste unerledigte Story
• Implementiert sie
• Führt Verifikation (Tests) aus
• Markiert sie als erledigt
• Geht zur nächsten

Der Gewinn: Du gehst einfach weg. Wach mit fertigen Features auf, grünen Tests und Commits, die schon im Log stehen.

UI-Verifikation: Die versteckte Falle

Eine Falle, die jeden früher oder später erwischt: Die Tests werden grün, aber die UI sieht falsch aus.

Hier ist der Grund. Ralph kann fröhlich bestätigen, dass der Code läuft, während er für visuelle Bugs völlig blind ist. Die Komponente rendert, die Tests bestehen, und der Button ist trotzdem off-screen oder der Text ist halb abgeschnitten.

Beheb das mit einem Screenshot-basierten Verifikationsprotokoll.

After implementing UI changes:
1. Take screenshots of affected components
2. Rename each with "verified_" prefix after review
3. Do NOT output completion promise yet
4. Let the next iteration confirm all files are verified
5. Only then output "complete"

Das erzwingt mindestens zwei Loop-Durchläufe bei UI-Änderungen. Durchlauf eins implementiert und nimmt Screenshots. Durchlauf zwei bestätigt, dass jeder Screenshot überprüft wurde. Die visuelle Prüfung kann nicht übersprungen werden.

Die wichtige Erkenntnis: Sag Claude, dass das Umbenennen der Screenshots das Completion-Promise NICHT verdient. Die nächste Iteration signalisiert "fertig". Das blockiert vorzeitige Exits.

Wirtschaftlichkeit: Warum das alles verändert

Ein Coding-Agent, der durchgehend auf Sonnet läuft, kostet ungefähr 10,42 USD pro Stunde (gemessen über 24 Stunden).

Weniger als Mindestlohn in den meisten Ländern. Und du bezahlst für eine Maschine, die:

• Backlogs über Nacht abarbeitet
• Mehrere Features parallel läuft
• Nie müde oder abgelenkt wird
• Mit mehr Compute skaliert

Der Engpass verschiebt sich. Es hört auf "wie viel bin ich bereit auszugeben?" und wird zu "wie viel zuverlässige Arbeit kann ich definieren?"

Teams, die zuverlässige Loops laufen lassen, werden Teams, die das nicht tun, weit abhängen. Der Abstand wächst bereits.

Häufige Fehler und Fixes

Loop endet nie

Ursache: Unmögliche Aufgabe oder fehlende Abschlusskriterien Fix: Maximale Iterationsanzahl setzen (z.B. 25). Explizite Abschlusskriterien zum Prompt hinzufügen.

Loop endet zu früh

Ursache: Claude gibt das Promise aus, bevor die Arbeit fertig ist Fix: Verifikation verstärken. Tests hinzufügen. Screenshot-Protokoll für UI nutzen. "Fertig" objektiv messbar machen.

Qualität nimmt über Iterationen ab

Ursache: Kontext-Fenster füllt sich mit fehlgeschlagenen Versuchen Fix: Checkpoint-State implementieren. Erledigte Arbeit in einer externen Datei markieren. Loop sauber weiterlaufen lassen, wenn Kontext voll wird.

Agent erfindet Features

Ursache: Spec ist vage oder fehlt Fix: Dein Spec ist der "Pin", der Erfindungen verhindert. Mach ihn spezifisch. Füge explizite Referenzen auf bestehenden Code ein. Sag Claude, was es NICHT tun soll.

Deinen ersten Ralph-Loop aufsetzen

Halte es beim ersten Mal klein. Wähl ein Feature, das du gut kennst, mit Tests, die bereits existieren.

1. Installiere das Ralph-Plugin (oder implementiere das Stop-Hook-Muster selbst)

2. Erstelle deine Prompt-Datei:

Study the implementation plan in /docs/plan.md
Pick the single most important incomplete task
Implement it following existing patterns
Run tests with: npm test
On pass: mark task complete in plan.md, commit changes
On fail: fix the issue and run tests again
Output "complete" only when all tasks are done and tests pass

1. Constraints setzen:

• Max-Iterationen: 25
• Completion-Promise: "complete"
• Quality-Gates: Tests müssen bestehen, Linting muss bestehen

2. Den ersten Lauf beobachten. Noch nicht weggehen. Abbrechen, wenn das Verhalten falsch aussieht. Prompt anpassen. Nochmal laufen.

3. Autonomie schrittweise erhöhen, wenn das Vertrauen wächst.

Die Ralph-Philosophie

Ralph geht nicht darum, Menschen aus dem Coding herauszuhalten. Es geht darum, Menschen aus dem mühsamen Loop zwischen den Versuchen herauszuhalten.

Das Design bleibt deins. Die Specs bleiben deine. Du definierst, was "fertig" bedeutet. Du reviewst das Endergebnis.

Was Ralph nimmt, ist der 2-Uhr-nachts-Debugging-Slog. Der endlose Test-Fix-Test-Grind. Das Wechseln zwischen Features. Das ist der Teil, den es übernimmt.

Boris kommt immer wieder zur gleichen Aussage: Verifikation treibt alles. Gib Claude eine Möglichkeit, seine eigene Arbeit zu prüfen, und es wird stundenlang zuverlässig laufen. Nimm das weg und du spielst Glücksspiel.

Fang mit Verifikation an. Bau deine Loops darum herum. Die autonome Coding-Zukunft kommt nicht durch klügere Prompts. Sie kommt durch bessere Feedback-Systeme.

Nächste Schritte

• Probiere natives Task-Management für eingebaute Persistenz und Multi-Session-Koordination
• Lerne über Hooks, um benutzerdefinierte Stop-Verhaltensweisen zu implementieren
• Erkunde asynchrone Workflows für das Ausführen mehrerer Loops
• Lies über thread-basiertes Engineering zum Skalieren deiner autonomen Workflows
• Schau dir Feedback-Loops für Verifikationsmuster an

Wer gut in Ralph wird, ist nicht nur ein Claude Code-Nutzer. Er baut Systeme, die Code liefern, während er schläft.