Thread-basiertes Engineering

Woher weißt du eigentlich, ob du im KI-gestützten Engineering besser wirst?

Nicht "sich produktiv fühlen." Zählen. Messen. Zahlen zeigen, dass diese Woche besser war als die letzte.

Thread-basiertes Engineering ist der Rahmen, der das möglich macht. Jede KI-gestützte Arbeit wird zu einer diskreten Einheit, die als Thread bezeichnet wird. Sobald Arbeit als Threads auftaucht, kannst du sie optimieren.

Ein Thread ist eine Einheit technischer Arbeit, die sich über Zeit erstreckt und von dir plus einem Agenten angetrieben wird.

Zwei Stellen in jedem Thread brauchen einen Menschen:

1. Den Anfang. Du promptest oder planst.
2. Das Ende. Du reviewst oder validierst.

Was ist mit der Mitte? Der Agent übernimmt sie durch Tool Calls.

Das ist der Base Thread. Jedes Mal, wenn du Claude Code startest und einen Prompt ausführst, hast du einen Thread gestartet. Der Agent führt Tool Calls aus (liest Dateien, schreibt Code, führt Befehle aus), und wenn er stoppt, prüfst du das Ergebnis.

Einfache Idee. Große Konsequenzen.

Die Kernerkenntnis: Tool Calls sind ungefähr gleich Wirkung (vorausgesetzt, der Prompt war es wert, ausgeführt zu werden).

Vor 2023 warst du die Tool Calls. Du hast Code bearbeitet. Du hast Dateien geöffnet. Du hast Befehle ausgeführt. Die gesamte Kette war manuell.

Heute erscheinst du am Anfang (Prompt) und am Ende (Review). Die Mitte läuft von selbst.

Wer mehr nützliche Tool Calls ausführt, gewinnt gegen denjenigen, der weniger ausführt. Das ist das neue Scoreboard.

Sobald der Base Thread Sinn macht, folgt das Skalieren. Sechs Muster decken fast jeden KI-gestützten Workflow ab.

1. Base Thread

Das Fundament. Ein Prompt, Agenten-Arbeit, ein Review.

Jedes der folgenden Muster baut darauf auf. Ein wackeliger Base Thread bedeutet, dass nichts Höheres funktioniert.

Einsatz für. Einfache Aufgaben, schnelle Fixes, Änderungen an einzelnen Dateien.

2. P-Threads (Parallele Ausführung)

Mehrere Threads laufen gleichzeitig.

Boris Cherny, der Claude Code erschaffen hat, hält fünf Claude Code Instanzen in seinem Terminal offen, nummeriert 1 bis 5. Dazu laufen noch 5 bis 10 weitere im Claude Code Web-Interface.

Sagen wir 10 bis 15 parallele Threads. Ein Agent liefert Auth, ein anderer arbeitet an API-Endpunkten, ein dritter schreibt Tests. Du promptest, wechselst den Tab, promptest, wechselst den Tab, promptest. Dann gehst du zurück zum Review.

Einsatz für. Unabhängige Aufgaben, Code-Reviews, Feature-Branches, Recherche.

Wie du dich verbesserst. Öffne mehr Terminal-Fenster. Schiebe Background-Agenten ins Claude Code Web-Interface. Forke Terminals mit benutzerdefiniertem Tooling.

3. C-Threads (Verkettete Workloads)

Mehrstufige Arbeit mit menschlichen Checkpoints zwischen den Phasen.

Manchmal passt die Arbeit nicht in ein Kontextfenster. Oder die Einsätze sind hoch genug, dass du bei jedem Schritt hinschauen möchtest, bevor der nächste startet.

C-Threads teilen die Arbeit in Phasen auf:

• Phase 1: Datenbank-Migration
• Phase 2: API-Updates
• Phase 3: Frontend-Änderungen

Du reviewst zwischen den Phasen. Alles Kaputte wird früh erkannt, bevor es zu einem riesigen Rollback eskaliert.

Einsatz für. Production Deploys, große Refactors, sensible Migrationen, mehrstufige Workflows.

Trade-off. Deine Aufmerksamkeit. C-Threads kosten mehr menschliche Zeit. Setze sie ein, wenn das Risiko es rechtfertigt.

Das ask user question Tool in Claude Code unterstützt C-Threads von Haus aus. Ein Agent kann mitten im Workflow pausieren und dich etwas fragen, bevor er zur nächsten Phase übergeht.

4. F-Threads (Fusion)

Ein Prompt, viele Agenten, dann nimmst du die besten Ergebnisse zusammen.

Denk an "bestes von N" über ganze Workflows. Feuere denselben Prompt auf vier Agenten. Schau dir alle vier Outputs an. Nimm den Gewinner. Oder nähe die stärksten Teile aus mehreren Outputs zu etwas zusammen, das besser ist als jeder einzelne.

Warum es funktioniert. Mehr Versuche erhöhen die Erfolgschancen. Ein Agent könnte scheitern, während ein anderer es trifft. Vier Blickwinkel schlagen einen.

Einsatz für. Rapid Prototyping, Recherchefragen, Architektur-Entscheidungen, Code-Reviews, bei denen Vertrauen wichtig ist.

Die Zukunft des Prototypings. F-Threads werden das Rapid Prototyping dominieren. Starte mehrere Agenten, gib ihnen dasselbe Problem, fuse ihre Outputs. Mehr Compute kauft mehr Vertrauen.

5. B-Threads (Big/Meta)

Ein Thread, der andere Threads in sich enthält.

Hier wird es meta. Prompts feuern andere Prompts ab. Sub-Agenten spinnen weitere Sub-Agenten auf. Ein Orchestrator-Agent führt einen Planer, dann einen Builder, dann einen Reviewer aus.

Vom Engineer-Platz aus promptest du nur am Anfang und reviewst am Ende. Darunter laufen mehrere Threads von selbst.

Das klarste Beispiel. Sub-Agenten. Sag Claude Code, "verwende Sub-Agenten, um diese drei Aufgaben zu erledigen", und es spawnt drei Threads in sich selbst. Ein Prompt von dir, drei laufende Threads.

Einsatz für. Komplexe Änderungen über mehrere Dateien, Team-of-Agents-Workflows, orchestrierte Builds.

Das Muster. Agenten schreiben Prompts für dich. Der Orchestrator schreibt Prompts für Worker-Agenten. Der Output steigt um das 10-fache, ohne dass der Aufwand um das 10-fache steigt.

6. L-Threads (Lange Laufzeit)

Ausgedehnte Autonomie ohne Menschen in der Schleife.

Der Base Thread, bis an seine Grenzen gedehnt. Nicht 10 Tool Calls. Probier 100. Nicht 5 Minuten. Probier 5 Stunden. Boris hat Threads über 26 Stunden laufen lassen.

L-Threads brauchen:

• Starke Prompts (gute Planung gleich gutes Prompten)
• Solide Verifikation (damit der Agent erkennt, wann er fertig ist)
• Checkpoint-State (damit die Arbeit Kontext-Limits überlebt)

Der Link zu Ralph. Die Ralph-Wiggum-Technik ist um L-Threads herum gebaut. Ein Stop Hook hält den Agenten in der Schleife, bis die Arbeit wirklich erledigt ist. Keine vorzeitigen Exits. Kein Hände-halten.

Einsatz für. Overnight Feature Builds, große Codebasen, Backlog-Abbau.

Ein weiterer Thread-Typ zeigt, wohin das Engineering steuert.

Z-Threads. Zero-Touch-Threads. Volles Vertrauen in deine Agenten. Kein Review-Knoten mehr.

Das ist kein Vibe Coding. Das ist agentenbasiertes Engineering mit so viel Verifikation und so vielen Guardrails, dass das Reviewen des Outputs wirklich optional ist.

Der Agent deployt in Production. Beobachtet Analytics. Entscheidet, ob die Änderung gelandet ist. Iteriert.

Die meisten Engineers sind noch nicht dort. Aber alles zeigt in diese Richtung. Das Ziel: Systeme, die zuverlässig genug sind, dass Review aufhört, erforderlich zu sein.

Jedes Thread-Muster kommt auf vier Grundlagen zurück:

1. Context. Was der Agent weiß
2. Model. Welches Modell läuft
3. Prompt. Was du anforderst
4. Tools. Was der Agent anfassen kann

Bring die vier in Ordnung und du bekommst Agenten. Jede Thread-Optimierung landet bei einem von ihnen.

• Bessere Prompts bedeuten längere Threads
• Besserer Context bedeutet genauere Arbeit
• Bessere Tools bedeuten mehr Fähigkeiten
• Bessere Modelle bedeuten höhere Zuverlässigkeit

Besonders für L-Threads trägt der Stop Hook das Gewicht.

Wenn dein Agent versucht zu stoppen, fängt der Stop Hook ab:

1. Agent versucht abzuschließen
2. Stop Hook führt Validierungscode aus
3. Entscheidung: Ist die Aufgabe wirklich abgeschlossen?
4. Wenn nein: Stop blockieren, weiter iterieren
5. Wenn ja: Abschluss erlauben

Das ist der technische Kern von Ralph-Schleifen. Der Stop Hook lässt den Agenten nicht aufhören, wenn er denkt, er sei fertig. Er lässt den Agenten aufhören, wenn die Arbeit verifiziert ist.

Thread-basiertes Engineering gibt dir etwas, das du wirklich messen kannst.

1. Mehr Threads laufen lassen (P-Threads)

Kannst du mehr parallele Agenten hinzufügen? Boris ist bei 10 bis 15. Kannst du 5 erreichen? Kannst du 3 erreichen?

Messen. Gleichzeitig laufende Threads.

2. Längere Threads laufen lassen (L-Threads)

Können Threads weiter in Tool Calls gehen, bevor du eingreifen musst?

Messen. Durchschnittliche Tool Calls pro Thread vor der Intervention.

3. Dickere Threads laufen lassen (B-Threads)

Können Threads in Threads sitzen? Kann ein Prompt in fünf Sub-Agenten auffächern?

Messen. Arbeit pro Prompt, den du schreibst.

4. Weniger Checkpoints laufen lassen

Kannst du die Anzahl menschlicher Reviews reduzieren? Verdient deine Verifikation genug Vertrauen, um sie zu überspringen?

Messen. Phasen, die vor einer manuellen Prüfung laufen.

Verbesserung in einer dieser vier Dimensionen ist echte Verbesserung als agentischer Engineer. Das ist die Metrik. So weißt du es.

So sieht das an einem echten Tag aus:

Montag morgen. Fünf Features zu liefern.

Alter Weg. Feature 1. Fertig. Feature 2. Fertig. Wiederholen. Fünf sequentielle Sessions.

Thread-basierter Weg:

1. Specs für alle fünf Features schreiben (Planungsphase)
2. Fünf parallele Claude Code Instanzen starten (P-Threads)
3. Jeder Instanz ein Feature übergeben
4. Die ersten fertigen Ergebnisse reviewen, während der Rest noch läuft
5. Einige Features brauchen phasenweise Durchführung (C-Threads)
6. Das kniffligste spawnt Sub-Agenten (B-Thread)
7. Die Overnight-Aufgabe läuft als L-Thread mit Ralph-Schleife

Dieselben fünf Features. Außer dass du jetzt mehr Threads, dickere Threads und längere Threads fährst.

Thread-basiertes Engineering und Ralph-Schleifen passen zusammen.

Ralph beantwortet die Frage: Wie halte ich einen Agenten zuverlässig am Laufen, bis er wirklich fertig ist?

Thread-basiertes Engineering beantwortet: Wie skaliere ich die Agentennutzung und messe, dass ich besser werde?

Ralph liefert L-Threads. Thread-basiertes Engineering sagt dir, wann L-Threads P-Threads schlagen und wann B-Threads der richtige Ansatz sind.

Der Stop Hook hinter Ralph ist derselbe Stop Hook, der L-Threads am Leben hält. Verification-first Development ist das, was beide Muster zum Funktionieren bringt.

Die Engineers, die vorankommen, "nutzen KI" nicht nur. Sie denken in Threads.

Jede Aufgabe beginnt mit einer Frage: Was für ein Thread ist das? Parallelisieren? Verketten? Sub-Threads darin verschachteln?

Der Engpass verschiebt sich. Früher war er "wie schnell kann ich coden?" Jetzt ist er "wie viele nützliche Threads kann ich laufen lassen?"

Skaliere dein Compute. Skaliere deine Wirkung.

Klein anfangen:

1. Deine Arbeit prüfen. Wie viele Threads fährst du gerade? (Für die meisten Engineers: 1.)

2. Einen P-Thread hinzufügen. Öffne ein zweites Terminal. Führe eine parallele Aufgabe aus, während der erste Agent noch läuft.

3. Deine Threads timen. Zähle Tool Calls, bevor du eingreifst. Verfolge diese Zahl.

4. Einen C-Thread ausprobieren. Teile eine große Aufgabe in explizite Phasen auf. Review zwischen den Phasen.

5. Auf L-Threads hinarbeiten. Verifikation aufsetzen. Einen Agenten 30 Minuten unbeaufsichtigt laufen lassen.

Es geht nicht darum, morgen 15 parallele Z-Threads zu erreichen. Es geht um stetigen, messbaren Fortschritt. Mehr Threads. Längere Threads. Dickere Threads. Weniger Checkpoints.

Das ist der einzige echte Weg zu wissen, dass du dich verbesserst. Nicht fühlen. Zählen.

• Ralph-Wiggum-Schleifen für L-Thread-Autonomie hinzufügen
• Asynchrone Workflows für parallele Agenten aufgreifen
• Sub-Agenten-Design für B-Thread-Architekturen studieren
• Feedback-Schleifen für Verifikationsmuster aufbauen

Thread-basiertes Engineering verwandelt KI-Coding von einem Handwerk in eine messbare Praxis. Du kannst es verfolgen. Du kannst es verbessern. Du kannst es skalieren.

Fang an, deine Threads zu zählen.