Agent-fan-out en git worktrees: parallel bouwen zonder botsingen

Het patroon: één parent, meerdere schrijvende children

Muse Code hanteert een simpele regel: valt een klus uiteen in meerdere losse taken, dan waaieren die taken automatisch uit naar aparte agents. De parent-agent start per taak één child die zelf mag schrijven. Daar hoef je niets voor te configureren en er bestaat geen aparte parallelmodus — opsplitsen en verdelen is gewoon het standaardgedrag zodra het werk groot genoeg is om ervan te profiteren.

De voor de hand liggende vraag dringt zich meteen op: als meerdere agents tegelijk code kunnen schrijven, in dezelfde repository, waarom eindigt dat dan niet in merge-conflicten en overschreven bestanden?

Een echte fan-out-sessie: zes taken op één game, vier gemerged, twee nog bezig — elk in een eigen worktree onder .muse/worktrees/, terwijl de hoofdcheckout onaangeroerd blijft.

Worktrees: isolatie op de git-eigen manier

Elke child-agent krijgt een eigen git worktree — een aparte checkout van de repository die de historie deelt met je hoofdkopie, maar een eigen werkmap en een eigen branch heeft. Twee children kunnen in hun respectievelijke worktrees hetzelfde bestand bewerken zonder ooit elkaars tussentijdse wijzigingen te zien. Een botsing kan structureel simpelweg niet optreden.

Minstens zo belangrijk: jouw werkkopie blijft schoon. De map die je in je editor open hebt staan is nooit de map waarin een agent aan het rommelen is. Er verschuift niets onder je cursor, er duikt geen half afgemaakte agent-edit op in je diff, en het werk van een agent weggooien is niet duurder dan zijn worktree verwijderen. Wijzigingen bereiken jouw branch pas als het werk af is en beoordeeld.

Waarom niet gewoon branches? Of containers?

Kale branches delen één werkmap — halverwege een taak van branch wisselen zou het tapijt onder een draaiende agent vandaan trekken. Volledige containers of repo-clones zouden werken, maar zijn log: dubbele object stores, trage setup, onhandig mergen. Worktrees zitten precies in de sweet spot. Ze zijn vrijwel instant aangemaakt, delen de onderliggende git-objectdatabase, en de afgeronde branch van een child terugmergen is doodgewone git — geen eigen synchronisatielaag om te vertrouwen, geen proprietary state om te debuggen.

Zes features tegelijk, aantoonbaar

De launchdemo’s leunden zwaar op dit mechanisme: in het gamedevelopment-voorbeeld bouwde Muse Code zes gamefeatures tegelijkertijd, elke agent in zijn eigen worktree, en elke branch mergede schoon. Dat is de praktische winst — de doorlooptijd van een sprint met meerdere features zakt richting de duur van de langste losse taak, in plaats van de som van allemaal.

Probeer het recept

Agent-fan-out is een van de drie patronen waarvoor Meta cookbook-recepten meelevert — splits één grote klus op over subagents zodat er onderweg niets botst. In het cookbook staat de uitvoerbare versie. En omdat uitgewaaierd werk precies het soort werk is dat je later wilt kunnen controleren, wordt elke spawn, tool call en merge van elke child vastgelegd in het event log — niets gebeurt buiten de boeken om, alleen maar omdat het parallel gebeurde.