Parallele Agenten, null Merge-Konflikte: Wie Muse Code Git-Worktrees nutzt
Parallelität versprechen viele Tools — sicher machen sie kaum eines. Muse Code setzt auf eine alte, unspektakuläre Git-Technik, konsequent richtig eingesetzt.
Das Muster: ein Parent, viele schreibende Kinder
Muse Code folgt einer simplen Regel: Zerfällt ein Auftrag in mehrere eigenständige Teilaufgaben, verteilt er sich automatisch auf separate Agenten. Der Parent-Agent startet pro Aufgabe ein schreibfähiges Kind. Du konfigurierst dafür nichts und schaltest auch keinen speziellen Parallelmodus ein — Zerlegen und Verteilen ist das Standardverhalten, sobald die Arbeit groß genug ist, um davon zu profitieren.
Die naheliegende Frage drängt sich sofort auf: Wenn mehrere Agenten gleichzeitig im selben Repository Code schreiben dürfen — warum endet das nicht zwangsläufig in Merge-Konflikten und überschriebenen Dateien?
Eine echte Fan-out-Session: sechs Aufgaben an einem Spiel, vier gemergt, zwei laufen noch — jede in ihrem eigenen Worktree unter .muse/worktrees/, während der Haupt-Checkout unangetastet bleibt.
Worktrees: Isolation, wie Git sie vorsieht
Jeder Kind-Agent bekommt einen eigenen git worktree — einen separaten Checkout des Repositories, der die Historie mit deiner Hauptkopie teilt, aber ein eigenes Arbeitsverzeichnis und einen eigenen Branch besitzt. Zwei Kinder können dieselbe Datei in ihren jeweiligen Worktrees bearbeiten, ohne die halbfertigen Änderungen des anderen je zu Gesicht zu bekommen. Eine Kollision ist damit strukturell ausgeschlossen.
Mindestens genauso wichtig: Dein Arbeitsverzeichnis bleibt sauber. Das Verzeichnis, das du im Editor offen hast, ist nie das, in dem gerade ein Agent herumschreibt. Nichts bewegt sich unter deinem Cursor, kein halbfertiger Agenten-Edit taucht in deinem Diff auf — und die Arbeit eines Agenten zu verwerfen kostet nicht mehr, als seinen Worktree wegzuwerfen. Änderungen erreichen deinen Branch erst, wenn sie fertig und reviewt sind.
Warum nicht einfach Branches? Oder Container?
Gewöhnliche Branches teilen sich ein Arbeitsverzeichnis — ein Branch-Wechsel mitten in der Aufgabe würde einem laufenden Agenten den Boden unter den Füßen wegziehen. Vollwertige Container oder komplette Repo-Klone würden funktionieren, sind aber schwergewichtig: duplizierte Object-Stores, langsames Setup, umständliches Mergen. Worktrees treffen genau den Sweet Spot: Sie sind praktisch sofort erstellt, teilen sich die Git-Objektdatenbank — und den fertigen Branch eines Kindes zurückzumergen ist ganz normales Git. Keine eigene Sync-Schicht, der du vertrauen musst, kein proprietärer Zustand, den du debuggen müsstest.
Sechs Features gleichzeitig — nachweisbar
Die Launch-Demos haben genau diesen Mechanismus strapaziert: Im Spieleentwicklungs-Beispiel baute Muse Code sechs Features gleichzeitig, jeder Agent in seinem eigenen Worktree — und jeder Branch mergte sauber. Das ist der praktische Gewinn: Die Wanduhr-Zeit eines Multi-Feature-Sprints schrumpft auf die Dauer der längsten Einzelaufgabe zusammen, statt der Summe aller.
Probier das Rezept aus
Agent-Fan-out ist eines der drei Muster, für die Meta Cookbook-Rezepte mitliefert — ein großer Auftrag, verteilt auf Subagenten, ohne dass sich unterwegs irgendetwas in die Quere kommt. Die lauffähige Version findest du im Cookbook. Und weil verteilte Arbeit genau die Art von Arbeit ist, die du später auditieren willst: Jeder Spawn, jeder Tool-Call und jeder Merge eines Kindes landet im Event-Log — nichts passiert unter dem Radar, nur weil es parallel passiert ist.