Claude Code Projects: Wie ein KI-Agent ein Team autonomer Agenten koordiniert

Mit der Einführung von Claude Code Projects wandelt sich die KI-gestützte Entwicklung von der Paradigme „Ein Entwickler – ein Chat“ hin zu einer vollwertigen Multi-Agenten-Orchestrierung.

Zuvor musste ein Ingenieur für komplexe, umfangreiche Aufgaben manuell mehrere Terminal-Sessions öffnen, Kontext zwischen ihnen kopieren, Git-Branches überwachen und die Ergebnisse selbst zusammenführen. In dem neuen Modell übernimmt die führende KI die gesamte Disposition.

Sie formulieren ein übergeordnetes strategisches Ziel, und Claude übernimmt das Management:

• Dekomposition der Arbeit: Zerlegt das große Ziel in isolierte Teilaufgaben.
• Orchestrierung der Workflows: Startet parallele Cloud-Sessions (Threads).
• Kontrollierte Kontextsynchronisation: Synchronisiert Entscheidungen über den gemeinsamen Projektspeicher (MEMORY.md).
• Verifikation des Ergebnisses: Führt Tests aus, prüft den Build-Status im CI und bereitet finale Pull Requests vor.

Systemarchitektur: Coordinator und Threads

Im Kern des Multi-Agenten-Systems von Claude Code Projects liegt ein zweistufiges Modell der Aufgabenteilung:

Vergleichstabelle der Systemebenen:

1. Der Coordinator: Die Steuerzentrale

Das Hauptgespräch innerhalb des Projekts fungiert als Dispatch-Knotenpunkt. Hierhin senden Sie High-Level-Anforderungen, technische Spezifikationen und Korrekturen.

Der Coordinator führt folgende Aufgaben aus:

• Anforderungsannahme: Analysiert komplexe Anfragen und definiert die Grenzen der Aufgabe.
• Routing: Entscheidet, ob ein neuer Thread gestartet oder die Aufgabe in einen bestehenden Kontext übergeben wird.
• Berichtsaggregation: Erhält kurze Zusammenfassungen von den Agenten, ohne den Hauptchat mit Gigabytes an Zwischenlogs zu belasten.
• Synthese: Kombiniert die Ergebnisse verteilter Threads zu einem einheitlichen finalen Produkt.

2. Threads: Cloud-basierte Entwickler

Jeder Thread ist eine vollwertige, unabhängige Claude Code Session, die in der Cloud-Infrastruktur bereitgestellt wird.

Bei der Arbeit mit der Codebase tut jeder Thread Folgendes:

• Isoliert die Umgebung: Klont eine frische Kopie des Repositories in einen separaten Container.
• Arbeitet im eigenen Branch: Erstellt einen Git-Branch für das spezifische Feature, um direkte Konflikte mit benachbarten Agenten auszuschließen.
• Validiert den Code: Führt lokale Linter, Unit-Tests und Integrationsszenarien aus.
• Formalisiert das Ergebnis: Öffnet eigenständig einen Pull Request auf GitHub und sendet eine kurze Zusammenfassung an den Coordinator.

Sie können dem Coordinator weiterhin neue Aufgaben stellen, während mehrere Threads gleichzeitig verschiedene Module des Systems refactorn.

3. Wie Claude Aufgaben dekomponiert

Sie müssen Aufgaben nicht manuell zuschneiden oder Agenten über Interface-Buttons erstellen. Sie senden eine globale Anforderung in den Chat, und der Coordinator wählt eine von drei Strategien:

Strategie A: Neue Aufgabe ➔ Neuer Thread

Wenn die Aufgabe unabhängig ist und erhebliche Änderungen erfordert, erstellt der Coordinator dafür eine saubere Cloud-Session. Wenn Sie beispielsweise in einem Prompt fragen:

• „Optimiere die Cold-Start-Geschwindigkeit der API und aktualisiere die Dokumentation in der OpenAPI-Spezifikation“ — startet Claude parallel zwei isolierte Threads.

Strategie B: Themenentwicklung ➔ Bestehender Thread

Wenn eine neue Eingabe eine Aufgabe ergänzt, an der ein Thread bereits arbeitet, vermeidet Claude Duplikate. Er leitet die Anfrage in den bereits „aufgewärmten“ Kontext weiter, wo der Agent frühere Edits und die Struktur der betroffenen Dateien kennt.

Strategie C: Einfache Frage ➔ Antwort im Hauptchat

Kurze Informationsabfragen („Welche Node.js-Version ist in der root package.json angegeben?“) bearbeitet der Coordinator sofort im Hauptfenster, ohne Zeit für die Initialisierung eines Cloud-Containers zu verschwenden.

Steuerung der Coordinator-Logik: Wenn Ihnen die automatische Aufgabenverteilung nicht gefällt, definieren Sie eine strikte Regel im Chat: «Bevor du neue Threads erstellst, zeige mir immer den Dekompositionsplan und warte auf meine Bestätigung».

4. Overview-Dashboard: Transparente Statuskontrolle

Wenn 5–10 Agenten gleichzeitig im Projekt arbeiten, ist es unmöglich, sie über separate Terminals zu überwachen. Die gesamte Aktivität wird im Overview-Dashboard konsolidiert.

Matrix des Thread-Lebenszyklus:

Spezialisierte Projekt-Tabs:

• Library: Wissensdatenbank des Projekts, in der von Agenten erstellte Spezifikationen, Berichte und Datendateien gespeichert werden.
• Pull Requests: Einheitliche Liste aller von Agenten geöffneten PRs mit Markierungen zum CI-Status.
• Routines: Geplante regelmäßige Prozeduren (z. B. täglicher Sicherheitsaudit der Abhängigkeiten).

5. Gemeinsamer Projektspeicher: Verlustfreie Synchronisation

Alle Threads innerhalb eines Projekts arbeiten nicht isoliert – sie sind an ein einheitliches Project Memory-System angebunden.

Was Claude sich merkt:

• Architektonische Vereinbarungen: Z. B. der Verzicht auf Bibliothek X zugunsten einer leichtgewichtigen Lösung Y.
• Operative Rahmenbedingungen: Verschiebung des Releasedatums, spezielle Genehmigungsprozesse für Edits im Billing-Modul.
• Entwicklerpräferenzen: Code-Stil-Konventionen, verbotene Patterns, Wahl des Package Managers (pnpm statt npm).

Jeder neue Thread liest beim Start primär die Datei MEMORY.md. Daher müssen Sie Basisanforderungen des Projekts nicht immer wieder denselben Agenten erklären.

6. Eingriff in die Arbeit einzelner Agenten

Trotz des hohen Autonomiegrades des Coordinators behält der Entwickler die volle Kontrolle über jeden Schritt. Sie können jederzeit in jeden Thread „hineintauchen“:

• Vollständiges Transcript ansehen: Minutengenaues Log ausgeführter Shell-Befehle, gelesener Dateien und Linter-Ergebnisse.
• Punktuelle Kurskorrektur: Direkte Anweisung an einen spezifischen Agenten („Konzentriere dich nur auf den Endpoint /checkout, lass den Rest vorerst unberührt“).
• Notfall-Stopp (Stop): Unterbrechen eines hängenden Threads mit einem Klick.

7. Praktische Anwendungsszenarien

Der Multi-Agenten-Ansatz ist besonders effektiv in vier Engineering-Szenarien:

Szenario 1: Performance-Optimierung (Latency Profiling)

Aufgabe: Reduzierung der Antwortlatenz des Checkout-Services (Checkout p75 latency) von 800 ms auf 200 ms.

• Thread 1: Profilisiert SQL-Abfragen zur Datenbank und erstellt eine Migration für fehlende Indizes.
• Thread 2: Konfiguriert Redis-Caching für schwere Katalogantworten.
• Thread 3: Optimiert die Größe des Client-Bundles und entfernt ungenutzte Imports.

Jeder Thread bereitet einen separaten PR mit isolierten Benchmarks vor.

Szenario 2: Cross-Repository API-Migration

Aufgabe: Außerbetriebnahme der veralteten v1 API in allen angrenzenden Services des Unternehmens.

• Backend API-, Web App- und Mobile App-Repos werden zum Project hinzugefügt.
• Der Coordinator startet 3 Threads: Jeder migriert Calls auf die v2 API in seinem Repo, führt lokale Tests aus und öffnet einen PR mit Hinweis auf die Merge-Reihenfolge.

Szenario 3: End-to-End Refactoring nach technischer Spezifikation

Aufgabe: Implementierung eines komplexen Auth-Moduls gemäß der Datei docs/auth-spec.md.

• Der Coordinator zerlegt die Spezifikation in logische Phasen: Datenmodell-Generierung ➔ Middleware-Implementierung ➔ OAuth-Integration ➔ E2E-Test-Schreibung. Das Wissen wird von Phase zu Phase über MEMORY.md weitergegeben.

Szenario 4: Batch-Audit von Dokumentation und Verträgen

Aufgabe: Überprüfung von Hunderten von Verträgen oder Support-Tickets.

• Threads verteilen Dokumentpakete untereinander, extrahieren Schlüsselrisiken und erstellen strukturierte JSON/Markdown-Zusammenfassungen im gemeinsamen Library-Speicher.

8. Einschränkungen und Fallstricke der Architektur

Paralleles Arbeiten verkürzt die Entwicklungszeit erheblich, erfordert jedoch Verständnis für die technischen Spezifika:

1. Token-Verbrauch und Tariflimits: Jeder aktive Thread verbraucht unabhängig das Modellkontingent. Zudem nutzt der Coordinator Tokens für das Lesen langer Berichte. Im System gilt ein Limit von bis zu 200 neuen Threads pro Tag pro Projekt.
2. Merge Conflicts: Obwohl Threads in verschiedenen Branches arbeiten, führen gleichzeitige Edits an gemeinsamen Modulen oder Config-Dateien unvermeidlich zu Konflikten beim Merge, die manuell gelöst werden müssen.
3. Isolation der Cloud-Umgebung: Threads laufen in virtuellen Anthropic-Containern. Sie haben keinen direkten Zugriff auf Ihre lokalen Datenbanken, Geräte-Emulatoren oder interne Services hinter dem Corporate VPN. Für solche Aufgaben ist weiterhin eine lokale Claude Code Session erforderlich.
4. Kontextfenster: Trotz automatischer Kontextkompression (compaction) kann ein Thread während langem Debugging das verfügbare Fenster erschöpfen. In diesem Fall erstellt der Coordinator einen sauberen Nachfolger-Thread.

Fazit: Eine neue Ebene der Arbeitsteilung

Claude Code Projects verändert die Rolle des Ingenieurs im Entwicklungsprozess grundlegend:

Statt manuell Befehle in zehn Terminal-Fenstern einzutippen, wird der Entwickler zum Architekten und Technical Director seines Teams autonomer AI-Agenten, wobei er sich den finalen Architektur-Review und die Genehmigung der Pull Requests vorbehält.