Ende November des vergangenen Jahres war ich drei Wochen in einen WooCommerce-Build für einen Großkundenkunden eingestiegen. Knapp dreißig Custom Post Types, eine maßgeschneiderte Pricing Engine und ein Checkout-Flow mit mehr bedingter Logik, als mir lieb ist. Ich war der einzige Entwickler darauf. Und ich verlor täglich Zeit beim Kontextwechsel zwischen dem Plugin-Layer, den Theme-Overrides und den REST API Endpoints.
Damals habe ich mich richtig auf die parallele Ausführung von Claude Code Subagents festgelegt. Nicht nur herumprobiert. Tatsächlich umgestellt, wie ich Arbeiten aufteile, damit mehrere Agenten gleichzeitig voranschreiten können, ohne sich gegenseitig zu behindern.
Hier ist, was ich gelernt habe, einschließlich wo ich es anfangs falsch gemacht habe.
---
Was „Subagents" in Claude Code wirklich bedeutet
Die Leute verwenden das Wort locker. Im agentatischen Framework von Claude ist ein Subagent einfach eine Claude-Instanz, die eine begrenzte Aufgabe von einem Orchestrator erhält, diese ausführt und das Ergebnis zurückgibt. Der Orchestrator (der selbst eine Claude-Sitzung sein kann) entscheidet, wie die Arbeiten aufgeteilt werden, welche Subagents gestartet werden und wie die Ergebnisse kombiniert werden.
In der Praxis bedeutet dies für die meisten von uns, die Websites und Anwendungen bauen, mehrere Terminal-Sitzungen zu betreiben, jede mit einem fokussierten Claude Code Kontext, gegen denselben Codebase. Manchmal ist die Orchestrierung über ein Skript automatisiert. Oft bin ich ehrlich gesagt einfach dabei, manuell zu koordinieren, woran jeder Agent aus einem Planungsdokument in Notion arbeitet.
Der Unterschied zwischen sequentiell und parallel
Sequentielles agentatisches Arbeiten ist das, auf das die meisten Entwickler zurückgreifen: Frag Claude, Aufgabe A zu machen, warte, dann frag es, Aufgabe B zu machen. Bei einfachen Sachen in Ordnung. Aber wenn A und B nicht voneinander abhängen, verschwendest du Zeit.
Parallele Subagents laufen gleichzeitig auf unabhängigen Workstreams. Das WooCommerce-Projekt, das ich erwähnt habe: Ich hatte einen Agenten, der die Pricing-Engine-Logik umgestaltete, während ein anderer PHPDoc-Kommentare über die REST API Controller generierte. Null Überschneidung. Beide fertig ungefähr in der Zeit, die es gebraucht hätte, eine zu machen.
---
Wie ich die Arbeitsaufteilung tatsächlich strukturiere
Das ist der Teil, über den niemand klar genug spricht. Das Agent-Setup ist die einfache Sache. Die schwierige Sache ist herauszufinden, was man aufteilt.
Ich verwende eine einfache Regel, die ich nach einem schmerzhaften Merge-Konflikt-Vorfall 2022 entwickelt habe: Keine zwei Agenten dürfen in derselben Sitzung dieselbe Datei berühren. Punkt. Wenn ich das nicht garantieren kann, laufen die Aufgaben nicht parallel.
Mein Planungsschritt vor jedem parallelen Lauf
Bevor ich etwas starte, schreibe ich ein kurzes Task-Manifest. Nichts Ausgefallenes, nur eine Klartext-Datei oder eine Notion-Seite mit:
- Aufgabenname und eine Ein-Satz-Beschreibung
- Dateien im Umfang (explizite Liste)
- Dateien außerhalb des Umfangs (alles Angrenzende, das einen Agenten zum Wandern verleiten könnte)
- Erwartetes Ausgabeformat
- Jeder Kontext, den der Agent benötigt und nicht in der Codebasis vorhanden ist
Das kostet mich vielleicht 15 Minuten. Es hat mich vor einer wirklich peinlichen Anzahl von Konflikten bewahrt.
---
Die drei Workstream-Typen, die ich am häufigsten aufteile
Bei über 12.000+ Site-Builds bei Seahawk und meiner eigenen Kundennarbeit nebenher habe ich bemerkt, dass sich die gleichen Kategorien wiederholt als gute Kandidaten für Parallelisierung eignen.
1. Dokumentation und Code-Generierung
Ein Agent schreibt oder refaktoriert Code. Ein anderer schreibt Dokumentation, Tests oder Kommentare für ein anderes Modul. Diese kollidieren fast nie und beide sind echte Plackerei, wenn man sie manuell macht. Im WooCommerce-Wholesale-Projekt hatte ich einen Subagent, der PHPUnit-Test-Stubs für die Pricing-Funktionen generierte, während ein anderer die benutzerdefinierten Admin-Spalten aufbaute. Die Test-Stubs dauerten etwa vier Minuten. Die Admin-Spalten dauerten zwölf. Ich verlor keine dieser vier Minuten mit Warten.
2. Frontend- und Backend-Isolation
Wenn sich dein Frontend und Backend in klar getrennten Verzeichnissen befinden (was sie sollten, aber das ist ein anderes Thema), ist das eine natürliche Aufteilung. Ich hatte einen Subagent, der React-Komponenten in /resources/js aufbaute, während ein anderer Laravel-Controller in /app/Http verkabelte. Der einzige Koordinationspunkt war, sich auf den API-Vertrag zu einigen, bevor einer der Agenten anfing. Ich habe das in einer AGENTS.md-Datei im Projektstamm geschrieben. Beide Agenten bezogen sich darauf.
3. Modul-für-Modul-Refactoring
Große Refactors sind eine Qual, wenn sie sequenziell durchgeführt werden. Wenn du beispielsweise acht Feature-Module hast, die jeweils dieselbe Art von Änderung benötigen (eine veraltete Methode aktualisieren, zu einem neuen Helper migrieren, was auch immer), verteile sie auf Agenten. Ich hatte einmal vier gleichzeitige Agenten, die ein Legacy-Plugin von WP_Query-Schleifen zu einem Repository-Pattern migrierten. Jeder Agent bekam zwei Module. Erledigt in unter einer Stunde. Sequenziell wäre das ein halber Tag gewesen.
---
Tooling-Setup: Was ich tatsächlich verwende
Ich werde nicht so tun, als hätte ich eine aufwendige Infrastruktur. Mein tatsächliches Setup ist:
- Claude Code läuft in mehreren
tmux-Panes auf einem einzelnen MacBook Pro M3 - Eine freigegebene
AGENTS.md-Datei im Projektstamm, die Konventionen, Dateieigentümer und den API-Vertrag zwischen Workstreams definiert - Git-Branches pro Agent. Immer. Auch wenn der Branch nur zwanzig Minuten existiert
- Ein schneller
git diff --statvor jedem Merge, um Überraschungen zu erfassen
Die AGENTS.md-Datei ist wahrscheinlich das einzeln nützlichste, das ich in meinem Workflow im letzten Jahr hinzugefügt habe. Es ist eine einfache Markdown-Datei, die jedem Agent (oder Mensch, falls relevant) sagt, was die Projektkonventionen sind, welche Dateien zu welchem Workstream gehören und was zu vermeiden ist. Denk daran wie an eine CONTRIBUTING.md, aber für AI-Kontextfenster geschrieben.
Zum Kontextfenster-Management
Hier werden die Leute faul und verwirrt. Jeder Subagent hat seinen eigenen Kontext. Das bedeutet, wenn Agent B wissen muss, was Agent A entschieden hat, musst du es ihm explizit sagen. Er wird es nicht einfach wissen.
Ich handle das mit einer SESSION_LOG.md, die ich manuell aktualisiere, nachdem jeder Agent einen Block fertig gestellt hat. Es sind maximal drei bis fünf Stichpunkte: was wurde getan, was hat sich geändert, was muss der nächste Agent wissen. Der Overhead ist gering. Die Alternative ist, dass ein Agent Annahmen macht, die deinen Code brechen, und dieser Overhead ist viel höher.
---
Wo es schiefgeht (aus schmerzhafter Erfahrung)
Seahawk hatte letztes Frühjahr ein Fintech-Dashboard-Projekt, bei dem wir Subagenten über ein Monorepo ohne ordnungsgemäß definierte Dateieigentümer laufen ließen. Zwei Agenten beschlossen beide, die freigegebene Datei utils/formatters.ts zu aktualisieren. Keiner wusste vom anderen. Das resultierende Merge war technisch in Ordnung, aber wir verbrachten 40 Minuten damit, die Absicht zu reconciliieren. Völlig vermeidbar.
Die Ausfallmodi, die ich wiederholt sehe:
- Gemeinsame Utility-Dateien. Das ist eine Falle. Sperren Sie sie ab. Wenn ein Subagent eine gemeinsame Utility aktualisieren muss, sollte diese Aufgabe allein laufen, nicht parallel.
- Vage Aufgabenbeschreibungen. Ein Agent, dem man "räumen Sie das Auth-Modul auf" gibt, wird das je nach Kontext sehr unterschiedlich interpretieren. Seien Sie spezifisch. "Refaktorieren Sie AuthController.php, um die bereits in
app/Repositories/UserRepository.phpdefinierte UserRepository-Schnittstelle zu verwenden. Ändern Sie die Schnittstelle selbst nicht." Das ist ein sicherer Prompt. - Keine Branch-Isolation. Alle Agenten auf
mainlaufen zu lassen ist der Weg zu aufregenden Freitagmittagen. Branches kosten nichts. - Das Manifest überspringen. Ich weiß, ich weiß. Es fühlt sich wie Overhead an. Machen Sie es trotzdem. Jedes Mal, wenn ich es übersprungen habe, habe ich es innerhalb einer Stunde bereut.
---
Ein echter paralleler Durchlauf, Schritt für Schritt
So sah die Sitzung ungefähr letzte Dienstag für ein Shopify-zu-WooCommerce-Migrationsprojekt aus (anonymisiert, aber die Struktur ist exakt).
- Ich schrieb das Task-Manifest in Notion. Vier als parallelisierbar identifizierte Aufgaben.
- Erstellte vier Git-Branches: agent/product-import, agent/tax-logic, agent/rest-endpoints,
agent/admin-ui. - Öffnete vier
tmux-Panes, je eine Claude Code-Sitzung. - Pachtete den relevanten Abschnitt von
AGENTS.mdam Anfang jeder Sitzung als Kontext ein. - Gab jedem Agent seinen Task-Prompt mit Verweis auf spezifische Dateien.
- Ließ alle vier gleichzeitig laufen. Machte einen Kaffee. Trank ihn tatsächlich, während er noch heiß war, was sich wie ein Wunder anfühlte.
- Überprüfte jede Branch-Ausgabe. Lief
phpcsauf dem PHP,eslintauf alle berührten JS-Dateien. - Mergte der Reihe nach: Product Import zuerst (die anderen hatten leichte Abhängigkeiten von seinem Schema), dann Tax-Logik, dann REST-Endpoints, dann Admin-UI.
- Aktualisierte
SESSION_LOG.mdmit den Änderungen.
Gesamtzeit für alle vier Aufgaben zusammen: etwa 35 Minuten. Meine Schätzung für sequenzielle Fertigstellung war 90 Minuten bis 2 Stunden. Das nehme ich.
---
Was dies ersetzt (und nicht ersetzt)
Parallele Subagenten sind kein Ersatz für Denken. Dieser 15-Minuten-Planungsschritt ist wirklich Sie, die die Architekturarbeit tun. Die Agenten führen aus. Sie müssen immer noch wissen, was zu bauen ist, wie die Teile zusammenpassen und ob die Ausgabe wirklich korrekt ist.
Ich überprüfe jede Agent-Ausgabe, bevor sie main berührt. Jedes einzelne Mal. Ich habe einen Subagenten dabei erwischt, der selbstbewusst einen Caching-Layer schrieb, der zu veralteten Datenproblemen bei einem Multisite-Setup geführt hätte. Der Code sah gut aus. Er war logisch falsch für den spezifischen Kontext. Nur erwischt, weil ich ihn gelesen habe.
Die eigene Orientierung von Anthropic zu agentic-Aufgaben hebt besonders die Bedeutung von menschlichen Checkpoints vor irreversiblen Aktionen hervor. Das ist keine Unternehmensphrasendrescher. Es ist tatsächlich wichtiger Rat, besonders wenn Agenten Schreibzugriff auf Datenbanken haben oder Migrationen durchführen.
Das andere, das dies nicht ersetzt: Kommunikation mit Clients. Ein Agent kann ein Feature bauen. Er kann einem Client nicht sagen, warum eine Frist verschoben wurde oder Erwartungen rund um Scope Creep verwalten. Das ist immer noch Ihre Aufgabe.
---
FAQ
Brauche ich speziellen API-Zugriff oder Werkzeuge, um Claude Code-Subagenten auszuführen?
Keine exotische Einrichtung erforderlich. Claude Code ist das Terminal-basierte Coding-Tool von Anthropic, und Sie können mehrere Instanzen in separaten Terminalsitzungen ausführen (ich verwende tmux). Sie brauchen einen Claude-API-Schlüssel mit ausreichend hohen Ratenlimits, wenn Sie direkt die API treffen. Bei schweren parallelen Workloads überprüfen Sie Ihre Rate-Limit-Stufe, bevor Sie anfangen, damit Sie nicht mid-session gedrosselt werden.
Wie verhindere ich, dass Agenten bei gemeinsamen Dateien in Konflikt geraten?
Definiere Dateieigentümer, bevor du startest. Die AGENTS.md-Konvention, die ich beschrieben habe, funktioniert gut. Wenn zwei Aufgaben dieselbe Utility-Datei ändern müssen, parallelisiere diese beiden Aufgaben nicht. Führe die Änderung der gemeinsamen Utility zuerst aus, committe sie, dann starte die anderen Aufgaben parallel von dieser sauberen Basis aus.
Ist das nur bei großen Projekten sinnvoll?
Ehrlich gesagt nein. Ich habe es bei Single-Page-Sites eingesetzt, bei denen ich Dokumentation zusammen mit neuem Feature-Code generiert haben wollte. Der Overhead der Planung ist niedrig genug, dass selbst bescheidene Zeiteinsparungen es rechtfertigen. Allerdings: Hat ein Projekt weniger als vielleicht fünf unterschiedliche parallelisierbare Aufgaben, beginnt die Setup-Zeit den Nutzen zu überwiegen. Nutze dein Urteilsvermögen.
Was passiert, wenn ein Agent schlechte Ausgabe produziert?
Du erkennst es in der Review, verwirfst den Branch und versuchst es erneut mit einem präziseren Prompt. Das ist der ganze Sinn der Branch-Isolation. Schlechte Agent-Ausgabe kostet dich die Zeit zum Überprüfen und erneuten Prompting. Sie sollte dir keine kaputte Codebase kosten, wenn du die Branch-pro-Agent-Regel befolgst.
Kann ich die Orchestrierung automatisieren, anstatt sie manuell zu machen?
Ja, und bei wiederkehrenden Workflows lohnt sich das. Ich habe simple Bash-Skripte geschrieben, die sequenzielle Claude Code-Aufrufe mit vordefinierten Prompts und Kontext starten. Für vollständig automatisierte parallele Orchestrierung würdest du eine Orchestrator-Schicht bauen, die programmatisch Agenten spawnt, Ausgabe sammelt und Abhängigkeiten handhabt. Das ist eine größere Engineering-Investition. Für die meisten Freelancer und kleine Agenturen reicht manuelle Koordination mit tmux und einem Task-Manifest vollkommen.
---
Die ehrliche Wahrheit ist: Parallele Sub-Agenten haben mich nicht zu einem dramatisch besseren Entwickler gemacht. Sie haben mich schneller gemacht – bei der speziellen Klasse von Aufgaben, bei denen der Engpass die Ausführung war und nicht das Denken. Das Denken kommt immer noch von mir. Architektur-Entscheidungen, Kundengespräche, Code-Review. Alles immer noch von mir.
Aber die nervige Ausführungsarbeit? Ich nehme mir jeden Moment zurück, den ich kriegen kann.