Autonomes Claude Code

Zwei Ideen verändern gerade, wie Ingenieure KI-Agenten steuern: Ralph Wiggum-Schleifen und thread-basiertes Engineering.

Ralph ist die Anleitung, einen Agenten selbständig am Laufen zu halten. Threads sind die Anleitung, diese Autonomie zu skalieren und zu messen. Zusammengenäht bilden sie ein funktionierendes System für das Entwickeln von Software ohne einen Menschen am Steuer.

Dieser Post ist das Nähen.

Das vereinheitlichte Modell

So passen die Teile zusammen:

Thread-basiertes Engineering liefert das Skelett. Dein mentales Modell sind Threads: Base, Parallel, Chained, Fusion, Big und Long-Duration. Jeder Thread-Typ hat seinen eigenen Job.

Ralph-Schleifen treiben die L-Threads an. Das Stop-Hook-Muster, das Fertigstellungsversprechen und Verification-First-Entwicklung verwandeln lange autonome Läufe in etwas, dem du wirklich vertrauen kannst.

Verifikation ist das, was das Ganze aufrechthält. Ohne sie brechen Threads zu früh ab und Schleifen laufen ewig.

Thread Types × Verification → Reliable Autonomous Work
     ↓
Ralph Loops = Implementation of L-Threads
     ↓
Result: Features shipping while you sleep

Der Verifikations-Stack

Boris Chernys Regel ist ein Satz: Gib Claude immer eine Möglichkeit, seine Arbeit zu verifizieren.

Sie taucht auf jeder Ebene des vereinheitlichten Modells auf:

Eine Sache zählt mehr als die anderen. Je länger ein Thread läuft, desto mehr muss seine Verifikation selbst laufen. Niemand reviewed einen 26-Stunden-L-Thread von Hand. Das System muss sich selbst prüfen.

Den vollständigen Stack aufbauen

Hier ist ein funktionierendes Setup, das alle Konzepte zusammenklebt:

Ebene 1: Spezifikation (Der Pin)

Jeder autonome Lauf beginnt mit einer Spec. Diese Spec ist dein Pin. Sie verhindert, dass der Agent das Problem erfindet.

## Feature: User Dashboard
 
### Scope
 
- Display user metrics
- Show recent activity
- Add export functionality
 
### Out of Scope
 
- Real-time updates (Phase 2)
- Mobile responsiveness (Phase 2)
 
### Acceptance Criteria
 
- [ ] Metrics load in under 2 seconds
- [ ] Activity shows last 30 days
- [ ] Export generates valid CSV

Wo möglich auf bestehenden Code verweisen. Sagen, was der Agent nicht tun soll. Festlegen, wie "fertig" in klaren Worten aussieht.

Ebene 2: Test-gesteuerte Verifikation

Zuerst die Tests schreiben. Diese Tests sind die Verifikationsschicht, die L-Threads zuverlässig macht.

// For each acceptance criterion, create a test
tests/
  dashboard/
    metrics.test.ts      # Verifies metrics load time
    activity.test.ts     # Verifies activity display
    export.test.ts       # Verifies CSV generation

Laufende Agenten führen Tests immer wieder aus. Eine Schleife kann sich nicht schließen, bis die Tests grün sind. Nichts Vages. Keine frühen Ausstiege.

Ebene 3: Der Stop-Hook

Den Stop-Hook setzen, um Verifikation zu erzwingen:

// stop-hook.js
module.exports = async function (context) {
  // Run test suite
  const testResult = await runTests();
 
  if (testResult.failed > 0) {
    return {
      decision: "block",
      reason: `${testResult.failed} tests failing. Continue work.`,
    };
  }
 
  // Check for completion promise
  if (!context.output.includes("complete")) {
    return {
      decision: "block",
      reason: "Completion promise not found. Verify all work is done.",
    };
  }
 
  return { decision: "allow" };
};

Der Stop-Hook ist der Türsteher. Er ignoriert, was Claude denkt. Er kümmert sich nur darum, ob die Tests bestehen.

Ebene 4: Thread-Auswahl

Jetzt den Thread-Typ wählen, der zur Arbeit passt:

Kleines Feature, eine Datei: Base-Thread. Prompt, Agent arbeitet, Review.

Fünf unabhängige Features: P-Threads. Fünf Terminals hochfahren, jedem ein Feature zuweisen.

Datenbank-Migration mit drei Phasen: C-Thread. Nach jeder Phase verifizieren, bevor fortgefahren wird.

Kritische Architekturentscheidung: F-Thread. Die Meinungen von drei Agenten einholen, Ergebnisse vergleichen.

Über-Nacht-Feature-Build: L-Thread mit Ralph-Schleife. Vor dem Schlafengehen starten.

Multi-File-Refactor mit Sub-Tasks: B-Thread. Orchestrator spawnt Worker für jede Datei.

Ebene 5: Checkpoint-Status

Status außerhalb des Agenten halten. Das ist besonders wichtig für L-Threads:

## Progress: User Dashboard
 
### Completed
 
- [x] Set up test infrastructure
- [x] Implement metrics API endpoint
- [x] Create metrics display component
 
### In Progress
 
- [ ] Implement activity feed
 
### Remaining
 
- [ ] Add export functionality
- [ ] Performance optimization

Der Agent schreibt diese Datei während der Arbeit neu. Wenn das Kontextfenster voll wird und der Agent neustartet, liest er die Progress-Datei und macht weiter, wo er aufgehört hat.

UI-Verifikation: Das fehlende Teil

Tests können bestehen, während der Bildschirm kaputt ist.

Jeder Thread, der die UI berührt, braucht Screenshot-basierte Verifikation zusätzlich zur Test-Suite:

Workflow extension for UI work:

1. Complete implementation
2. Take screenshots of affected components
3. Review each screenshot for visual issues
4. Rename verified screenshots with "verified_" prefix
5. Do NOT output completion promise yet
6. Run one more loop to confirm all screenshots verified
7. Only then output "complete"

Das erzwingt die visuelle Review. Claude hat keine Möglichkeit, die Screenshot-Prüfung zu überspringen und die Arbeit trotzdem als fertig zu bezeichnen.

Mit Loom skalieren

Die nächste Stufe ist Loom-artige Orchestrierung.

Loom ist eine Umgebung, die für Agenten statt für Menschen gebaut wurde. Es verdrahtet Ralph-Schleifen zu reaktiven Systemen.

Level 1: Einzelne Ralph-Schleife (L-Thread) Level 2: Mehrere parallele Ralph-Schleifen (P-Threads von L-Threads) Level 3: Orchestrierte Ketten von Schleifen (B-Threads mit L-Threads) Level 4: Autonome Produktsysteme (Agenten, die ausliefern, beobachten und iterieren)

Auf Level 4 tun Agenten Folgendes:

• Hinter Feature-Flags ausliefern
• Ohne Code-Review deployen
• Analytics beobachten
• Entscheiden, ob Änderungen funktioniert haben
• Automatisch iterieren

Das ist der Z-Thread-Endpunkt. Null menschliche Eingabe. Volle Autonomie.

Wirtschaftlichkeit autonomer Schleifen

Einen Agenten am Laufen zu halten kostet etwa 10,42 USD pro Stunde auf Sonnet.

Das rechnet neu.

Die Kosten sind nicht die Begrenzung. Die Begrenzung ist wie viel zuverlässige Arbeit du definieren kannst.

Teams, die Verification-First-Schleifen richtig hinbekommen, werden mit einer anderen Rate ausliefern als Teams, die das nicht tun. Nicht ein bisschen anders. Eine komplett andere Rate.

Häufige Integrationsmuster

Muster 1: Planung + L-Thread

1. C-Thread für die Planung (du verifizierst den Plan)
2. Frischer Kontext
3. L-Thread für die Implementierung (Ralph-Schleife)
4. Abschlussprüfung

Warum es funktioniert: Planung und Implementierung leben in separaten Kontexten. Du widmest deine Aufmerksamkeit dem Plan. Der Build läuft allein.

Muster 2: P-Thread Feature-Sprint

1. Specs für mehrere Features schreiben
2. P-Threads hochfahren (einer pro Feature)
3. Jeder P-Thread läuft intern als L-Thread
4. Abgeschlossene Features reviewen, wenn sie fertig werden

Warum es funktioniert: Parallelismus lebt auf Feature-Ebene. Autonomie lebt auf Implementierungsebene.

Muster 3: F-Thread Architektur

1. Architektur-Frage definieren
2. F-Thread hochfahren (3-4 Agenten)
3. Jeder Agent schlägt eine Lösung vor
4. Ergebnisse vergleichen, die beste wählen
5. Gewählte Lösung mit L-Thread implementieren

Warum es funktioniert: Du bekommst mehrere Perspektiven auf die Entscheidungen, die schmerzhaft falsch laufen können. Einmal gewählt, läuft der Build autonom.

Muster 4: B-Thread-Orchestrierung

1. Hauptagent empfängt große Aufgabe
2. Zerlegt sie in Sub-Tasks
3. Spawnt Worker-Agenten (jeder läuft Mini-L-Thread)
4. Aggregiert Ergebnisse
5. Hauptagent verifiziert und committet

Warum es funktioniert: Die Arbeit teilt sich sauber auf. Jeder Worker behält einen engen Fokus. Der Hauptagent hält den Thread zusammen.

Fehlermodi und Fixes

Threads enden zu früh

Ursache: Schwache Verifikation Fix: Mehr Tests hinzufügen. Fertigstellungskriterien objektiv machen. Screenshot-Verifikation für UI nutzen.

L-Threads drehen ewig

Ursache: Unmögliche Aufgabe oder fehlendes Fertigstellungsversprechen Fix: Max-Iterationen setzen. Explizite Fertigstellungskriterien hinzufügen. Sicherstellen, dass der Agent weiß, wann er das Versprechen ausgeben soll.

P-Threads erzeugen Konflikte

Ursache: Agenten editieren dieselben Dateien Fix: Nach Feature oder Datei isolieren. Git-Worktrees nutzen. Harte Grenzen zwischen paralleler Arbeit ziehen.

B-Threads verlieren Kohärenz

Ursache: Sub-Agenten driften vom Hauptziel ab Fix: Bessere Specs. Mehr Checkpoints. Orchestrator prüft Sub-Agenten-Ausgabe.

Verifikation besteht, Arbeit ist falsch

Ursache: Tests decken die echte Anforderung nicht ab Fix: Engere Abnahmekriterien. Screenshot-Verifikation auf UI. Die ersten paar Läufe manuell überprüfen.

Der Implementierungspfad

Starte, wo du stehst. Bau jede Woche einen Schritt Richtung voller Autonomie.

Woche 1: Zuverlässige Base-Threads laufen. Jedes Ergebnis manuell verifizieren.

Woche 2: P-Threads hinzufügen. Zwei Agenten parallel laufen lassen. Mit dem Kontextwechsel umgehen.

Woche 3: Test-gesteuerte Verifikation implementieren. Tests vor der Implementierung schreiben.

Woche 4: Den ersten L-Thread versuchen. Den Stop-Hook nutzen. Eine Max-Iterationszahl setzen. Zusehen, wie er läuft.

Woche 5: L-Threads skalieren. Über Nacht laufen lassen. Der Verifikation vertrauen.

Woche 6: B-Threads hinzufügen. Den Agenten Sub-Agenten spawnen lassen. Multi-File-Änderungen orchestrieren.

Woche 7: F-Threads versuchen. Mehrere Meinungen zu Architekturentscheidungen einholen.

Woche 8: Muster kombinieren. P-Threads von L-Threads. B-Threads mit F-Threads.

Jede Woche messen. Wie viele Threads. Wie lang sie liefen. Wie viele Checkpoints die Arbeit brauchte.

Das Ziel

Software-Engineering bewegt sich auf autonome Schleifen zu, die durch thread-basiertes Denken skaliert werden.

• Mehr Threads: Parallelismus auf jeder Ebene
• Längere Threads: Stunden und Tage, nicht Minuten
• Dickere Threads: Agenten, die Agenten spawnen, die Agenten spawnen
• Weniger Checkpoints: Verifikation ersetzt Review

Entwickler, die so arbeiten, "nutzen nicht nur KI". Sie betreiben autonome Software-Fabriken.

Ralph gibt dir die Schleife. Threads geben dir die Form. Verifikation gibt dir das Vertrauen.

Alle drei zusammen ergibt Systeme, die ausliefern, während du schläfst.

Nächste Schritte

• Mit Ralph Wiggum-Schleifen als L-Thread-Grundlage beginnen
• Thread-basiertes Engineering für das mentale Modell lernen
• Feedback-Schleifen für Verifikationsmuster studieren
• Async-Workflows für P-Thread-Management erkunden
• Custom-Agenten für B-Thread-Orchestrierung bauen

Die Schleife ist einfach. Verifikation ist das, was zählt. Threads sind der Multiplikator.

Jetzt anfangen zu bauen.