Raus aus dem Flaschenhals. Das Handwerk bleibt.

Mit einem Coding-Agent bist du Pair-Programmer: Er tippt schneller, du steuerst. Mit mehreren ändert sich der Job grundlegend. Cloud-Agents laufen in eigenen isolierten Umgebungen, arbeiten auf eigenen Branches und liefern Pull Requests zurück — nichts davon berührt deine Maschine. [1] Das Versprechen der Parallelität ist real. Aber dein Durchsatz hört auf, deine Tippgeschwindigkeit zu sein. Er wird zu der Frage, wie gut du eine Flotte in eine Richtung lenken kannst.

Und Flotten scheitern auf eine bestimmte Art. Richte einen zweiten Agent auf denselben Checkout wie den ersten, und innerhalb von Minuten bearbeiten beide dieselbe Datei — einer überschreibt den anderen mitten in einer Änderung, und du bekommst halb angewendete Diffs und einen kaputten Build, ohne zu wissen, welcher Agent was getan hat. [2] Die Kosten sind nicht nur kaputter Code. Es sind die Tokens, die deine Agents verbrennen, um die Kollision zu entdecken, aufzulösen und neu zu bauen — ein Anbieter von Tooling für parallele Agents verweist auf API-Guthaben, das durch Merge-Konflikte und halbfertige Änderungen verschwendet wird [3] — und am Ende bist du es, der Diffs entwirrt, die es nie hätte geben sollen.

Die Lösung ist kein klügerer Agent. Es ist, Koordination als Infrastruktur zu behandeln: explizite Aufgabengrenzen, isolierte Ausführung und evidenzbasierte Merges. [2] Bekommst du das hin, entfernst du dich wirklich als Flaschenhals — die Agents bauen, und du verbringst deine Stunden mit den Entscheidungen, die nur du treffen kannst.

Die meisten Coding-Agents gehen davon aus, dass ihnen das Projektverzeichnis gehört — sie lesen und schreiben Dateien direkt. Setzt man zwei davon in denselben Checkout, gehen schnell drei Dinge schief: Dateikollisionen, bei denen Agent A eine Datei umschreibt, während Agent B sie refaktoriert, und Git nur den letzten Schreibvorgang sieht; Kontextkontamination, bei der B eine Datei liest, die A gerade halb verändert, und über einen Zustand nachdenkt, der nie existiert hat; und Build-Interferenz, bei der beide Agents Builds und Tests auslösen, die um dieselben Ausgabeverzeichnisse und Ports konkurrieren. [4] Keiner davon ist ein seltener Sonderfall. Sie treten auf, sobald man zwei Sessions gegen ein Repo ausprobiert.

Die Standardlösung sind Git-Worktrees: ein verlinktes Arbeitsverzeichnis auf einem eigenen Branch, das dieselbe .git-Historie teilt — Isolation ohne Klonen. Der Befehl gibt es seit 2015; neu ist, dass er zur Standardmethode wurde, um mehr als einen Agent gegen eine Codebasis laufen zu lassen. [2] Jeder Agent bekommt sein eigenes Verzeichnis und seinen eigenen Branch, sodass er niemandes Dateien anfassen kann — und Konflikte verschieben sich auf den Merge-Zeitpunkt, wo normale Git-Werkzeuge sie erkennen, statt still zu entstehen, während die Arbeit läuft. [5]

Worktrees isolieren Dateien, aber nicht alles andere. Jeder Agent braucht auch eine eigene Datenbank (oder einen Datenbank-Branch) und einen eigenen Dev-Server-Port — sonst kollidieren zwei Agents trotzdem bei den Daten und im Netzwerk. [2]

Wie viele sind zu viele? Wer lokale Worktrees nutzt, berichtet von fünf bis sieben Agents auf einem Laptop als praktischer Obergrenze — danach holen Rate-Limits, Speicherplatz und Review-Aufwand auf. [2] Andere empfehlen drei bis fünf, also irgendwas zwischen drei und sieben, je nachdem, wen man fragt. [4] Cloud-Agents heben die Laptop-Grenzen auf, nicht aber die Review-Grenze.

Isolation hindert Agents daran, sich gegenseitig auf die Füße zu treten. Sie hindert sie nicht daran, Unvereinbares zu bauen. Echte Repositories haben gemeinsame Hotspot-Dateien — Routen, Konfigurationen, Registries — und Agents zu sagen, sie sollen in unterschiedlichen Dateien bleiben, hilft weniger als erhofft: Ein Toolhersteller merkt an, dass eine Refaktorierung, die ein Modul-Interface betrifft, jede Datei betrifft, die es importiert, und zwei Agents, die unterschiedliche Endpunkte hinzufügen, brauchen oft dieselbe Router-Datei. [6]

Die zweite Hälfte der Lösung ist also das Zerschneiden. Nicht überlappende Aufgaben zuweisen, damit Überlappung durch Design schwierig ist statt durch Glück vermieden. [5] Der Test ist schlicht:

"Wenn zwei Aufgaben überlappende Dateilisten haben, müssen sie sequenziell laufen, nicht parallel." [7]

Unserer Erfahrung nach ist der sauberste Schnitt nach Grenze, nicht nach Schicht: Gib jedem Agent ein Feature oder eine Naht, nicht ein Scheibchen derselben vertikalen Story. Merge dann Branches nacheinander in Abhängigkeitsreihenfolge und lasse nach jedem Merge Build und Tests laufen, sodass jeder Teil in einer Codebasis landet, auf der der nächste Agent aufbauen kann. [2]

Wenn zwei Teile wirklich voneinander abhängen, lass sie nicht parallel laufen und hoffe nicht einfach. Markiere eines als blockiert durch das andere in Linear, und lass das zweite erst starten, wenn das erste gemergt wurde. Die Abhängigkeit wird auf dem Board sichtbar statt nur in deinem Kopf zu leben.

Jeder Teil braucht trotzdem denselben Vertrag wie jede Einzel-Agent-Story: den Auftrag, die Einschränkungen, was tabu ist, und was fertig bedeutet. Eine gut geschnittene Story macht die Annahmen zweier Agents kompatibel, ohne ein Meeting — wie man eine schreibt, behandeln wir in unserem Guide zu Stories für Coding-Agents.

Mit mehreren Agents gleichzeitig kannst du nicht jeden Diff überfliegen — und du solltest es auch nicht müssen. Unser Rat: Verlagere die Qualitätslatte in die Automatisierung. Verlange Tests und automatische Verifikation, bevor etwas gemergt wird, und mach den Merge selbst evidenzbasiert statt hoffnungsvoll. Die Rollenaufteilung, die daraus entsteht, ist Koordinator, Spezialisten und Verifizierer — du planst und urteilst, Agents führen aus, und Checks verifizieren.

Das hält auch die Tokens in Richtung nützlicher Arbeit fließend. Wenn die Abnahmekriterien in der Story stehen, scheitert ein abdriftender Agent an seinen eigenen Tests, statt seine Abweichung an einen Reviewer zu liefern — oder schlimmer, an einen anderen Agent, der darauf aufbaut. Wenn nicht, taucht das Scheitern als Konflikt zwischen zwei selbstbewussten, plausiblen, falschen Pull Requests auf.

Der Gewinn zeigt sich darin, wo deine Aufmerksamkeit hingeht: Review-Zeit für Urteilsvermögen — ist das das richtige Verhalten, die richtige Form, der richtige Name — statt für Konfliktarchäologie und mysteriöse Diffs.

Es gibt eine leisere Kosten als Merge-Konflikte, und sie trifft Menschen, die ihr Leben lang programmiert haben. Agents fressen genau die Arbeit, die den Tag früher befriedigend gemacht hat — die kleinen, vollständigen Siege — und was übrig bleibt, ist zu entscheiden, was gebaut wird, Abwägungen zu beurteilen, zu reviewen und Feinheiten zu erkennen. [8] Manche, die auf diese Weise Features ausliefern, fühlen danach nichts: Die Arbeit passierte in ihrer Nähe statt durch sie. [9]

Ein Entwickler führte das Gefühl auf seine eigenen Entscheidungen zurück. KI habe ihm die Freude nicht genommen, schloss er — er habe sie weggegeben, indem er sich für Geschwindigkeit entschied:

"Ich höre auf, die Person zu sein, die es gemacht hat, und werde die Person, die es abgenickt hat." [11]

Ein anderer fasst es als Wertefrage: Wir automatisieren Aufgaben, die wir nicht wertschätzen — also sei ehrlich, ob du das Ergebnis willst oder das Verständnis, und wenn es das Verständnis ist, mach es auf die harte Tour. [10] Das ist das Gefühl hinter "Ich bin ein Code-Review-Roboter geworden." Es ist kein Naturgesetz des KI-Codings. Es passiert, wenn die Arbeitsteilung per Default entschieden wird statt bewusst. Also entscheide — bewusst — was dir bleibt:

Spaß ist, wie sich zeigt, auch ein Designproblem. Lass die Agents das Boilerplate übernehmen, und bleib selbst bei den schwierigen, befriedigenden Problemen. [8] Ein Entwickler plädiert für bewusste Langsamkeit und dafür, ambitionierte Projekte zu wählen:

"Der Schlüssel zum Spaß ist, sich selbst genau an der Grenze der eigenen Fähigkeiten herauszufordern." [9]

Rein auf schnelles Ausliefern zu optimieren zehrt genau daran. Wie dieselbe Autorin es formuliert: "Die Fähigkeit, komplexe Probleme zu durchdenken, verschwindet einfach." [9]

Es gibt einen ehrlichen Gegenpunkt, der Gehör verdient: "Wenn du fünf Agents parallel laufen lässt, programmierst du nicht mehr, du machst Flugsicherung." [8] Das stimmt, wenn die Koordination in deinem Kopf wohnt. Genau deshalb sollte die Koordination — wer als Nächstes läuft, was blockiert ist, was Review braucht — Tooling sein, nicht deine Aufmerksamkeit.

Ein paar konkrete Schritte, die eine echte Woche überstehen: Nimm dir das schwierigste Stück einer Story selbst und gib den Rest an die Flotte. Behalte einen Teil des Systems, der immer dir gehört — die Stelle, an der du noch jede Zeile selbst schreibst. Beende den Tag mit einem Review, das Architektur ist, keine Inspektion: Du bist derjenige, der entscheidet, was der Code als Nächstes werden soll.

Das ist keine Nostalgie. Motivation ist ein Produktionsfaktor: Niemand hält eine Flotte aus einem Job am Laufen, der sich wie Maschinenüberwachung anfühlt. Behalte das Handwerk, und die Agents werden zum Hebel.

Der Rat dieses Guides läuft auf drei Gewohnheiten hinaus: Arbeit so schneiden, dass sie nicht kollidieren kann, einen Branch nach dem anderen in Abhängigkeitsreihenfolge mergen, und Checks — nicht deine Augen — die erste Qualitätsschranke sein lassen. Aerunit macht diese Gewohnheiten zur Automatisierung für Teams mit Linear und Cursor Cloud Agents.

Es folgt Linears blocks / blocked-by-Beziehungen: Wenn ein Pull Request gemergt wird, findet Aerunit die Issues, die dieser PR blockiert hat, und stellt sie für Cursor Cloud Agents in die Warteschlange, sodass der nächste Teil auf gemergtem Code aufbaut. Das ist sequenzielles Mergen, für dich erledigt. Wenn ein Agent einen PR öffnet, führt Aerunit einen Code-Review durch und kann die Ergebnisse an die Agent-Session zurückschicken. Und Aerunit liest jedes Repository, das eine Story betrifft, bevor sie geschrieben wird, sodass repo-übergreifende Arbeit einen einheitlichen Plan und ein Unter-Issue pro Repo bekommt. Du entscheidest immer noch, was läuft; Aerunit übernimmt das "Was kommt als Nächstes", sobald ein Blocker gemergt wird.