Wenn Subagenten glänzen

Du weißt, wie man Subagenten erstellt und gut gestaltet. Jetzt stellt sich die Frage: Wann helfen sie wirklich, und wann stehen sie im Weg? Der Unterschied kommt auf eines an -- ob die Zwischenarbeit für deinen Hauptthread wichtig ist.

Subagenten funktionieren am besten, wenn die Erkundung von der Ausführung getrennt ist. Wenn jeder Schritt einer Aufgabe von dem abhängt, was der vorherige Schritt entdeckt hat, möchtest du diese Arbeit in deinem Hauptthread. Aber wenn du nur eine Antwort brauchst und den Weg nicht interessiert, delegiere es.

Subagenten zeichnen sich bei Aufgaben aus, bei denen:

Du ein Ergebnis brauchst, nicht eine Schritt-für-Schritt-Erklärung, wie es gefunden wurde
Die Explorationsarbeit deinen Hauptthread-Kontext verstopfen würde
Die Aufgabe von einer frischen Perspektive oder einem benutzerdefinierten System Prompt profitiert

Recherche-Aufgaben

Recherche ist der klassische Anwendungsfall für Subagenten. Stell dir vor, du untersuchst, wie Authentifizierung in einer unbekannten Codebasis funktioniert. Dein Hauptthread muss wissen, wo das JWT validiert wird, aber er muss nicht sehen, welche Dateien auf dem Weg durchsucht wurden.

Ein Recherche-Subagent kann Dutzende von Dateien lesen, Funktionsaufrufe verfolgen und verschiedene Code-Pfade erkunden. Die ganze Erkundung bleibt im Kontext des Subagenten. Dein Hauptthread erhält eine saubere Zusammenfassung wie:

JWT-Validierung erfolgt in middleware/auth. js Zeile 42, aufgerufen vom Express-Router in route/api. js

Der Subagent hat die schwere Arbeit geleistet. Dein Hauptthread bekommt genau das, was er braucht, um voranzukommen.

Code Reviews

Claude überprüft Code effektiver, wenn der Code so präsentiert wird, als wäre er von jemand anderem geschrieben. Wenn du ein Feature über viele Turns mit deinem Hauptthread gebaut hast, führt das Bitten an denselben Thread, es zu überprüfen, oft zu schwachem Feedback. Claude war an der Erstellung beteiligt, daher hat es Schwierigkeiten, es mit frischen Augen zu sehen.

Ein Reviewer-Subagent sieht die Änderungen in einem separaten Kontext. Er führt git diff aus, liest die geänderten Dateien und wendet seine spezialisierten Review-Kriterien an, ohne die Geschichte, wie der Code geschrieben wurde. Diese Trennung ermöglicht es dir auch, projektspezifische Review-Standards im System Prompt des Subagenten zu kodifizieren und so konsistente Review-Kriterien im gesamten Team sicherzustellen.

Benutzerdefinierte System Prompts

Der Standard-System Prompt von Claude Code betont prägnante, Code-fokussierte Antworten. Das funktioniert großartig zum Programmieren, aber nicht für alles.

Hier sind zwei Fälle, in denen ein benutzerdefinierter System Prompt den Subagenten wirklich besser macht als den Hauptthread:

Copywriting-Subagent \-- Gib ihm Anweisungen zu Ton, Zielgruppe und Stil. Claude Codes Standard-Prompt neigt zu prägnanter technischer Schreibweise, was wirklich nicht das ist, was du für eine Landing Page oder E-Mail-Kampagne möchtest. Ein Copywriting-Subagent kann völlig andere Anweisungen zur Stimme und Struktur haben.
Styling-Subagent \-- Zeige auf deine Design-System-Dateien. Wenn der Subagent läuft, werden diese Dateien automatisch in seinen Kontext geladen, sodass er deine Farbvariablen, Spacing-Konventionen und Komponenten-Muster kennt, bevor er überhaupt anfängt, CSS zu schreiben.

Wenn Subagenten schaden

Der Overhead beim Starten eines Subagenten -- die Sichtbarkeit seiner Arbeit verlieren und seine Erkenntnisse in eine Zusammenfassung komprimieren -- macht nur Sinn, wenn der Subagent etwas tut, das dein Hauptthread nicht kann. Es gibt drei häufige Anti-Muster, auf die du achten solltest.

Expertise-Ansprüche

Subagenten, die Expertise beanspruchen, helfen selten. Prompts wie „du bist ein Python-Experte" oder „du bist ein Kubernetes-Spezialist" bringen keinen Mehrwert, weil Claude dieses Wissen bereits hat. Es gibt nichts, das ein sogenannter Experten-Subagent tun kann, das dein Hauptthread nicht direkt tun kann.

Sequenzielle Pipelines

Sequenzielle Subagenten-Pipelines schaffen Probleme. Stell dir einen Drei-Agenten-Ablauf vor: einer zum Reproduzieren eines Bugs, einer zum Debuggen und einer zum Beheben. Pipelines funktionieren, wenn Aufgaben wirklich unabhängig sind. Sie scheitern, wenn jeder Schritt von Erkenntnissen aus dem vorherigen Schritt abhängt -- und Bug-Behebung tut das fast immer. Informationen gehen bei der Übergabe zwischen Agenten verloren.

Test Runner

Test-Runner-Subagenten neigen dazu, Informationen zu verbergen, die du brauchst. Wenn Tests fehlschlagen, möchtest du die vollständige Ausgabe, um Probleme zu diagnostizieren. Ein Subagent, der „Tests fehlgeschlagen" zurückgibt, zwingt dich, zusätzliche Debug-Skripte zu erstellen, um Details zu erhalten, die in der direkten Ausgabe sichtbar gewesen wären. Tests haben gezeigt, dass das Test-Runner-Muster unter allen Konfigurationen schlechter abschnitt.

Die Entscheidungsregel

Wenn du entscheidest, ob du einen Subagenten verwenden sollst, stelle dir selbst eine Frage: Ist die Zwischenarbeit wichtig?

Wenn die Antwort nein ist -- du brauchst nur das Endergebnis -- delegiere es an einen Subagenten. Wenn die Antwort ja ist -- du musst sehen und auf das reagieren, was unterwegs passiert -- behalte es in deinem Hauptthread.

Verwende Subagenten für:

Recherche und Erkundung
Code Reviews
Aufgaben, die einen benutzerdefinierten System Prompt benötigen

Vermeide Subagenten für:

„Experten"-Personas, die keine echte Fähigkeit hinzufügen
Multi-Step-Pipelines, bei denen jeder Schritt vom letzten abhängt
Ausführen von Tests, bei denen du die vollständige Ausgabe zum Debuggen brauchst