Claude Code ist zu einem ernsthaften Hebel für die Produktivität von Ingenieurteams geworden. Die Fortschritte in den ersten Wochen sind in der Regel offensichtlich. Weniger offensichtlich ist, was passiert, wenn Ihr Team beginnt, es für längere, ambitioniertere Arbeiten zu nutzen: Refactoring über mehrere Dateien hinweg, große Audits, End-to-End-Feature-Entwicklung. In diesem Maßstab hören die Ausgabequalität und die Kosten auf, sich so zu entwickeln, wie sie es am Anfang taten, und die Gründe dafür sind aus Führungssicht nicht immer leicht zu erkennen.
Die Antwort ist fast nie das Modell selbst. Es ist die Architektur um das Modell herum. Teams, die das 5- bis 10-fache aus Claude Code herausholen, verwenden keine andere Version von Claude. Sie verwenden dieselbe Version mit integrierten Claude-Subagenten, die lange Sitzungen scharf halten, anstatt sie verfallen zu lassen. Dieses Stück ist für die Leute, die entscheiden, wo Ingenieurzeit investiert werden soll: Es befasst sich mit den fünf Engpässen, die die Leistung Ihres Teams leise begrenzen, den Subagenten-Mustern, die jeden einzelnen beheben, und wann Sie zu Claude Code Agent Teams übergehen sollten. Am Ende werden Sie wissen, was Sie Ihren Ingenieurleiter fragen sollen und wie Sie erkennen können, ob Ihre aktuelle Einrichtung bares Geld auf dem Tisch liegen lässt.
Was Claude Subagenten eigentlich sind
Ein Claude Subagent ist eine isolierte Claude Code-Instanz mit seinem eigenen ~200K-Kontextfenster, seinem eigenen System-Prompt, seiner eigenen Tool-Whitelist und seinen eigenen Berechtigungen. Die Hauptsitzung delegiert eine Aufgabe an ihn. Der Subagent erledigt die Arbeit isoliert und gibt dann nur eine Zusammenfassung zurück. Alles Rauschen, das innerhalb des Subagenten geschah, bleibt innerhalb des Subagenten.
Der eigentliche Wert hier ist nicht die Parallelität, obwohl diese hilft. Es ist die Isolation. Wenn ein Subagent vierzig Dateien liest, um ein Muster zu finden, sieht die Hauptsitzung diese vierzig Dateien nie. Sie sieht einen Absatz: „Muster gefunden, es befindet sich hier, sieht so aus.“ Das hält den Hauptthread über eine lange Sitzung hinweg scharf.
Drei Varianten sind wissenswert. Integrierte Subagenten wie Explore und Code werden mit Claude Code geliefert und laufen automatisch. Benutzerdefinierte Subagenten befinden sich in Ihrem Verzeichnis .claude/agents/ und ermöglichen es Ihnen, Spezialisten für Sicherheit, Tests oder Dokumentation zu definieren. Und wenn eine Sitzung die Arbeit wirklich nicht bewältigen kann, ermöglichen Claude Code Agent Teams die Koordination mehrerer Sitzungen mit Nachrichten zwischen ihnen.
Claude Code sitzt in einer breiteren Landschaft von Multi-Agenten-KI-Frameworks wie LangChain, OpenAI’s Agents SDK und Google ADK, die jeweils unterschiedliche Kompromisse bei Orchestrierung, Speicher und Werkzeugzugriff bieten. Subagenten sind Anthropic’s Antwort auf dasselbe Koordinationsproblem, das diese Frameworks zu lösen versuchen, eingebaut direkt in die Claude Code-Laufzeit anstatt als separate Schicht angehängt zu werden.
Die fünf Engpässe, die lange Claude Code-Workflows unterbrechen
Führungskräfte im Ingenieurwesen beschreiben Claude Code-Verlangsamungen normalerweise in vagen Begriffen: „Das Modell wird schlechter“, „Es vergisst Dinge“, „Sitzungen werden teuer“. Dies sind echte Beobachtungen, aber sie sind nicht zufällig. Jede davon entspricht einer spezifischen architektonischen Ursache, wie eine Einzelsitzung im Laufe der Zeit mit Arbeit umgeht, und jede hat ein Subagenten-Muster, das sie löst, ohne ein anderes Modell oder ein anderes Werkzeug zu benötigen.
Die fünf unten genannten Muster decken den Großteil dessen ab, was lange Sitzungen verlangsamt. Zu wissen, welches Ihr Team trifft, ist der Unterschied zwischen dem Übertragen von mehr Tokens auf das Problem und der tatsächlichen Behebung des Workflows.
Kontextverfall (Context Rot) ist der langsame Qualitätsabfall, wenn sich das Kontextfenster füllt. Er tritt lange vor dem harten Token-Limit auf. Je mehr Kontext das Modell hält, desto weniger Gewicht haben Ihre ursprünglichen Anweisungen. Nach drei Stunden ist der architektonische Plan, den Sie zu Beginn festgelegt haben, unter Werkzeugausgaben, Dateiinhalten und vorheriger Argumentation begraben, und das Modell beginnt effektiv, ihn zu ignorieren.
Die Lösung besteht darin, laute Arbeiten an einen Subagenten zu delegieren. Alles, was mehr als fünf Dateien liest, große Unterschiede analysiert oder Protokolle durcharbeitet, geht an einen Explore-Subagenten. Die Hauptsitzung sieht nie die Rohausgabe. Sie sieht die Ergebnisse.
Sie wissen, dass dies funktioniert, wenn Ihre Qualität nach drei Stunden Ihrer Qualität nach einer Stunde entspricht.
Sequentielle Belastung unabhängiger Arbeit
Wenn ein langer Arbeitsablauf alles über eine einzige Hauptsitzung laufen lässt, warten unabhängige Arbeitsstücke aus keinem guten Grund aufeinander. Die Sicherheitsüberprüfung wartet auf Tests, Tests warten auf Dokumente, Dokumente warten auf das Refactoring. Die Arbeit selbst war nie sequentiell. Die Architektur hat sie sequentiell gemacht.
Das Split-and-Merge-Muster löst dies auf. Unabhängige Arbeitsströme werden über parallele Subagenten verteilt und die Ergebnisse kommen an einem Ort zurück. Wo Teams es falsch machen, ist, Subagenten mit generischen Begriffen zu versenden, was zu überlappender Arbeit, Bearbeitungen an denselben Dateien und einem Merge-Chaos am Ende führt. Die Teams, die dies gut machen, geben jedem Subagenten eine benannte Rolle, eine definierte Leistung und klare Grenzen für das, was er berühren kann. Diese Präzision ist das, was parallele Ausführung in tatsächliche Durchsatzrate verwandelt, anstatt dass drei Agenten sich gegenseitig auf die Füße treten.
Domänenübergreifende Kontamination
Kontextverfall betrifft, was im Laufe der Zeit verblasst. Domänenübergreifende Kontamination betrifft, was im Moment konkurriert. Wenn eine Sitzung gebeten wird, Backend-Regeln, Frontend-Regeln und SDK-Konventionen gleichzeitig zu verarbeiten, stören sich diese Regelwerke gegenseitig. Dem Modell geht nicht der Platz aus. Es wird in drei Richtungen gleichzeitig gezogen.
Das sichtbare Versagen: Backend-Muster sickern in React-Komponenten, oder Frontend-Konventionen erscheinen in Datenübertragungsobjekten. Der Code sieht auf den ersten Blick plausibel aus, verstößt aber gegen die von Ihnen für jede Ebene festgelegten Konventionen. Dies ist das Ergebnis der Aufforderung an einen Kontext, gleichzeitig Experte für zu viele Dinge zu sein.
Die Lösung ist ein Subagent pro Domäne. Der Backend-Subagent lädt nur Backend-Anweisungen. Der Frontend-Subagent lädt nur Komponentenmuster. Der Orchestrator koordiniert zwischen ihnen, versucht aber nie, alle Regeln selbst zu halten. Das gleiche Prinzip untermauert die saubere Architektur in der Softwareentwicklung und funktioniert aus demselben Grund: Trennung der Zuständigkeiten verhindert Drift.
Der Vier-Stunden-Kollaps
Der Vier-Stunden-Kollaps tritt ein, wenn einer der Workflow-Schritte fehlschlägt und die gesamte Pipeline ins Stocken gerät, oder wenn der Sitzung auf halbem Weg der Platz ausgeht und der akkumulierte Zustand verloren geht. Die meisten Einzelsitzungs-Workflows sind auf diese Weise fragil, da zwischen den Schritten nichts gespeichert wird.
Die Lösung ist ein strukturierter Explore-, Plan-, Execute-Workflow. Jede Phase ist eine separate Subagenten-Aufrufung mit einer sauberen Übergabe an die nächste. Das menschliche Überprüfungs-Gate sitzt zwischen Plan und Execute, wo die Kosten für die Erkennung eines Fehlers am niedrigsten sind.
Dies ist im großen Maßstab wichtig. Anthropic’s Dynamic Workflows Release vom 28. Mai 2026 zeigte Claude Code, der Codebasis-Migrationen über Hunderte von Tausenden von Zeilen durchführt, wobei die bestehende Testsuite als Validierungsmaßstab dient. Eine Demo migrierte eine Codebasis von 750.000 Zeilen in elf Tagen mit einer Test-Passrate von 99,8%. Läufe dieser Größenordnung überleben nicht ohne strukturierte Übergaben zwischen den Phasen.
Orchestrierungsüberlastung
Die anderen vier Engpässe sitzen auf der Worker-Ebene. Die Orchestrierungsüberlastung tritt auf der Koordinator-Ebene auf, sobald die Worker gut arbeiten. Sie haben parallele Subagenten, die saubere Zusammenfassungen erstellen, aber der übergeordnete Agent ertrinkt nun im Ankommenden-Verkehr: zehn Zusammenfassungen zum Lesen, zehn Sätze von Empfehlungen zur Reconciliierung, zehn Threads, die kohärent bleiben müssen. Der Durchsatz stockt nicht, weil die Worker langsam sind, sondern weil nichts nachgelagert ihre Ausgabe schnell genug synthetisieren kann.
Die Lösung ist Zurückhaltung an der Spitze. Der Orchestrator sollte nur koordinieren und nichts anderes. Die Parallelität sollte der tatsächlichen Aufgabenunabhängigkeit entsprechen, nicht nur der verfügbaren Kapazität. Ein schreibgeschützter Reviewer-Subagent im Verhältnis 1:3 oder 1:4 hilft, die Qualität hoch zu halten, ohne die Merge-Last zu erhöhen. Schreibgeschützt ist wichtig, da ein Reviewer mit Schreibzugriff anfängt, Probleme selbst zu beheben, was zu Konflikten mit den Implementierungs-Subagenten führt. Die gleiche Logik liegt dem zugrunde, wie gute Code-Reviews in einem menschlichen Team funktionieren: Der Reviewer markiert, der Implementierer behebt. Fünf parallele Subagenten sind die praktische Obergrenze für die meisten Teams innerhalb einer Sitzung.
Subagenten vs. Agententeams
Subagenten sind Worker innerhalb einer Claude Code-Sitzung. Claude Code Agent Teams koordinieren sich über mehrere Sitzungen hinweg, jede mit eigenem Kontext, die über Nachrichten zwischen Teammitgliedern kommunizieren. Die Wahl zwischen ihnen ist nicht akademisch. Wenn Sie es falsch machen, verbrennen Sie Geld für Agententeams, wenn Subagenten ausreichen würden, oder Sie dehnen Subagenten über ihre Grenzen hinaus aus, wenn eine Sitzung die Arbeit nicht bewältigen kann.
Verwenden Sie Subagenten, wenn Sie einen Arbeitsablauf haben, der Helfer darunter benötigt. Parallele Erkundung, begrenzte Delegation, isolierte Leseoperationen mit großem Kontext. Verwenden Sie Agententeams, wenn sich die Arbeit selbst über mehrere länger laufende Sitzungen aufteilt, Teammitglieder miteinander sprechen müssen oder der Gesamtkontext das übersteigt, was eine Sitzung realistisch bewältigen kann.
Umfang
Eine Sitzung, begrenzte Delegation
Mehrere Sitzungen koordinieren
Kommunikation
Gibt eine einzelne Zusammenfassung an den Elternteil zurück
Nachrichten zwischen Teammitgliedern
Am besten für
Parallele Erkundung, isolierte Lesevorgänge
Arbeiten über mehrere Tage, getrennte Arbeitsströme
Kostenprofil
Leichter
Schwerer pro Teammitglied
Praktische Teamgröße
Bis zu 10 parallel
3 bis 5 Teammitglieder im Sweet Spot
Die meisten Teams greifen zu Agententeams. Beginnen Sie mit Subagenten. Wechseln Sie nur dann zu Agententeams, wenn eine Sitzung die Arbeit wirklich nicht koordinieren kann.
Die Fehler, die Subagenten zu einer Bürde machen
Subagenten sind mächtig und werden auch leicht missbraucht. Hier sind die Muster, die wir sehen und die die Produktivität eher beeinträchtigen als fördern:
- Übermäßige Delegation einfacher Aufgaben. Ein Lesezugriff auf eine Datei erfordert keinen Subagenten. Der Koordinationsaufwand übersteigt die Einsparungen. Verwenden Sie die Hauptsitzung für alles, was bequem hineinpasst.
- Unter spezifizierte Ausgaben. Vage Dispatch-Prompts erzeugen vage Zusammenfassungen. Geben Sie immer die Form der Leistung an: „Geben Sie eine Markdown-Tabelle mit den Spalten X, Y, Z zurück“ ist besser als „Fassen Sie zusammen, was Sie finden“.
- Falsche Parallelität. Sequentielle Verkettung von Subagenten, wenn die Arbeit keine wirklichen Abhängigkeiten hat. Wenn zwei Subagenten nicht voneinander abhängen, führen Sie sie parallel aus.
- Reviewer mit Schreibzugriff. Vereitelt die Isolation. Ein Reviewer, der bearbeiten kann, wird anfangen, Dinge zu reparieren, was zu Merge-Konflikten führt und die Arbeit, die Ihre anderen Subagenten gerade geleistet haben, zunichte macht.
- Berechtigungs-Sprawl. Jedes zusätzliche Tool erweitert Ihre Angriffsfläche. Unser Artikel über KI-Agenten-Governance beschreibt, warum Berechtigungshygiene wichtiger ist, als die meisten Teams denken, insbesondere nachdem der ClawBank-Zwischenfall die Unternehmens-KI-Sicherheit neu definiert hat.
Wenn Sie diese falsch machen, kosten Subagenten Sie mehr Tokens, mehr Zeit und mehr Nacharbeit, als wenn alles in einer Sitzung gelaufen wäre.
Die minimale Subagenten-Einrichtung, die Bestand hat
Wenn Sie bei Null anfangen, ist hier die kleinste Produktionsumgebung, die eine vierstündige Claude Code-Sitzung ohne Qualitätsverlust übersteht:
- Ein Orchestrator auf Opus. Koordiniert nur. Implementiert nie.
- Ein Explore-Subagent auf Haiku. Liest, fasst zusammen, gibt Ergebnisse zurück. Günstig und schnell.
- Ein Code-Subagent auf Sonnet. Implementiert basierend auf der Explore-Zusammenfassung.
- Ein schreibgeschützter Reviewer auf Opus. Läuft nach jeder abgeschlossenen Aufgabe. Die Ausgabe sind strukturierte Ergebnisse, blockierend und nicht-blockierend.
- Gehen Sie nur dann zu Agententeams über, wenn eine Sitzung die Arbeit wirklich nicht bewältigen kann.
Die Modellaufteilung ist wichtig, da sie die Kosten steuert. Die Analyse von McKinsey zur Produktivitätssteigerung durch KI im Jahr 2026 (McKinsey) verdeutlicht, dass der Wert von KI darin liegt, die Arbeitsorganisation neu zu gestalten, nicht nur bestehende Arbeit schneller auszuführen. Subagenten sind genau eine solche Neugestaltung. Sie hören auf, Claude als ein einziges Modell zu betrachten, das alles tut, und beginnen, es als ein Ingenieurteam zu betrachten.
Diese Einrichtung ist am wichtigsten für Teams, die SaaS-Produkte im großen Maßstab entwickeln, wo eine vierstündige Claude Code-Sitzung keine Seltenheit ist und die Kosten des Kontextverfalls sich über den Release-Zyklus hinweg summieren.
Gleiches Modell, bessere Architektur
Die Teams, die das 10-fache aus Claude Code herausholen, verwenden kein besseres Modell. Sie verwenden dasselbe Modell mit der richtigen Struktur darum herum. Die Engpässe sind vorhersehbar. Die Muster sind dokumentiert. Der Unterschied zwischen Teams, die einen inkrementellen Schub durch Claude erhalten, und Teams, die ihre Auslieferung ändern, liegt darin, ob sie das Werkzeug als einzelnen Agenten oder als Ingenieurteam behandeln.
Bauen Sie die Architektur, bevor Sie sie brauchen, nicht nach dem Vier-Stunden-Kollaps. Wenn Sie Hilfe bei der Zusammenstellung für einen realen Workflow benötigen, kontaktieren Sie uns.
FAQ
Was sind Claude Subagenten?
Subagenten sind isolierte Claude Code-Instanzen, an die die Hauptsitzung Aufgaben delegiert. Jede hat ihr eigenes Kontextfenster, ihre eigenen Werkzeuge und ihre eigenen Anweisungen. Der Subagent erledigt die Arbeit und gibt eine Zusammenfassung zurück. Das laute Mittel bleibt innerhalb des Subagenten, was die Hauptsitzung fokussiert hält.
Warum wird Claude Code im Laufe der Zeit langsamer?
Kontextverfall. Wenn sich das Kontextfenster füllt, haben die frühesten Anweisungen weniger Gewicht, sodass das Modell nach drei Stunden den zu Beginn der Sitzung festgelegten Plan effektiv ignoriert. Subagenten beheben dies, indem sie laute Arbeiten aus der Hauptsitzung heraushalten.
Wie viele Subagenten können parallel laufen?
Bis zu zehn parallel innerhalb einer Claude Code-Sitzung, wobei fünf der praktische Sweet Spot sind, bevor der Koordinator zum Engpass wird. Dynamic Workflows auf Opus 4.8 erhöhen die Obergrenze für sehr große Aufträge erheblich.
Wann sollte ich Claude Code Agent Teams anstelle von Subagenten verwenden?
Wenn sich die Arbeit selbst über mehrere länger laufende Sitzungen aufteilt, wenn Teammitglieder kommunizieren müssen oder wenn der Gesamtkontext das übersteigt, was eine Sitzung bewältigen kann. Für eng definierte Delegationen innerhalb eines Arbeitsstrangs bleiben Sie bei Subagenten.
Was ist der größte Fehler, den Teams mit Subagenten machen?
Überdelegation. Das Senden von Ein-Datei-Lesevorgängen oder trivialen Aufgaben an einen Subagenten kostet mehr an Koordinationsaufwand als es einspart. Verwenden Sie Subagenten für Arbeiten, die ansonsten den Hauptkontext verunreinigen würden.
Sehen Sie, wie Redwerk die Architektur von Sentient Ascend neu aufgebaut hat, um die führende digitale Wachstumsplattform angetrieben von KI zu ermöglichen.
