Wie man 3 bis 8 Coding Agents parallel ausführt, ohne den Überblick zu verlieren

Zwei Agents gleichzeitig auszuführen, dauert fünf Minuten. Du öffnest zwei Terminals, gibst jedem eine Aufgabe und beobachtest, wie der Text scrollt.

Das Problem beginnt beim vierten.

Du weißt nicht mehr, welcher auf eine Überprüfung wartet, welcher fertig ist, welcher vor zehn Minuten abgestürzt ist, während du woanders hingeschaut hast. Du scrollst im falschen Terminal. Du startest eine Aufgabe neu, die bereits erledigt war. Nach einer Stunde machst du die Arbeit von drei Agents von Hand, nur um den Überblick zu behalten.

Es ist kein Leistungsproblem. Es ist ein Sichtbarkeitsproblem.

Das eigentliche Nadelöhr ist dein Kopf

Ein autonomer Coding Agent liefert in Schüben. Er denkt 40 Sekunden nach, schreibt, stoppt, wartet auf dein Okay. In diesen 40 Sekunden kannst du einem zweiten Agent folgen. Während der zweite schreibt, gibst du dem ersten die Freigabe.

Bis zu 3 Agents hält dein Gehirn mit. Ab 5 verlierst du den Faden.

Anthropic veröffentlichte eine aufschlussreiche Zahl in seinen Dokumenten: Ungesteuerte Versuche gelingen etwa einmal von drei. Der Unterschied zwischen den Leuten, die viel liefern, und allen anderen ist nicht das Modell. Es ist die Struktur, die sie vor dem Start einrichten.

Bevor du also skalierst, strukturierst du.

Regel eins: ein Agent, ein isolierter Arbeitsbereich

Der klassische Fehler ist, drei Agents auf dieselbe Kopie des Repos zu setzen. Sie treten sich gegenseitig auf die Füße. Einer bearbeitet package.json, ein anderer auch, und du endest mit einem Merge, den du nicht entwirren kannst.

Die Lösung sind zwei Worte: git worktree.

git worktree add ../project-auth feature/auth
git worktree add ../project-billing feature/billing
git worktree add ../project-export feature/export

Jeder Agent arbeitet in seinem eigenen Ordner, auf seinem eigenen Branch, mit seinen eigenen Dateien. Null Kollisionen. Du überprüfst jeden Branch separat und mergest, wenn er bereit ist.

Dies ist die Grundlage dessen, was Forscher isolierte Delegation nennen: ein zentraler Manager teilt die Arbeit auf, jede Teilaufgabe läuft in ihrer eigenen Ecke, und die Integration erfolgt danach, mit Tests zur Validierung.

Regel zwei: nie dieselbe zentrale Datei zweimal ausgeben

Bevor du die Arbeit aufteilst, finde die Dateien, die mehrere Features berühren müssen. Der Router. Das Datenbankschema. Die API-Routen-Konfiguration.

Diese Dateien bekommen genau einen Agent. Die anderen warten oder arbeiten um sie herum.

Gib dasselbe routes.ts an zwei parallele Agents und du zahlst in Merge-Konflikten, was du dachtest, in Parallelität zu gewinnen. Dieser Tausch verliert jedes Mal.

Regel drei: ein Board, nicht zehn Terminals

Hier steigen die meisten Leute aus dem Multi-Agent aus. Sie öffnen acht Terminal-Tabs, verlieren den Faden und kriechen zurück zu einem einzigen Agent.

Du brauchst eine Ansicht, die drei Fragen auf einen Blick beantwortet:

• Wer codiert gerade?
• Wer wartet auf meine Überprüfung?
• Wer ist fertig oder abgestürzt?

Ohne diese Ansicht kostet dich Multi-Agent mehr mentale Belastung, als es dir an Geschwindigkeit bringt. Mit ihr kannst du tatsächlich 6 oder 8 Arbeitsströme gleichzeitig halten.

Genau diese Lücke füllt AgentsRoom. Jeder Agent bekommt seine eigene Kachel, seinen Status, seine Farbe. Ein Agent, der auf deine Antwort wartet, wird rot und pingt dich. Du hörst auf, im falschen Terminal zu scrollen, du schaust auf das Board und weißt, wohin du gehen musst.

Der Rhythmus, der in der Praxis funktioniert

Hier ist der Rhythmus, mit dem ich beginnen würde.

Beginne mit zwei Agents, an zwei Features, die keine Dateien teilen. Gewöhne dich an den Überprüfungs- und Merge-Zyklus. Dieser Zyklus, nicht der Code, wird zu deinem eigentlichen Job.

Sobald sich dieser Zyklus reibungslos anfühlt, gehe auf vier. Halte eine strikte Prioritätenliste von Aufgaben mit hoher Wirkung und stütze dich stark auf den Planmodus: Du genehmigst den Plan des Agents, bevor er eine Zeile schreibt. Ein im Voraus genehmigter Plan erspart dir später eine schmerzhafte Überprüfung.

Der Sweet Spot liegt zwischen 3 und 8 Features im selben Repo, mit visueller Aufsicht. Darüber hinaus, selbst mit einem guten Board, wird die Überprüfung zum Nadelöhr und du verlierst den Vorteil.

Was du tatsächlich gewinnst

Multi-Agent ist sinnlos für 95% der kleinen Aufgaben. Um einen Tippfehler zu beheben oder einen Button hinzuzufügen, reicht ein einzelner Agent völlig aus, und es geht schneller.

Wo es deine Woche verändert, ist bei großen Arbeiten. Du startest drei unabhängige Refactorings an einem Abend, überprüfst sie, sobald sie landen, und am nächsten Morgen hast du drei Tage Arbeit bereit zum Mergen.

Das Geheimnis ist nicht die Anzahl der Agents. Es ist immer zu wissen, welcher dich gerade jetzt braucht. Behebe das, und der Rest folgt.