Du übergibst einen Bug an Claude Code und ein kleines Feature an Codex, gehst weg und kommst zu einer Datei zurück, die falsch aussieht. Die Änderung eines Agenten fehlt. Oder beide Änderungen sind da und der Build schlägt fehl. Oder, schlimmer noch, alles kompiliert und ein Test bricht an einer Stelle, die keiner der Agenten angefasst hat. Nichts ist abgestürzt, während du weg warst. Beide Agenten haben die Arbeit erledigt, um die du gebeten hast. Die Datei konnte nicht zwei Autoren gleichzeitig halten, und niemand hat dir gesagt, wer gewonnen hat.
Diese Stille ist das eigentliche Problem. Eine Datei ist kein Merge-Tool. Wenn zwei Coding-Agenten zu überlappenden Zeiten in dasselbe Verzeichnis in auth.ts schreiben, gibt es keinen Lock, keine Queue, keine Warnung; es gibt nur den Prozess, der zuletzt gespeichert hat. Dieser Artikel geht die Kollision Schritt für Schritt durch, benennt den Fehlermodus in jedem Stadium und endet mit einer Checkliste, die du vor deiner nächsten parallelen Sitzung durchgehen kannst.
Er zeigt außerdem auf den Workflow, zu dem diese Fixes führen. Sharkly ist eine All-in-One-Plattform für Agenten-Steuerung und -Management, die über den Coding-Agenten sitzt, die du bereits betreibst. Sie gibt jedem Task seinen eigenen isolierten Worktree und hält Kontext, Fortschritt, Blocker, Ergebnisse und menschliches Review von der Anfrage bis zum Release sichtbar. Du kannst dieselbe Disziplin von Hand mit reinem Git aufbauen, und der Großteil dieses Artikels zeigt dir, wie. Der letzte Abschnitt dreht sich darum, wann sich die Handarbeit nicht mehr auszahlt.
Es gibt keinen Lock: Wer zuletzt schreibt, gewinnt
Beginne mit der schlimmsten Variante, denn sie ist die häufigste und die am wenigsten sichtbare. Beide Agenten laufen im selben Arbeitsverzeichnis. Agent A liest auth.ts, plant eine Änderung und beginnt zu schreiben. Agent B liest dieselbe auth.ts eine Sekunde später, plant eine andere Änderung gegen die Version, die er gelesen hat, und schreibt ebenfalls.
Keiner hat die Änderung des anderen gelesen, weil die Änderung noch nicht gespeichert war, als sie gelesen haben. Wer zuletzt speichert, überschreibt die Datei auf der Festplatte mit einer Version, die die Arbeit des ersten Agenten nie enthielt. Das ist Last Write Wins, und es ist still. Es gibt keinen Konfliktmarker, keinen Fehler, keinen Exit-Code. Agent A meldet Erfolg. Agent B meldet Erfolg. Einer von beiden belügt dich und weiß es nicht.
Das Wettrennen um die Lock-Datei ist derselbe Fehler an einer kostspieligeren Stelle. Agent A führt npm install aus und schreibt package-lock.json neu; Agent B, mitten in der Installation, schreibt sie erneut aus einem anderen Ausgangszustand neu. Das Ergebnis ist eine Lock-Datei, die zu keinem der beiden Dependency-Bäume passt, und der Bruch taucht Tage später auf dem Rechner von jemand anderem auf. Gemeinsame Build-Ausgaben, ein einzelner Dev-Server-Port und ein globaler Cache versagen auf dieselbe Weise.
Die Lösung ist kein klügerer Agent. Es ist, jedem Agenten einen eigenen Raum zu geben.
Eine Arbeitskopie pro Agent: Aus dem stillen Überschreiben wird ein sichtbarer Konflikt
Ein Git-Worktree ist eine zweite ausgecheckte Kopie eines Repositorys, auf einem eigenen Branch, die einen einzigen .git-Object-Store teilt. Jeder Agent bekommt ein echtes Verzeichnis zum Bearbeiten, Bauen und Testen, ohne die laufende Arbeit eines anderen zu sehen.
# From the main repo
git worktree add ../repo-agent-a -b agent/auth-refactor
git worktree add ../repo-agent-b -b agent/session-timeout
Richte Agent A auf ../repo-agent-a und Agent B auf ../repo-agent-b aus. Jetzt sind A's ungespeicherte Änderungen an auth.ts für B unsichtbar, und kein Agent kann die Datei des anderen auf der Festplatte überschreiben, weil sie zwei verschiedene Dateien auf zwei verschiedenen Branches bearbeiten. Das Worktree-Modell wird ausführlicher behandelt in Git-Worktrees für KI-Coding-Agenten und Coding-Agent-Worktrees: ein Checkout pro Task.
Beachte, was die Isolierung hier bewirkt hat. Sie hat nicht verhindert, dass die beiden Agenten dieselbe Datei bearbeiten. Sie hat einen stillen Datenverlust in einen sichtbaren Merge-Konflikt verwandelt, in dem Moment, in dem die Branches wieder zusammenkommen. Das ist eine echte Verbesserung: Git hält an und zeigt dir die genauen Zeilen, die nicht übereinstimmen, und du löst sie mit vollem Blick auf beide Versionen auf. Ein Konflikt, den du sehen kannst, ist ein Problem, das du beheben kannst. Das Überschreiben, das du nicht sehen konntest, war das, das ausgeliefert wurde.
Eine Grenze, die es wert ist, klar benannt zu werden: Worktrees isolieren Dateien, nicht Nebenwirkungen. Eine gemeinsame Datenbank, ein einzelner Port oder ein fest codierter Ausgabepfad kollidieren weiterhin über Worktrees hinweg. Isoliere auch diese, oder serialisiere die Agenten, die sie brauchen.
Der Konflikt, den du nicht sehen kannst
Hier ist der Fehlermodus, der die Isolierung überlebt. Agent A benennt in seinem eigenen Worktree getUser() in fetchUser() um und aktualisiert jede Aufrufstelle, die ihm gehört. Agent B schreibt gleichzeitig in seinem eigenen Worktree drei neue Aufrufstellen für getUser(), weil das der Funktionsname war, als B die Datei gelesen hat.
Beide Branches mergen mit null Konfliktmarkern. Git vergleicht Zeilen, und Zeile für Zeile hat sich nichts überlappt: A hat seine Dateien geändert, B hat neue hinzugefügt. Der Merge ist sauber. Dann bricht der Build an einem undefinierten getUser, oder er kompiliert und schlägt zur Laufzeit fehl, wo der Type-Checker nicht hinreichen konnte. Kein Tool hat es markiert, weil textuell keine Kollision vorlag. Die beiden Änderungen waren sich über die Bedeutung der Datei uneinig, nicht über ihren Text.
Deshalb ist „isoliere einfach die Agenten" nicht die ganze Antwort. Isolierung verschiebt eine Same-File-Kollision zu einer Same-Interface-Kollision, und die zweite Art versteckt sich besser als die erste. Der Hebel hier ist Task-Scoping, nicht Tooling. Eine nützliche Regel: Wenn du zwei Aufgaben von Agenten nicht beschreiben kannst, ohne dieselbe Datei oder dieselbe Funktion zu nennen, sind sie eine Aufgabe, nicht zwei. Arbeit entlang von Modulgrenzen aufzuteilen ist der größte Teil dessen, was Claude Code und Codex gemeinsam auf einer Codebasis laufen zu lassen davon abhält, in einen Debugging-Nachmittag auszuarten. Wenn zwei Tasks wirklich eine Schnittstelle teilen, serialisiere sie, oder merge und rebase zwischen den Schritten, damit der zweite Agent die Realität des ersten Agenten liest.
Wo das DIY-Setup nicht mehr skaliert, und was ein Task-Board hinzufügt
Zwei Agenten und eine geteilte Datei kannst du von Hand verwalten: zwei Worktrees, sorgfältiges Scoping, ein Merge, den du beobachtest. Die Methode hält, bis das Zählen schwierig wird. Welcher Agent ist auf welchem Branch. Welcher Worktree gehört zu welchem Task. Welcher von fünf sauberen Merges hat still eine geteilte Schnittstelle verändert. Welche Branches warten auf dein Review, und welche hast du schon angesehen. Die Git-Befehle wurden nie schwieriger; die Buchhaltung drumherum wurde es, und genau dort rutschen Same-File-Kollisionen durch, weil du einen Merge genehmigt hast, den du nicht vollständig gelesen hast.
Ein Task-Board ändert, was du verfolgst. Statt einer Wand von Terminals und losgelösten Worktrees ist jede Arbeitseinheit ein Task mit einem Owner, einem Branch und einem Status. In Sharkly bekommt ein Task automatisch seinen eigenen isolierten Worktree, sodass Isolierung auf Dateiebene der Standard ist statt eines Befehls, den du dich zu erinnern musst auszuführen. Ausführung, Blocker und Ergebnisse kehren zum Task zurück, sodass du eine Änderung gegen ihren angegebenen Umfang prüfst, statt die Absicht aus einem Diff zurückzuentwickeln. Und die Arbeitsteilung bleibt fest: Agenten recherchieren, führen aus, testen und berichten; Menschen setzen die Richtung, erteilen die Befugnis und akzeptieren das Ergebnis. Automatisierung endet dort, wo Team-Urteilsvermögen gefragt ist.
Das ist der letzte Punkt, den Isolierung allein nie löst. Bessere Tools machen Isolierung und Merging einfacher, aber Review skaliert nicht mit der Anzahl der Agenten; es skaliert mit deiner Aufmerksamkeit, und menschliches Review ist der echte Engpass bei paralleler Agentenarbeit. Fünf Agenten produzieren fünf Branches in der Zeit, in der du einen sorgfältig liest. Ein Task-Board liest den Code nicht für dich. Es hält die Queue ehrlich, damit die plausibel aussehende Änderung nicht überflogen und gemergt wird, weil du den Überblick verloren hast, in welchem Stapel sie lag. Dieselbe Konfliktmathematik taucht auch auf Repository-Ebene auf, behandelt in mehrere Coding-Agenten im selben Repository.
Du kannst das mit Worktrees und Disziplin aufbauen oder Sharkly nutzen, um den Workflow zu verwalten. Wenn du bereits mehrere Agenten laufen lässt, liegt der Wert darin, einen Ort zu haben, an dem ihre Tasks und Ergebnisse leben, statt über Terminals verstreut zu sein.
Die Checkliste für deine nächste parallele Sitzung
Geh das durch, bevor du zwei Agenten auf irgendetwas richtest:
- Gib jedem Agenten seinen eigenen Worktree. Niemals zwei Agenten in einem Arbeitsverzeichnis.
git worktree add ../repo-<task> -b agent/<task>pro Task. Siehe parallele Agenten in isolierten Worktrees. - Scope die Tasks so, dass sie nicht dieselbe Datei oder Funktion nennen. Wenn sie es müssen, ist das ein Task; serialisiere ihn.
- Isoliere Nebenwirkungen, nicht nur Dateien. Getrennte Datenbanken, Ports, Ausgabepfade und Caches, oder serialisiere die Agenten, die sie teilen.
- Rebase vor dem Merge, wenn zwei Branches gegen denselben Ausgangs-Commit liefen, damit die Arbeit des zweiten Agenten auf der des ersten sitzt.
- Führe die Typ-Prüfung und die vollständige Testsuite nach jedem Merge aus, nicht erst nach dem letzten. Semantische Konflikte bestehen einen sauberen Merge und scheitern hier.
- Prüfe jeden Branch gegen den Umfang seines Tasks, einen nach dem anderen. Ein Stapel ungelesener grüner Häkchen ist der Ort, an dem der unsichtbare Konflikt ausgeliefert wird.
Zwei Agenten, die eine Datei bearbeiten, sind kein seltener Randfall; es ist das, wie parallele Arbeit aussieht, in dem Moment, in dem sich deine Tasks um einen Zentimeter überlappen. Plane die Kollision ein, mach sie sichtbar, und lass eine Person entscheiden, was gemergt wird.
