Subagents effektiv einsetzen

Wann Subagents glänzen

Subagents funktionieren am besten, wenn die Exploration von der Ausführung getrennt ist. Wenn jeder Schritt einer Aufgabe davon abhängt, was der vorherige Schritt entdeckt hat, willst du diese Arbeit in deinem Hauptthread haben. Aber wenn du nur eine Antwort brauchst und dich nicht für den Weg dorthin interessierst, delegiere sie.

Subagents glänzen bei Aufgaben, bei denen:

• Du ein Ergebnis brauchst, nicht eine Schritt-für-Schritt-Beschreibung, wie es gefunden wurde
• Die explorative Arbeit den Kontext deines Hauptthreads überladen würde
• Die Aufgabe von einer frischen Perspektive oder einem benutzerdefinierten System-Prompt profitiert

Recherche-Aufgaben

Recherche ist der klassische Anwendungsfall für Subagents. 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 jede Datei sehen, die dabei durchsucht wurde.

Ein Recherche-Subagent kann Dutzende von Dateien lesen, Funktionsaufrufe nachverfolgen und verschiedene Codepfade erkunden. Die gesamte Exploration bleibt im Kontext des Subagents. Dein Hauptthread erhält eine saubere Zusammenfassung wie:

JWT validation happens in middleware/auth.js line 42,
called from the Express router in route/api.js

Der Subagent hat die Schwerstarbeit geleistet. Dein Hauptthread bekommt genau das, was er braucht, um weiterzumachen.

Code-Reviews

Claude überprüft Code effektiver, wenn der Code so präsentiert wird, als wäre er von jemand anderem verfasst worden. Wenn du ein Feature über viele Turns hinweg mit deinem Hauptthread gebaut hast, liefert es oft schwaches Feedback, wenn du denselben Thread bittest, es zu überprüfen. Claude war an der Erstellung beteiligt, daher fällt es ihm schwer, es mit frischen Augen zu betrachten.

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 Historie zu kennen, wie der Code geschrieben wurde. Diese Trennung erlaubt es dir außerdem, projektspezifische Review-Standards im System-Prompt des Subagents zu hinterlegen, was konsistente Review-Kriterien im gesamten Team sicherstellt.

Benutzerdefinierte System-Prompts

Der Standard-System-Prompt von Claude Code legt den Schwerpunkt auf prägnante, codefokussierte Antworten. Das funktioniert hervorragend fürs Coding, aber nicht für alles.

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

• Copywriting-Subagent -- Gib ihm Anweisungen zu Tonfall, Zielgruppe und Stil. Der Standard-Prompt von Claude Code tendiert zu prägnantem technischem Schreiben, was wirklich nicht das ist, was du für eine Landingpage oder eine E-Mail-Kampagne willst. Ein Copywriting-Subagent kann völlig andere Anweisungen zu Stimme und Struktur haben.
• Styling-Subagent -- Sag ihm in seinem System-Prompt, dass er zuerst deine Design-System-Dateien lesen soll, damit er deine Farbvariablen, Abstandskonventionen und Komponentenmuster kennt, bevor er mit dem Schreiben von CSS beginnt.

Wann Subagents schaden

Der Overhead beim Starten eines Subagents -- seine Arbeit vor dem Hauptthread zu verbergen und seine Erkenntnisse zu einer Zusammenfassung zu komprimieren -- ergibt nur dann Sinn, wenn der Subagent etwas tut, das der Hauptthread nicht kann. Es gibt drei häufige Anti-Patterns, auf die du achten solltest.

Experten-Behauptungen

Subagents, 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 besitzt. Es gibt nichts, was ein sogenannter Experten-Subagent tun kann, das dein Hauptthread nicht direkt tun könnte.

Sequenzielle Pipelines

Sequenzielle Subagent-Pipelines verursachen Probleme. Stell dir einen Drei-Agenten-Ablauf vor: einer, um einen Bug zu reproduzieren, einer, um ihn zu debuggen, und einer, um ihn zu beheben. Pipelines funktionieren, wenn Aufgaben wirklich unabhängig sind. Sie scheitern, wenn jeder Schritt von Entdeckungen des vorherigen Schritts abhängt -- und das ist bei der Fehlerbehebung fast immer der Fall. Informationen gehen bei der Übergabe zwischen Agenten verloren.

Test-Runner

Test-Runner-Subagents neigen dazu, Informationen zu verbergen, die du brauchst. Wenn Tests fehlschlagen, willst du die vollständige Ausgabe, um Probleme zu diagnostizieren. Ein Subagent, der „Tests fehlgeschlagen" zurückgibt, zwingt dich dazu, 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 von allen Konfigurationen am schlechtesten abschnitt.

Die Entscheidungsregel

Wenn du entscheidest, ob du einen Subagent einsetzen sollst, stelle dir eine Frage: Ist die Zwischenarbeit von Bedeutung?

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

Verwende Subagents für:

• Recherche und Exploration
• Code-Reviews
• Aufgaben, die einen benutzerdefinierten System-Prompt benötigen

Vermeide Subagents für:

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