Parallel arbeiten mit Claude Code: Worktree, Agents und Workflows

Praktische Materialien zur parallelen Arbeit mit Agents: Ailoot-Dokumentation.

Dieser Leitfaden vereint praktische Erfahrung mit einer Übersicht darüber, wo die Tools zum Einsatz kommen. Die vier offiziellen Claude-Code-Primitiven, eine Übersicht zu ihren Einsatzgebieten und ein Anti-Hype-Rahmen dafür, wie viele parallele Agents ein Vibe-Coder tatsächlich braucht. Alle Zahlen und Zitate verweisen auf Primärquellen von Anthropic.

Was ist Multi-Agent in Claude Code, und warum sind es nicht „1000 Agents“?#

Ein Multi-Agent-Setup liegt vor, wenn eine Aufgabe in mehrere unabhängige Arbeitsstränge aufgeteilt wird, von denen jeder seinen eigenen Teil bearbeitet und ein Ergebnis zurückliefert. Das einfachste Beispiel: Du schreibst das Frontend in einem Claude-Code-Fenster und das Backend in einem anderen Fenster auf demselben Rechner, wobei beide auf ein gemeinsames Git-Repository zugreifen. Das ist bereits Multi-Agent, auch wenn „Orchestrierung“ dafür ein unnötig großes Wort wäre.

Ein aufwendigeres Setup: Innerhalb einer Claude-Code-Sitzung startest du fünf Subagents mit unterschiedlichen Rollen (Frontend-Entwickler, Backend-Entwickler, Sicherheitsprüfer, Tester, Dokumentierer), und jeder liefert seinen Teil des Ergebnisses an das gemeinsame Gespräch zurück. Es ist derselbe Multi-Agent-Ansatz, nur mit einer zentralen Steuerung.

Noch aufwendiger: Du sagst Claude: „Führe wöchentlich ein Sicherheitsaudit aller 500 Dateien in meinem Projekt durch“, und Claude schreibt ein JavaScript-Orchestrierungsskript. Die Laufzeit startet im Hintergrund mehrere Dutzend Agents, von denen jeder einen eigenen Abschnitt prüft. Danach kontrollieren unabhängige Agents gegenseitig ihre Ergebnisse, und du erhältst einen Bericht. Das sind Dynamic Workflows, die Anthropic am 28. Mai 2026 veröffentlicht hat. Eine detaillierte Aufschlüsselung der Funktion findest du im separaten Leitfaden zu Dynamic Workflows.

Der Unterschied zwischen diesen drei Szenarien liegt nicht in der Zahl der Agents. Der Unterschied ist: Wer entscheidet, was der nächste Agent tut? Im ersten Szenario bist du das. Im zweiten entscheidet Claude im Verlauf des Gesprächs. Im dritten ist es ein JavaScript-Skript, das Claude geschrieben hat.

„1000 Agents“ ist übrigens eine echte Zahl. Sie bezeichnet die Obergrenze für einen Dynamic Workflow in Claude Code. In der offiziellen Anthropic-Dokumentation heißt es:

Mit anderen Worten: Das ist eine technische Schutzmaßnahme gegen unkontrolliertes Verhalten, keine Empfehlung für den Arbeitsumfang. In der Praxis werden 95 % der Aufgaben mit 2–8 parallelen Arbeitssträngen erledigt. Wenn du mehr planst, frag dich zuerst, was sie tun sollen.

4 Claude-Code-Primitiven: Subagents, Skills, Agent Teams, Workflows#

Claude Code hat vier offizielle Primitiven, um eine Aufgabe auf mehrere Agents aufzuteilen. Anthropic hat sie in einer Vergleichstabelle in der Dokumentation zu Dynamic Workflows zusammengeführt. Hier ist der Vergleich in einfachen Worten:

Jedes dieser Primitiven löst ein anderes Problem. Subagents eignen sich, um 2–3 Prüfungen innerhalb einer Aufgabe zu delegieren. Skills sind sinnvoll, wenn du eine fertige Anweisung hast, der Claude folgen soll (zum Beispiel: „Führe anhand dieser Checkliste eine PR-Prüfung durch“). Agent Teams eignen sich, wenn mehrere Teile eines Produkts in verschiedenen Fenstern liegen und du eine koordinierende Instanz brauchst. Workflows sind für Aufgaben gedacht, die zu groß für ein einzelnes Kontextfenster sind.

Subagents werden ausführlich im Leitfaden Claude Code Subagents 2026 behandelt. Der Entscheidungsbaum für die Frage „Was sollte ich für eine bestimmte Aufgabe verwenden?“ steht im Leitfaden zu Skills, Subagents, MCP und Plugins. In diesem Leitfaden geht es darum, sie mithilfe von Git Worktree zu einem Multi-Agent-Setup zusammenzustellen.

Ebene 1: Subagents in einer Sitzung – der einfachste Einstieg#

Ein Subagent ist die einfachste Möglichkeit, eine Aufgabe aufzuteilen. Das Hauptgespräch übernimmt die Koordination. Subagents sind temporäre Mitarbeiter, die der Hauptagent im Arbeitsverlauf startet.

Ein konkretes Beispiel aus dem beschriebenen Projekt. Nach dem ersten Entwurf eines Leitfadens wird die Überprüfung so aufgesetzt: Claude erhält die Anweisung: „Starte sechs Subagents parallel – einer sucht nach KI-Merkmalen, der zweite nach juristischem Vokabular, der dritte prüft Stimme und Ton, der vierte kontrolliert Fakten mit WebFetch, der fünfte prüft die SEO-Struktur und der sechste die Genauigkeit der Querverweise.“ Jeder liefert einen Bericht, danach werden die Änderungen umgesetzt.

Technisch geschieht das mit Dateien unter .claude/agents/[subagent-name].md, die Rolle und Tools beschreiben. Der Aufruf erfolgt über das Tool Agent im Hauptgespräch. Claude entscheidet, wann es eine Anfrage an einen Subagent sendet.

Wo es funktioniert. Aufgaben mit 3–7 parallelen Prüfungen eines einzelnen Artefakts (Code, Text, Design). Jede Prüfung ist unabhängig. Die Ergebnisse passen in das Hauptkontextfenster.

Wo es an Grenzen stößt. Bei mehr als 50 Dateien oder wenn jede Prüfung ein eigenes Kontextfenster mit 50K Tokens benötigt, füllt sich das Hauptfenster. Dann brauchst du Workflows oder Agent Teams.

Hauptrisiko. Jeder Subagent verbraucht separat Tokens. Wenn du sechs Subagents in einem Projekt mit 200 Dateien startest und jeder alle 200 erneut liest, zahlst du das Sechsfache. Deshalb MUSST du genau angeben, welche Dateien der Subagent prüfen soll. Einzelheiten findest du im Leitfaden dazu, wohin die Tokens in Claude Code fließen.

Ebene 2: Git Worktree – Dateien zwischen parallelen Sitzungen isolieren#

Wenn Subagents nicht ausreichen und du zwei vollwertige Claude-Code-Instanzen in unterschiedlichen Terminals brauchst, die am selben Repository arbeiten, taucht ein klassisches Problem auf. Sie fangen an, dieselbe Datei zu bearbeiten; eine Instanz speichert zuerst, und die zweite überschreibt sie. Ein Kunde fragte das Supportteam letzte Woche: „5 überschreiben sich gleichzeitig.“

Die Lösung ist Git Worktree. Diese integrierte Git-Funktion ermöglicht mehrere Arbeitskopien desselben Repositorys, jeweils auf einem eigenen Branch und mit gemeinsamem .git-Repository. Ein Ursprung, verschiedene Verzeichnisse auf der Festplatte und keine Überschneidungen zwischen den Dateien. Der Mechanismus wird ausführlich im Leitfaden zu Git Worktree in Claude Code beschrieben.

Befehle für eine Einrichtung in fünf Minuten:

# From the main project directory
cd ~/projects/my-app

# Create a worktree for feature/auth
git worktree add ../my-app-auth feature/auth

# Create a worktree for feature/billing
git worktree add ../my-app-billing feature/billing

# Open two terminal windows
cd ~/projects/my-app-auth && claude   # first Claude Code
cd ~/projects/my-app-billing && claude # second Claude Code

Jede Kopie liegt auf einem eigenen Branch. Jede Claude-Code-Instanz schreibt in ihr eigenes Verzeichnis. Wenn die Aufgabe erledigt ist, führe git push von ihrem Branch aus und anschließend git worktree remove ../my-app-auth.

Was du wissen musst. Ein Worktree dupliziert keine node_modules, .venv oder anderen Dateien aus .gitignore. Wenn du unabhängige Abhängigkeiten brauchst (eine andere Bibliotheksversion auf jedem Branch), führe nach worktree add im neuen Verzeichnis separat npm install aus.

Wie viele Worktrees pro Person? Laut Teamumfragen von 2026 liegt die praktische Obergrenze bei 4–8 parallelen Worktrees pro Entwickler. Der begrenzende Faktor ist nicht Claude, sondern die Fähigkeit einer Person, die Ergebnisse zu prüfen und anzunehmen. Bei 10 Worktrees warten die Ergebnisse auf eine Überprüfung.

In der beschriebenen Praxis nutzen die Leute üblicherweise 2–3 parallele Worktrees. Einen primären Worktree für die aktive Arbeit, einen als Reserve für dringende Hotfixes und einen für ein Experiment (eine neue Funktion, bei der du unsicher bist). Mehr sind nicht nötig.

Ebene 3: Agent Teams – mehrere Fenster, ein Lead-Agent#

Agent Teams sind ein relativ neues Primitiv. Die Idee: Ein Lead-Agent hält den gemeinsamen Plan als Aufgabenliste fest, und mehrere Peer-Sitzungen in separaten Fenstern übernehmen die vom Lead zugewiesenen Aufgaben. Alle arbeiten mit demselben Dateisystem und können die Zwischenergebnisse der anderen sehen.

Das ist nützlich, wenn sich eine Aufgabe in 3–5 große Arbeitsstränge aufteilen lässt, die jeweils Stunden dauern (ein großes Modul migrieren, ein Subsystem neu schreiben, ein vollständiges Sicherheitsaudit durchführen). In diesem Fall führt der Lead-Agent den Plan in einer gemeinsamen Aufgabendatei an einem absoluten Pfad außerhalb der Worktrees. Worker lesen diesen Pfad und berichten Ergebnisse. Nur der Lead ändert Statusangaben, damit keine konkurrierenden Schreibzugriffe auf die Koordination entstehen.

Technisch gesehen sind Agent Teams mehrere Fenster, die auf Git Worktree aufsetzen und einen gemeinsamen Planungspunkt nutzen. In der Praxis verwalten 80 % der Leute Agent Teams manuell (wie oben mit Worktree beschrieben) und verwenden kein spezielles „Teams-Framework“. Das ist völlig in Ordnung.

Wenn du nicht sicher bist, ob du überhaupt ein Framework brauchst, brauchst du wahrscheinlich keins. Verwende manuelle Worktrees und einen Lead-Agent im Hauptverzeichnis.

Ebene 4: Dynamic Workflows – Claude schreibt ein JS-Orchestrierungsskript#

Bei allen drei oben beschriebenen Ebenen bleibt der Plan in einem Gespräch: im Kopf des Hauptagents oder in der Aufgabenliste des Lead-Agents. Dynamic Workflows verlagern den Plan in den Code. Claude formuliert die Aufgabe als JavaScript-Skript, die Laufzeit führt es in einer isolierten Umgebung aus, Zwischenergebnisse bleiben in Skriptvariablen statt in deinem Kontext, und die Sitzung bleibt reaktionsfähig, während die Agents im Hintergrund arbeiten.

Ein konkretes Beispiel aus der offiziellen Dokumentation. Du sagst:

ultracode: audit every API endpoint under src/routes/ for missing auth checks

Claude schreibt ein JavaScript-Skript mit ungefähr folgender Logik: „Nimm alle Dateien aus src/routes/, teile sie in Gruppen zu je 30 Endpunkten auf, starte für jede Gruppe einen Agent mit derselben Prüfung, lass anschließend zwei unabhängige Grader-Agents ihre Ergebnisse kontrollieren und fasse alles zu einem Abschlussbericht zusammen.“ Das Skript läuft. Du erhältst eine Ergebnistabelle und eine Liste der Endpunkte, die unbedingt überprüft werden müssen.

Wo es funktioniert.

• Ein ganzes Projekt auf ein Problem prüfen (Sicherheit, Typisierung, veraltete APIs).
• Große Migrationen (500+ Dateien, für die dieselbe Regel gilt).
• Recherchefragen, die aus mehreren unabhängigen Blickwinkeln geprüft werden müssen (Anthropic macht das mit dem eingebauten Befehl /deep-research).

Eine detaillierte Aufschlüsselung der Dynamic Workflows, ihrer Grenzen und der Funktionsweise von ultracode findest du im separaten Leitfaden zu Dynamic Workflows in Claude Code.

Wann du es NICHT verwenden solltest. Wenn die Aufgabe linear und klar ist. Für eine Aufgabe wie „Stelle diese Komponente fertig“ ist kein Workflow nötig. Ein Workflow ist sinnvoll, wenn sich eine Aufgabe in 10+ unabhängige Teilaufgaben aufteilen lässt und diese gegenseitig überprüft werden müssen.

Haupteinschränkung. Ein Workflow verbraucht deutlich mehr Tokens als eine normale Sitzung. Anthropic empfiehlt in der Dokumentation:

Mit anderen Worten: Führe deinen ersten Workflow auf einem Verzeichnis aus, nicht auf dem gesamten Projekt. Prüfe die Kosten und entscheide dann, ob sich eine Ausweitung lohnt.

Outcomes: eine Kriterienrubrik und ein unabhängiger Reviewer#

Das Gefährlichste bei Multi-Agent-Arbeit ist, den Ausgaben der Agents zu vertrauen. Jeder Agent liefert Text, der wie abgeschlossene Arbeit aussieht. Ein Zitat scheint zu stimmen, ein Bericht vollständig zu sein, eine Migration erledigt. Mit einem Agent kannst du das selbst prüfen. Bei 10 Agents kannst du es nicht – dir fehlt die Zeit.

Anthropic begegnet diesem Problem mit Outcomes, einer am 6. Mai 2026 veröffentlichten Funktion von Managed Agents. Die Idee ist einfach: Die Sitzung erhält einen ZWEITEN Agent (einen Grader), dessen einzige Aufgabe darin besteht, die Arbeit des ersten Agents anhand einer strengen Rubrik zu überprüfen.

So funktioniert es technisch. Du verfasst eine Rubrik – ein Markdown-Dokument mit einer detaillierten Liste, woran sich „erledigt“ erkennen lässt, welche Quellen zu prüfen und welche Labels zu verwenden sind. Die Plattform erstellt automatisch einen Grader-Agent in einem frischen Kontextfenster. Er erhält nur die Rubrik und das Ergebnis, sonst nichts. Nach jedem Versuch des Hauptagents (des Verfassers) liest der Grader das Ergebnis erneut und gibt es entweder frei oder liefert eine Liste der noch offenen Punkte zurück.

Ein Zitat aus dem Anthropic Cookbook:

Zahlen zur tatsächlichen Wirkung: Nachdem das KI-Unternehmen Harvey Outcomes in Claude Managed Agents integriert hatte, stieg seine Aufgabenerfüllungsrate um etwa das 6-Fache. Bei Wisedocs (medizinische Dokumentation) verringerte sich der Zeitaufwand für die Prüfung eines Dokuments um 50 %. Diese Zahlen stammen aus der offiziellen Ankündigung der Funktion.

Was für einen Vibe-Coder statt eines Unternehmens wichtig ist: Outcomes ist ein Muster, nicht nur eine bestimmte Funktion. Du kannst deinen eigenen Grader-Agent erstellen, indem du dieselben Kriterien in .claude/agents/grader.md beschreibst und den Hauptagent bittest, ihn nach jedem Versuch auszuführen. Das funktioniert mit jedem Multi-Agent-Setup, nicht nur mit Managed Agents.

Die wichtigste Regel aus dem Cookbook fürs Verfassen von Rubriken lautet: Formuliere etwas Überprüfbares und nichts Allgemeines. Nicht: „Prüfe, ob das Briefing die Abrechnung abdeckt“, sondern: „Öffne das Briefing, suche den Abschnitt zur Abrechnung und bestätige, dass dort ein Betrag in $ oder ein prozentualer Anteil am Umsatz angegeben ist.“ Bei der ersten Anweisung kann der Grader überfliegen und ein Häkchen setzen. Die zweite zwingt ihn, das Dokument zu öffnen und eine konkrete Zahl zu finden.

Anti-Pattern: „50 Agents, die Unsinn machen“#

Das ist das zentrale Multi-Agent-Anti-Pattern. Jemand erfährt, dass Claude Code 16 Agents gleichzeitig ausführen kann und Dynamic Workflows 1000 pro Lauf schaffen, und setzt sich hin, um sie zu starten. Das Ergebnis: null. Tokenverbrauch: das Zehnfache einer normalen Sitzung.

Ein einfacher Test. Nimm ein Blatt Papier und zeichne für jeden deiner Agents ein Kästchen. Schreibe in jedes Kästchen:

1. Was genau er tut (ein Satz).
2. Welche Dateien er bearbeitet.
3. Was er zurückliefert.
4. Wer es überprüft.

Wenn du auch nur eine dieser Fragen nicht innerhalb von 30 Sekunden beantworten kannst, solltest du diesen Agent nicht einsetzen. Diese Regel gilt auf jeder Ebene: Subagents, Agent Teams, Dynamic Workflows.

Das zweite Anti-Pattern ist Arbeit parallel auszuführen, die nacheinander erledigt werden sollte. Wenn das Frontend zuerst das Backend braucht, weil es das API-Schema liest, solltest du sie nicht parallel ausführen. Erledige zuerst das Backend, dann das Frontend. Aufgaben sollten nur dann parallel laufen, wenn sie unabhängig sind.

Das dritte Anti-Pattern ist Multi-Agent für mehr Geschwindigkeit einzusetzen. Das funktioniert nur bis zu einem gewissen Punkt. Wenn du eine Aufgabe in vier unabhängige Arbeitsstränge aufteilst, sind sie ungefähr in der Zeit fertig, die ein einzelner Strang gebraucht hätte (zuzüglich minimalen Koordinationsaufwands). Aber wenn 50 Stränge auf einem Rechner laufen, arbeitet jeder langsamer, weil sie sich die CPU teilen. Die praktische Obergrenze auf einem Laptop liegt bei 4–6 gleichzeitig laufenden Claude-Code-Instanzen; danach setzt Drosselung ein.

Was kostet das, und wie kannst du vermeiden, deine Limits aufzubrauchen?#

Im Mai und Juni 2026 wurde in der Branche deutlich, dass KI-Coding mehr kostet als erwartet.

Eine normale Claude-Code-Chat-Sitzung kostet vergleichsweise wenig. Schalte Dynamic Workflows für ein ganzes Repository ein, und du erhältst eine Rechnung, die 20-mal so hoch ist. In der offiziellen Anthropic-Dokumentation heißt es:

Was in der Praxis zu tun ist. Die Einsparregeln aus der beschriebenen Praxis:

1. Gib für jeden Agent genau an, welche Dateien er bearbeiten soll. Nicht: „Sieh dir das Projekt an und suche nach Problemen“, sondern: „Sieh dir src/auth/*.ts an und prüfe, ob jede Funktion userId validiert.“ Mit der zweiten Anweisung erhältst du genau die Arbeit, für die du bezahlst.

2. Probiere einen Workflow immer zuerst auf einem Verzeichnis aus. Nicht auf ganz src/. Beginne mit src/auth/. Wenn dir die Ergebnisse gefallen und du die Kosten kennst, kannst du ihn breiter einsetzen.

3. Verwende standardmäßig /effort high und ultracode nur mit Bedacht. /effort ultracode bedeutet xhigh plus automatische Orchestrierung. Das ist sehr teuer. Verwende es, wenn eine Aufgabe tatsächlich mehrere parallele Arbeitsstränge erfordert.

4. Wechsle Subagents, wo möglich, zu einem kleineren Modell. Wenn sechs Subagents einen Leitfaden prüfen, brauchen weder der QA-Agent für KI-Merkmale noch der Prüfer der Querverweise Opus. Sonnet reicht aus. So sinkt der Verbrauch um das 3- bis 5-Fache.

Eine ausführliche Betrachtung zum Tokensparen findest du im Leitfaden dazu, wohin die Tokens in Claude Code fließen und im Leitfaden dazu, die Claude-Code-Limits nicht aufzubrauchen.

Wo du heute anfangen kannst: eine Checkliste für 30 Minuten#

1. Aktualisiere Claude Code auf v2.1.154+

   Das ist die Mindestversion, die Dynamic Workflows unterstützt. Führe claude update im Terminal aus.

2. Aktiviere Dynamic Workflows in /config

   Im Pro-Tarif sind sie standardmäßig deaktiviert. Öffne /config, suche die Zeile „Dynamic workflows“ und aktiviere sie. In den Tarifen Max, Team und Enterprise sind sie bereits aktiviert.

3. Erstelle deinen ersten Worktree

   Führe im Hauptverzeichnis des Projekts git worktree add ../<project>-experiment <branch> aus. Öffne ein zweites Terminalfenster in diesem Verzeichnis. Führe claude aus.

4. Füge eine gemeinsame Aufgabenliste hinzu

   Verwende einen absoluten Pfad außerhalb aller Worktrees. Eine tasks.md in jedem Worktree ist jeweils eine eigene Datei und synchronisiert sich nicht automatisch. Nur die Lead-Sitzung schreibt; Worker lesen die gemeinsame Liste und berichten an den Lead.

   Erstelle Koordinationsordner und Aufgabenliste einmal:

   mkdir -p "$HOME/projects/my-app-coordination"
   printf '%s\n' '# Aufgaben' '- Auth: dem Auth-Worktree zugewiesen' '- Billing: dem Billing-Worktree zugewiesen' > "$HOME/projects/my-app-coordination/tasks.md"
   

   Im ersten Terminal:

   cd "$HOME/projects/my-app-auth"
   printf 'Gemeinsame Aufgabenliste: %s\n' "$HOME/projects/my-app-coordination/tasks.md"
   claude
   

   Im zweiten Terminal:

   cd "$HOME/projects/my-app-billing"
   printf 'Gemeinsame Aufgabenliste: %s\n' "$HOME/projects/my-app-coordination/tasks.md"
   claude
   

   Gib beiden Agenten denselben oben ausgegebenen vollständigen absoluten Pfad: „Lies diese gemeinsame Aufgabenliste. Bearbeite nur deine zugewiesene Aufgabe und Dateien. Ändere die Liste nicht; melde Abschluss und Blockaden an den Lead, der ihre Pflege übernimmt.“ Prüfe vor dem Start, dass beide genau diese Datei lesen können. Kläre eine Berechtigungsabfrage für diesen Pfad. Die Liste koordiniert den Status; Codeänderungen bleiben in getrennten Worktrees.

5. Arbeite eine Woche lang auf diese Weise

   Installiere nicht sofort einen GUI-Wrapper. Arbeite eine Woche lang manuell mit zwei Worktrees. Du wirst sehen, was fehlt; wähle dann ein Tool für ein konkretes Problem.

6. Aktiviere erst dann `/effort ultracode`

   Wähle eine Aufgabe, zum Beispiel: „Finde alle API-Endpunkte ohne Auth-Prüfungen in src/routes/.“ Aktiviere /effort ultracode. Sieh dir an, welchen Workflow Claude schreibt, was er kostet und welches Ergebnis er liefert. Das ist dein erster Dynamic Workflow.

Wie es weitergeht: Erinnerung zwischen Sitzungen, Code Review, Multi-Agent v2#

Was im Mai und Juni 2026 erschienen ist und wohin sich Multi-Agent in Claude Code entwickelt.

Managed Agents mit Dreaming. Veröffentlicht am 6. Mai 2026 bei Code with Claude. Ein geplanter Prozess liest zwischen den Sitzungen die bisherigen Transkripte eines Agents, erkennt wiederkehrende Muster und aktualisiert dessen Erinnerung. Die Aufgabenerfüllung des KI-Rechtsunternehmens Harvey stieg speziell nach Dreaming um das Sechsfache. Noch in der Research Preview.

Outcomes als Funktion von Managed Agents. Weiter oben beschrieben. Über das Claude Agent SDK verfügbar, nicht direkt über die Claude-Code-CLI. Dasselbe Muster kannst du bereits jetzt manuell mit einem Grader-Subagent anwenden.

Multi-Agent Orchestration v2 im Claude Agent SDK. Ein Lead-Agent delegiert selbst Aufgaben an Subagents und verwendet dafür ein gemeinsames Dateisystem. Das ist der Schritt von „N Subagents manuell starten“ zu „Eine Aufgabe beschreiben, und der Lead entscheidet selbst, wen er womit beauftragt“. Wenn du Subagents gerade erst kennenlernst, musst du dich um v2 noch nicht kümmern. Lerne erst das klassische Muster – „ein Hauptagent plus 3–5 Subagents mit Rollen“ – und gehe in 3–6 Monaten ganz natürlich zu v2 über.

Code Review durch ein Agent-Team. Anthropic kündigte bei Code with Claude eine Funktion zur automatischen Codeprüfung beim Öffnen eines PR an. Ein Team von KI-Agents prüft den Diff parallel, sucht nach Bugs, überprüft die Ergebnisse gegenseitig und stuft sie nach Schweregrad ein. Für Team und Enterprise verfügbar, noch nicht für Pro.

Plugin Marketplace. Gestartet am 23. Mai 2026 in v2.1.128-136. Einige Marketplace-Plugins sind fertige Multi-Agent-Setups (parallel-review, security-audit, migration-helper). Du kannst sie mit /plugin install <name>@claude-plugins-official installieren und dir ihren Aufbau ansehen – eine gute Möglichkeit, zu lernen, wie man eigene erstellt.

Multi-Agent in Claude Code ist weiterhin eine Sammlung von Primitiven mit unterschiedlichem Reifegrad. Subagents und Git Worktree sind stabil, bewährt und funktionieren überall. Agent Teams sind halbautomatisiert und halbmanuell. Dynamic Workflows befinden sich in der Research Preview und ändern sich schnell. Managed Agents v2 ist nur für Unternehmen verfügbar. Das bedeutet: Im nächsten Jahr wird für einen Vibe-Coder nicht die neueste Version, sondern das für die konkrete Aufgabe erforderliche Mindest-Setup optimal sein. Zwei Worktrees und ein Grader-Subagent reichen für einen Monat aktiver Arbeit. Füge erst dann mehr Komplexität hinzu, wenn du an Grenzen stößt.

Ein funktionierendes Setup fürs Vibe-Coding#

Praktische Materialien: Ailoot-Dokumentation.

Weitere Materialien und Tools: Ailoot.