Toen Meta deze week Muse Code lanceerde, ging de kop vooral over concurrentiepositionering: nog een terminal-gebaseerde codeeragent die zich bij Claude Code, Codex en Cursor voegt in de strijd om ontwikkelaarsworkflows. Maar verstopt in Mark Zuckerbergs eigen omschrijving van de tool zit het interessantere signaal voor iedereen die beroepsmatig code schrijft of reviewt.

"Als een taak groot genoeg is, wordt hij verdeeld over aparte subagents die parallel werken in geïsoleerde worktrees," schreef Zuckerberg, over de aanpak van Muse Code voor grote taken. "Je working copy wordt nooit aangeraakt. Tijdens het testen lieten we het zes features voor een game tegelijk bouwen, zonder botsingen."

Dat is geen productomschrijving. Het is een functieomschrijving — voor jou.

Wat "geïsoleerde worktrees" eigenlijk betekent

Met een git worktree kun je meerdere branches van dezelfde repository tegelijk uitchecken in aparte mappen, zodat verschillende werklijnen naast elkaar kunnen lopen zonder dat de ene checkout de andere in de weg zit. Muse Code gebruikt, volgens Meta, dit mechanisme om meerdere subagents tegelijk code te laten schrijven zonder je actieve working copy of elkaars bestanden aan te raken. Het is een verstandige technische keuze: botsingen op bestandsniveau zijn de makkelijkst mechanisch te voorkomen soort multi-agent-conflict, dus voorkom je die mechanisch en geef je het model de ruimte om zich op het daadwerkelijke coderen te richten.

Het woord om op te letten is "verdeeld". Een menselijke ontwikkelaar ervaart zes parallelle worktrees niet als zes codestromen die hij een voor een op zijn gemak kan nalopen — het zijn zes stromen die ongeveer tegelijk op zijn bureau belanden, waarbij elke stroom een beslissing vraagt: gaat dit erin, moet het worden overgedaan, botst het met iets wat een zusteragent zojuist in een andere worktree heeft gedaan.

De vaardigheid die daadwerkelijk verschuift

De afgelopen paar jaar was het dominante model van AI-ondersteund coderen conversationeel en enkelvoudig: één ontwikkelaar, één assistent, één heen-en-weer-draad, die min of meer in real time wordt beoordeeld terwijl hij ontstaat. Die vaardigheid — goed prompten, een slechte suggestie meteen opmerken, itereren — blijft nodig. Maar het is niet de vaardigheid waarop het ontwerp van Muse Code optimaliseert. Verdelen over subagents veronderstelt dat je al bent overgestapt op een andere manier van werken: een taak vooraf opsplitsen in stukken die onafhankelijk kunnen draaien, en vervolgens afgeronde (of half-afgeronde) output van meerdere agents tegelijk beoordelen in plaats van één agent stap voor stap aan te sturen.

Dat lijkt meer op een tech lead die een sprint over een klein team verdeelt dan op een pair programmer die het scherm deelt met een chatbot. De individuele codeerbeslissingen doen er minder toe dan de opsplitsing (heb je het werk verdeeld langs lijnen die daadwerkelijk onafhankelijk zijn?) en de reviewronde (kun je snel beoordelen of zes parallelle diffs elk afzonderlijk correct en gezamenlijk coherent zijn?).

Isolatie lost botsingen op, niet coherentie

Het is de moeite waard hierbij stil te staan, want het is makkelijk over het hoofd te zien: geïsoleerde worktrees voorkomen dat twee agents hetzelfde bestand overschrijven. Ze doen niets om te voorkomen dat twee agents onafhankelijk van elkaar twee verschillende manieren bedenken om hetzelfde te doen — een tweede hulpfunctie voor datumopmaak, een tweede retry-wrapper, een dubbele API-route — omdat geen van beide agents kon zien wat de ander aan het bouwen was. Git-isolatie is een garantie op bestandssysteemniveau, geen ontwerpgarantie. De reviewer die zes worktrees weer samenvoegt, is het enige controlepunt waar een gedupliceerde abstractie, een inconsistente naamgevingsconventie, of twee features die stilzwijgend van verschillende datastructuren uitgaan, aan het licht komen. Als die reviewer diffs vluchtig doorneemt omdat het volume aan parallelle output het tempo van zorgvuldig lezen overtreft, is dit precies het soort afwijking dat de productie haalt.

Dat verandert wat "codereview" moet betekenen zodra tools die werk verdelen de norm worden: minder regel-voor-regel inspectie van een individuele diff (de syntax van de agent klopt meestal wel), meer afstemming tussen diffs onderling — controleren of parallelle stromen AI-gegenereerd werk het met elkaar eens zijn over gedeelde conventies, gedeelde datamodellen en gedeelde foutafhandeling.

Waar je daadwerkelijk naartoe moet werken

Niets hiervan vereist specifiek Muse Code — hetzelfde verdeelpatroon duikt op bij alle grote codeeragents, wat erop wijst dat het een standaardarchitectuur wordt in plaats van een gok van één leverancier. Een paar concrete dingen die het waard zijn om nu al te oefenen, ongeacht welke tool je gebruikt:

  • Schrijf taakspecificaties die zich netjes laten opsplitsen. Voordat je om parallel werk vraagt, vraag jezelf af of de onderdelen werkelijk onafhankelijk zijn — raken ze dezelfde bestanden, dezelfde gedeelde constanten, hetzelfde API-contract? Zo ja, dan is dat geen taak voor zes parallelle agents; dan is het een taak voor één agent die sequentieel werkt, of voor jou om de gedeelde onderdelen eerst handmatig eruit te splitsen.
  • Oefen met reviewen op het samenvoegpunt, niet op het diffpunt. Wen eraan om meerdere afgeronde branches naast elkaar te leggen en jezelf af te vragen "komen deze met elkaar overeen," niet alleen "klopt elke branch afzonderlijk."
  • Ken de basis van git worktrees. Als de tools die je gebruikt hun interne werking op deze manier gaan beschrijven, is begrijpen wat een worktree wel en niet garandeert een absolute vereiste om de output te kunnen vertrouwen — of terecht te wantrouwen.
  • Maak expliciet wie eigenaar is van gedeelde zaken. Constanten, schema's, gedeelde hulpprogramma's, naamgevingsconventies. Hoe meer hiervan je vastlegt voordat het werk wordt verdeeld, hoe minder afstemmingswerk je achteraf hebt.

De mensen die het meeste uit tools als Muse Code halen, zijn niet degenen die het best prompten. Het zijn degenen die stilletjes goed zijn geworden in het leiden van een klein, snel, soms slordig team — zelfs wanneer elk lid van dat team een model is.