Code-Agent-Orchester – So bringt man Multi-Agent-Coding wirklich zum Laufen

• Der Wechsel von der Zusammenarbeit mit einem einzelnen KI-Assistenten in einer synchronen Schleife hin zu einem Orchestrator-Modell, in dem mehrere Agenten asynchron mit jeweils eigenem Kontextfenster und Dateibereich arbeiten, ist im Jahr 2026 in vollem Gange
• Drei Kernmuster bilden die Grundstruktur des Multi-Agent-Codings: Subagents, Agent Teams und hierarchische Delegation; sie liefern jeweils Parallelität, Spezialisierung, Isolierung und zusammengesetztes Lernen
• Geteilte Aufgabenlisten und Peer-to-Peer-Messaging sind die zentralen Koordinationsmechanismen von Agent Teams und ermöglichen das automatische Auflösen von Abhängigkeiten sowie das Vermeiden von Engpässen
• Das Tool-Ökosystem ist Stand 2026 in drei Ebenen gegliedert: In-Process-Subagents (Tier 1), lokale Orchestratoren (Tier 2) und asynchrone Cloud-Agenten (Tier 3); die meisten Entwickler nutzen alle drei Ebenen je nach Anwendungsfall in Kombination
• Der Engpass hat sich von der Codegenerierung zur Verifikation verlagert; Quality Gates über Plan-Freigaben, Hooks und AGENTS.md sowie menschliche Reviews sind die entscheidenden Faktoren für die Zuverlässigkeit von Multi-Agent-Systemen

---

Der aktuelle Wandel: vom Dirigenten zum Orchestrator

• Bis vor 6 Monaten arbeiteten die meisten Entwickler synchron mit einem einzelnen KI-Assistenten, und ein einzelnes Kontextfenster setzte die Obergrenze der Arbeit
• Die produktivsten Entwickler wechseln nun zu einer Arbeitsweise, bei der mehrere Agenten mit jeweils eigenem Kontextfenster, Dateibereich und Verantwortungsgebiet asynchron koordiniert werden
• Conductor-Modell: Ein einzelner Agent wird synchron in Echtzeit gesteuert; typische Werkzeuge sind Claude Code CLI und der Agent-Modus im Cursor-Editor
• Orchestrator-Modell: Mehrere Agenten mit jeweils eigenem Kontextfenster werden asynchron koordiniert; typische Werkzeuge sind Agent Teams, Conductor, Codex und Copilot Coding Agent
• Als Orchestrator braucht man neue Fähigkeiten: klare Spezifikationen schreiben, Arbeit zerlegen und Ergebnisse verifizieren

Die 8 Stufen des KI-gestützten Codings

• [Orchestrierung]
  • L8 — Eigenen Orchestrator bauen: Eine Koordinationsschicht selbst implementieren, in der Agentenerzeugung, Routing und Management direkt per Code geschrieben werden
  • L7 — 10 oder mehr Agenten, manuell verwaltet: „Verdammt, das ist ein Chaos geworden.“ Falscher Kontext landet beim falschen Agenten, und die Frage „Was passiert, wenn Claude Code Claude Code ausführt?“ taucht auf
  • L6 — Agenten-Multiplexing: Warten ist zu langweilig, also startet man nach und nach weitere Agenten und gerät in einen Zustand, in dem man zwischen mehreren Streams springt und nicht mehr aufhören kann
• [Agent-first]
  • L5 — Agent-first, IDE später: Agentengespräche sind der primäre Arbeitsraum, die IDE dient nur noch zur Codeprüfung
  • L4 — Diff verschwindet, das Gespräch übernimmt: Nicht mehr jedes Diff wird geprüft; stattdessen beobachtet man das Verhalten des Agenten und konzentriert sich auf die Richtungsgebung
• [IDE-Zeitalter]
  • L3 — YOLO-Modus: Der Agent läuft frei in der IDE, das Vertrauen steigt
  • L2 — Agent in der IDE, Berechtigungen manuell freigegeben: Jede Dateiveränderung wird direkt genehmigt, vollständige manuelle Kontrolle
  • L1 — Keine KI: Traditioneller Entwicklungs-Workflow
• Nach dem von Steve Yegge formulierten 8-Stufen-Framework für den Einsatz von KI-Tools bleiben die meisten Entwickler auf Stufe 3 bis 4
• Die Orchestrierungsebene beginnt ab Stufe 6 und erfordert einen grundlegend anderen Skillset als die Fähigkeiten, die man bis Stufe 5 aufgebaut hat
• Dieser Text behandelt die Stufen 5 bis 8

Grenzen eines einzelnen Agenten

• Kontextüberlastung: Ein einzelner Agent kann nur eine begrenzte Informationsmenge halten, und große Codebasen überfordern ein einzelnes Kontextfenster
• Fehlende Spezialisierung: Ein Agent, der Datenebene, API, UI und Tests zugleich behandelt, bleibt ein Generalist; ein Agent, der ausschließlich die Datenebene betreut, schreibt deutlich besseren DB-Code
• Fehlende Koordination: Selbst wenn zusätzliche Helfer-Agenten hinzukommen, können sie nicht miteinander kommunizieren, Aufgaben teilen oder Abhängigkeiten auflösen; je mehr Agenten man ohne Koordinationsprimitiven hinzufügt, desto schwieriger wird die Verwaltung
• Subagents lösen die ersten beiden Probleme, Agent Teams alle drei

Warum Multi-Agenten

• Parallelität (3-facher Durchsatz): Frontend-, Backend- und Test-Agenten arbeiten gleichzeitig
• Spezialisierung (fokussierter Kontext): Jeder Agent kennt nur die Dateien, für die er zuständig ist; ein Agent, der nur db.js kennt, schreibt besseren DB-Code als ein Agent, der die gesamte Codebasis bearbeiten muss
• Isolierung (sichere Ausführung): Git-Worktrees geben jedem Agenten ein eigenes Arbeitsverzeichnis, ohne Merge-Konflikte
• Zusammengesetztes Lernen: Die Datei AGENTS.md sammelt Muster und Hinweise über Sitzungen hinweg, sodass jede Sitzung die nächste verbessert
• Drei fokussierte Agenten liefern durchgängig bessere Ergebnisse als ein Generalisten-Agent, der dreimal so lange arbeitet

Muster 1: Subagents — fokussierte Delegation

• Mit dem Task-Tool werden aus dem übergeordneten Orchestrator spezialisierte Kind-Agenten erzeugt; das ist das einfachste Multi-Agent-Muster und sollte als Erstes ausprobiert werden
• Konkretes Beispiel: Gibt man Claude Code den Prompt „Baue Link Shelf, einen Bookmark-Manager mit Express und SQLite“, zerlegt der übergeordnete Orchestrator dies in drei Subagent-Briefings
  • Subagent für die Datenebene: db.js erstellen und anschließend den Bericht DATA.md verfassen
  • Subagent für die Business-Logik: validation.js erstellen und anschließend den Bericht LOGIC.md verfassen
  • Subagent für API-Routen: Nach dem Lesen von DATA.md und LOGIC.md server.js erstellen
• Die ersten beiden Subagents laufen unabhängig parallel, der dritte startet nach Abschluss der beiden Berichte; der Parent verwaltet den Abhängigkeitsgraphen manuell
• Grenzen von Subagents: Der Parent muss den Abhängigkeitsgraphen manuell verwalten, und es gibt weder Peer-Messaging noch geteilte Aufgabenlisten zwischen Agenten; bei lockerem Dateibereichs-Management können Konflikte entstehen
• Insgesamt etwa 220.000 Token und damit kostenneutral

• Hierarchische Subagents (Teams von Teams)

  • Statt dass der Orchestrator sechs Subagents direkt erzeugt, erzeugt er zwei Feature-Leads, und jeder Feature-Lead erzeugt seinerseits zwei bis drei Spezialisten
  • Der übergeordnete Orchestrator verwaltet nur zwei Agenten und hält so den Kontext sauber; Feature-Lead A erhält das Briefing „Suchfunktion bauen“ und zerlegt es selbstständig weiter
  • Dasselbe Prinzip wie in realen Engineering-Organisationen: Ein VP weist Aufgaben nicht direkt einzelnen Engineers zu, sondern gibt sie über Tech Leads weiter

Muster 2: Agenten-Team — echte parallele Ausführung

• Experimentelle Funktion von Claude Code, aktivierbar mit dem Befehl export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
• 3-Schichten-Architektur:
  • Team Lead: Zerlegung der Arbeit, Erstellung der Aufgabenliste, Zusammenführung der Ergebnisse
  • Geteilte Aufgabenliste: Statusverfolgung (pending, in_progress, completed, blocked), Abhängigkeitsverfolgung, Dateisperren
  • Teammitglieder: jeweils eine unabhängige Claude-Code-Instanz mit eigenem Kontextfenster, ausgeführt in geteilten tmux-Panels
• Teammitglieder wählen Aufgaben eigenständig aus der geteilten Liste und kommunizieren direkt per Peer-to-Peer-Messaging miteinander, ohne über den Lead zu gehen
• Wenn ein Teammitglied nach Abschluss einer Aufgabe diese als erledigt markiert, werden davon abhängige blockierte Aufgaben automatisch entsperrt
• Mit Ctrl+T lässt sich ein visuelles Overlay der Aufgabenliste ein- und ausblenden

• Zentrale Mechanismen des Agenten-Teams

  • Geteilte Aufgabenliste: Wenn ein Backend-Teammitglied die Search API als abgeschlossen markiert, wechselt die blockierte Aufgabe zum Schreiben von Tests automatisch in den Status pending; Dateisperren verhindern gleichzeitiges Bearbeiten
  • Peer-Messaging: Der Backend-Agent übermittelt dem Frontend-Agenten den API-Vertrag direkt — "GET /search?q= returns [{id,title,url}]"; so wird verhindert, dass der Lead zum Koordinations-Flaschenhals wird
  • Wenn ein Teammitglied in den Leerlauf geht, wird der Lead automatisch benachrichtigt

• Zentrale Empfehlungen für Agenten-Teams

  • 3 bis 5 Teammitglieder sind optimal; die Token-Kosten steigen linear mit der Teamgröße
  • Plan-Genehmigung: Wenn Teammitglieder vor der Implementierung einen Plan erstellen, prüft der Lead ihn und genehmigt oder verwirft ihn; Architekturprobleme zu erkennen, bevor Code existiert, ist deutlich günstiger
  • Drei fokussierte Teammitglieder liefern durchgängig bessere Ergebnisse als fünf abgelenkte

• Zuverlässigkeitstipps für Agenten-Teams

  • Loop-Guardrails + Reflexionsphase: Für alle Teammitglieder eine Obergrenze von MAX_ITERATIONS=8 setzen; vor jedem erneuten Versuch einen Reflexions-Prompt erzwingen: "Was ist fehlgeschlagen? Welche konkrete Änderung würde die Korrektur bringen? Wiederhole ich denselben Ansatz?" → deutlich weniger festgefahrene Agenten
  • Dediziertes @reviewer-Teammitglied: Claude Opus 4.6 (schreibgeschützt) als Reviewer festlegen, der nur Lint-, Test- und Security-Scan-Tools verwendet und bei jedem TaskCompleted-Ereignis automatisch ausgelöst wird; Verhältnis von 1 Reviewer auf 3 bis 4 Builder; der Lead erhält immer nur bereits überprüften Code

Muster 3: Orchestrierung im großen Maßstab

• Wenn 5, 10, 20 oder mehr Agenten über mehrere Repos und Features hinweg verwaltet werden, braucht es dedizierte Orchestrierungs-Tools
• Tier 1 — In-Process-Subagenten und -Teams: Claude-Code-Subagenten und Agenten-Teams; einzelne Terminal-Session, keine zusätzlichen Tools erforderlich; hier sollte man anfangen
• Tier 2 — Lokale Orchestratoren: Mehrere Agenten in unabhängigen Worktrees ausführen und dabei Dashboard, Diff-Review und Merge-Kontrolle behalten; optimal für 3 bis 10 Agenten in einer bekannten Codebasis; Conductor, Vibe Kanban, Gastown, OpenClaw + Antfarm, Claude Squad, Antigravity, Cursor Background Agents
• Tier 3 — Asynchrone Cloud-Agenten: Aufgaben zuweisen, dann das Notebook schließen und auf den PR warten; Ausführung auf Cloud-VMs; Claude Code Web, GitHub Copilot Coding Agent, Jules by Google, Codex Web by OpenAI
• 2026 werden die meisten Entwickler alle drei Schichten nutzen: Tier 1 (interaktive Arbeit), Tier 2 (parallele Sprints), Tier 3 (nächtliche Backlog-Bearbeitung)

Tool-Spotlight

• Conductor by Melty Labs

  • Der schnellste Weg, Multi-Agent-Orchestrierung auf dem Mac zu starten; mehrere Claude-Code- und Codex-Agenten parallel ausführen, jeweils in einem unabhängigen git-Worktree
  • Bietet ein visuelles Dashboard und eine Diff-zentrierte Review-UI; es fallen nur API-Kosten an (kostenlos); nur für macOS (Apple Silicon und Intel)
  • Optimal, wenn 3 bis 8 Features parallel im selben Repo bearbeitet werden und visuelle Aufsicht nötig ist

• Claude Code Web

  • Zugriff über claude.ai/code; vollständig browserbasiert, kein Terminal nötig; GitHub-Repo verbinden und Aufgabenbeschreibung eingeben → Ausführung auf einer von Anthropic verwalteten Cloud-VM
  • Unterstützt Zwischensteuerung, automatische PR-Erstellung und Zugriff über die iOS-App
  • Teams (Terminal) arbeiten gemeinsam mit Agenten, Web (Browser) delegiert und lässt sie dann laufen

• GitHub Copilot Coding Agent

  • Zu unterscheiden vom Copilot-Agent-Modus in der IDE (synchron und interaktiv); der Copilot Coding Agent von GitHub ist vollständig asynchron
  • Beliebige GitHub-Issues @copilot zuweisen oder im Agents-Panel starten → erstellt einen Draft-PR in einer GitHub-Actions-Umgebung
  • Führt vor dem Tagging eine eigene Review-Schleife aus; Drittanbieter-Agenten wie Claude Code und Codex sind im selben Panel ebenfalls zugänglich; kann aus Slack, Jira, Linear und Azure Boards ausgelöst werden

• Jules by Google

  • Googles asynchroner Cloud-Coding-Agent auf Gemini-Basis; GitHub-Repo verbinden → Aufgabenbeschreibung → Jules erstellt einen Plan → nach Freigabe Ausführung auf einer Cloud-VM → Rückgabe eines PR mit vollständigem Denkprozess und Terminal-Logs
  • Bietet Audio-Changelogs, das Unterbrechen laufender Aufgaben und die Jules Tools CLI zum direkten Einspeisen von GitHub-Issues
  • Liest AGENTS.md im Repo automatisch, ohne zusätzliche Konfiguration

• OpenAI Codex Web

  • Jede Aufgabe läuft in einem unabhängigen Sandbox-Container, in dem das GitHub-Repo vorab geladen ist
  • Verfügt über ein Surface-Ökosystem, das Web, CLI (Open Source), macOS-App, IDE-Erweiterungen und GitHub-Integration mit einem ChatGPT-Konto verbindet
  • Funktion Verifiable Evidence: Gibt für jede Aufgabe Zitate aus Terminal-Logs und Testausgaben zurück, sodass sich der Ausführungsverlauf prüfen lässt

• Cursor Cloud Agents + Glass

  • Agenten lassen sich über Web, Desktop-App, Slack, Linear, GitHub, API und PWA (Installation über cursor.com/agents) starten
  • Glass: neue Oberfläche von Cursor, die das Agenten-Management zur Hauptansicht macht und den bisherigen Editor in ein bei Bedarf zugängliches Hilfswerkzeug verwandelt
  • Spiegelt das Muster wider, dass über das gesamte Ökosystem hinweg die Control Plane zum Haupterlebnis wird und der Editor darunter nur noch ein Instrument ist

• Vibe Kanban

  • Löst die "Doomscrolling-Lücke" (2 bis 5 Minuten Leerlauf während der Agentenarbeit); nach dem Erstellen von Aufgabenkarten genügt das Ziehen auf "In Progress", um jeweils eigenen Worktree und Branch anzulegen
  • Diff-Review direkt im Board und Versand von Feedback an laufende Agenten möglich; unterstützt Claude Code, Codex, Gemini CLI, Amp, Cursor Agent CLI und mehr; plattformübergreifend (Mac, Windows, Linux), kostenlos, BYOK

Tipps für die Skalierung

• Multi-Modell-Routing

  • Nicht für jede Aufgabe wird das teuerste Modell benötigt; erstelle eine Datei MODEL_ROUTING.md für rollenbasiertes Routing:
    • Planung·Architektur → günstige Gemini-/Claude-/OpenAI-Modelle
    • Implementierung → Sonnet, Opus oder Codex
    • Review → dediziertes Sicherheitsmodell

• Worktree-Lifecycle-Skripte

  • Automatisiere wiederkehrende Arbeit mit drei Shell-Aliases:
    • agent-spin <feature>: Worktree + Branch erstellen + Agent starten
    • agent-merge <feature>: Rebase + Review + PR erstellen
    • agent-clean: abgeschlossene Worktrees entfernen
  • Etwa 12 Zeilen Bash; Conductor übernimmt die visuelle Aufbereitung

• Nur von Menschen geschriebene AGENTS.md zulassen

  • Eine Studie von ETH Zurich Gloaguen et al. zeigt, dass von LLMs erzeugte AGENTS.md-Dateien keinen Vorteil bringen und im Schnitt zu ~3 % geringerer Erfolgsquote sowie zu über 20 % höheren Inferenzkosten führen
  • Von Entwicklern geschriebene Kontextdateien liefern eine Leistungssteigerung von ~4 %
  • Erlaube Agenten niemals, direkt in AGENTS.md zu schreiben; ein Lead muss jede Zeile freigeben
  • Kurz halten mit klaren Abschnitten: STYLE, GOTCHAS, ARCH_DECISIONS, TEST_STRATEGY

Quality Gates: Vertrauen ist gut, Verifikation ist besser

• Drei Quality Gates

  • Planfreigabe: Ein Teammitglied erstellt vor Beginn des Codings einen Plan → der Lead prüft und genehmigt oder lehnt ihn ab → dann erst Implementierung; einen schlechten Plan zu korrigieren ist deutlich günstiger als schlechten Code zu korrigieren
  • Hooks: automatisierte Checks für Lifecycle-Events; der Hook TeammateIdle prüft, ob alle Tests bestanden sind, bevor ein Agent die Arbeit unterbricht; TaskCompleted führt Linting und Tests aus, bevor etwas als abgeschlossen markiert wird; schlägt ein Hook fehl, arbeitet der Agent weiter, bis er besteht
  • Kumulatives Lernen über AGENTS.md: erfasst entdeckte Muster, Hinweise und Stilpräferenzen; alle Agenten lesen die Datei zu Beginn einer Session, und in jeder Session wird etwas ergänzt

• Der Engpass verlagert sich zur Verifikation

  • Agenten können beeindruckende Ergebnisse mit erstaunlicher Geschwindigkeit erzeugen; die Schwierigkeit besteht darin, sicher zu sein, dass diese Ergebnisse korrekt sind
  • Tests, die vor einer Änderung bestanden haben, garantieren nicht, dass sie Regressionen durch diese Änderung erkennen
  • Agenten können technisch gültige Tests schreiben, die aber wichtige Fälle übersehen
  • Aufgrund von Beschränkungen des Kontextfensters können Agenten, die in großen Codebasen arbeiten, wichtige Randbedingungen außerhalb ihrer aktuellen Sicht verpassen
  • Eine instabile Umgebung, die für einen einzelnen Entwickler nur ein lästiger Edge Case wäre, wird zum systemischen Blocker, wenn 40 Agenten gleichzeitig auf denselben instabilen Test stoßen
  • Solange die Verifikationsinfrastruktur nicht mit den Generierungsfähigkeiten Schritt hält, ist menschliches Review kein optionaler Zusatzaufwand, sondern ein Sicherheitssystem

Ralph Loop und sich selbst verbessernde Agenten

• Das Ralph-Loop-Muster

  • Populär gemacht von Geoffrey Huntley und Ryan Carson; das Muster hinter „shipping while you sleep“; Carsons eigenständiges Tool ralph (snarktank/ralph) implementiert den Kern-Loop, während das Projekt Antfarm Multi-Agent-Orchestrierung auf OpenClaw aufsetzt
  • 5-Stufen-Zyklus: Pick(nächste Aufgabe aus tasks.json wählen) → Implement(Änderungen ausführen) → Validate(Tests·Typen·Linting ausführen) → Commit(wenn Checks bestehen, committen und Aufgabenstatus aktualisieren) → Reset(Agentenkontext zurücksetzen und zur nächsten Aufgabe wechseln)
  • Kernerkenntnis: Durch das Zurücksetzen bei jeder Iteration wird eine Kumulation von Verwirrung verhindert; kleine, klar abgegrenzte Aufgaben führen zu weniger Halluzinationen und saubererem Code als ein einziger riesiger Prompt
  • Sicherheitsvorkehrungen: Fehler als Feedback für automatische Wiederholungen zurückführen, aber nach mehr als 3 Blockaden beenden und neu zuweisen; immer auf Feature-Branches arbeiten; Obergrenzen für Iterationen, Zeit und Tokens setzen; Agenten erstellen PRs → menschliches Review vor dem Merge
  • Vier Speicherkanäle zwischen Kontext-Resets beibehalten: Git-Commit-Historie, Fortschrittslog, Aufgabenstatusdatei (tasks.json), AGENTS.md als langfristiges semantisches Gedächtnis

• Agenten mit der Zeit intelligenter machen

  • Selbstreflexion über REFLECTION.md: Nach jeder Aufgabe erzwingen, dass festgehalten wird „was überraschend war, ein Muster zum Hinzufügen zu AGENTS.md, eine Verbesserung des Prompts“; der Lead prüft dies und übernimmt freigegebene Learnings
  • Token-Budgets und Abbruchkriterien: Obergrenzen pro Agent setzen (z. B. Frontend 180.000 Tokens, Backend 280.000 Tokens); bei 85 % des Budgets automatisch pausieren und den Lead benachrichtigen; bei mehr als 3 Blockaden am selben Fehler abbrechen und an einen neuen Agenten neu zuweisen
  • Beads / permanentes Gedächtnis: das „beads“-Muster von Gastown — ein unveränderliches, Git-basiertes Protokoll aller Entscheidungen und Ergebnisse mit vollständiger Herkunft; Agenten fragen frühere Beads über einen Task-Graphen und eine per SQL adressierbare Datenebene ab; kein simples vektorbasiertes RAG, sondern strukturiertes, abfragbares institutionelles Gedächtnis

Die Disziplin, die das alles zum Laufen bringt

• Der menschliche Engpass war kein Bug, sondern ein Feature

  • Wenn Menschen Code in menschlicher Geschwindigkeit schreiben, spüren sie den Schmerz früh; fehlgeschlagene Tests, Hinweise aus Code Reviews, entdeckte Duplikate — der Schmerz ist sofort da, also wird unterwegs korrigiert
  • Bei einer orchestrierten Armee von Agenten gibt es keinen natürlichen Engpass; kleine Fehler (Code Smells, Duplikate, unnötige Abstraktionen) vervielfachen sich mit einer Geschwindigkeit, mit der man nicht mehr aufholen kann
  • Da man aus dem Loop heraus ist, spürt man den Schmerz erst, wenn die Architektur keine neuen Funktionen mehr zulässt
  • Darum gibt es all diese Quality Gates (Planfreigabe, Hooks, Token-Budgets, menschliches Review): Ohne sie manövriert man sich mit Agent Coding selbst in eine Sackgasse

• Aufgaben delegieren, Urteilsvermögen behalten

  • Was man Agenten geben sollte: klar abgegrenzte Aufgaben mit eindeutigen Pass/Fail-Kriterien, Boilerplate, Migrationen, Test-Scaffolding, das Ausprobieren von Ansätzen, für die man selbst keine Zeit hätte
  • Was man selbst behalten sollte: Architektur- und API-Design (Agenten haben aus Trainingsdaten viele schlechte Architekturen gelernt und können Enterprise-Patterns unverändert auf Startups übertragen), zu entscheiden, was nicht gebaut wird (Nein zu sagen ist keine Fähigkeit von Agenten), Review von Agenten-Output mit Gesamtverständnis des Systems
  • Wenn man das Verständnis des eigenen Systems verliert, verliert man auch die Fähigkeit, es zu reparieren, zu erweitern und Fehlverhalten zu erkennen

• Spezifikationen sind Hebelwirkung

  • Wenn man 50 Agenten parallel orchestriert, verlangsamt unklarer Denkstil nicht einfach nur die Geschwindigkeit, sondern wird über Dutzende parallele Ausführungen hinweg verstärkt
  • Der Unterschied zwischen mittelmäßigem und herausragendem Output hängt fast vollständig von der Qualität der Spezifikation ab
  • Vage Spezifikationen verstärken Fehler über die gesamte Flotte; präzise Spezifikationen mit klarer Architektur, Integrationsgrenzen, Edge Cases und Invarianten verstärken präzise Implementierungen im gesamten System
  • Die mechanische Arbeit des Code-Eintippens wird automatisiert; die kognitive Arbeit, ein System zu verstehen, wird über eine ganze Flotte autonomer Worker hinweg verstärkt

Das Fabrikmodell

• Es geht nicht mehr nur darum, Code zu schreiben, sondern darum, eine Fabrik zum Erstellen von Software aufzubauen
• 6-stufige Produktionslinie: Plan(Spezifikation mit Akzeptanzkriterien schreiben) → Spawn(Team erstellen und Agenten zuweisen) → Monitor(Fortschritt alle 5–10 Minuten prüfen·Blocker lösen, ohne zu hoveren) → Verify(Tests ausführen·Code reviewen; Verifikation ist der Engpass) → Integrate(Branches mergen·Konflikte lösen) → Retro(AGENTS.md mit neuen Mustern aktualisieren; kumulatives Lernen)
• Praktische Tipps:
  • WIP-Limits setzen: Nicht mehr Agenten laufen lassen, als man sinnvoll reviewen kann; 3–5 sind der Sweet Spot
  • Abbruchkriterien definieren: Nach mehr als 3 Blockaden am selben Fehler stoppen und neu zuweisen
  • Asynchrone Check-ins: Alle 5–10 Minuten den Fortschritt prüfen; die Agenten autonom arbeiten lassen
  • Eine Datei, ein Owner: Verhindern, dass zwei Agenten dieselbe Datei bearbeiten; Konflikte töten die Geschwindigkeit

5 Muster, mit denen man heute anfangen kann

1. In Sub-Agenten zerlegen: Mit dem Task-Tool fokussierte Child-Agenten mit spezifischem Briefing und Dateiverantwortung erstellen; keine Einrichtung nötig; heute starten
2. Parallelität mit einem Agenten-Team: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 aktivieren; einen Lead und drei Teammitglieder erstellen; mit einer gemeinsamen Task-Liste koordinieren
3. Isolierung mit Git-Worktrees: Jedem Agenten einen eigenen Worktree geben; keine Merge-Konflikte; der Conductor erledigt das automatisch
4. Quality Gates für Vertrauen: Für riskante Änderungen eine Planfreigabe verlangen; einen Hook hinzufügen, der bei Task-Abschluss Tests ausführt; Agenten-Output niemals ohne Verifikation vertrauen
5. Verbundlernen mit AGENTS.md: Muster, Hinweise und Stilpräferenzen dokumentieren; wird in jeder Sitzung gelesen und aktualisiert; Wissen verstärkt sich kumulativ

[kurthong]

Ich weiß nicht, ob das eine Eigenheit von Ingenieuren ist, aber warum sie immer so viele scheinbar plausible Dinge ohne jede Tiefe ausbreiten, ist mir ein Rätsel. Mich interessiert das Thema auch, deshalb habe ich den Text genau gelesen, aber Substanz war da keine.

[stroke33]

Der ultimative Grund, Haak Clco zu verwenden – die eigene Orchestrierung mit Multi-Agenten.

Ich betreibe gerade fünf Agenten, und die Tokens sind so unglaublich schnell weg, dass ich heulen könnte.