Deze week bracht Meta Muse Code uit, een op de terminal gebaseerde codeeragent die is gebouwd op Meta's Muse Spark 1.2-model en daarmee rechtstreeks concurreert met Claude Code van Anthropic en Codex van OpenAI. De opvallendste functie is niet de kwaliteit van het model — het is de architectuur. Zoals Mark Zuckerberg het beschreef: "wanneer een taak groot genoeg is, wordt die opgesplitst in afzonderlijke subagents die parallel werken in geïsoleerde worktrees. Je werkende kopie wordt nooit aangeraakt." Hij zei dat Meta's eigen tests hadden laten zien dat de tool tegelijkertijd zes functies voor een game kon bouwen zonder conflicten.

Neem die specifieke bewering met de nodige voorzichtigheid — het is het verslag van een leverancier over zijn eigen interne test, geen onafhankelijk geverifieerde benchmark, en "bèta" betekent dat de ruwe kantjes nog niet zijn gladgestreken. Maar de richting staat eigenlijk niet ter discussie, want het gaat niet alleen om Meta. Claude Code en Codex hebben zich dezelfde kant op ontwikkeld: één instructie erin, meerdere geïsoleerde werkstromen eruit, elk een kandidaat-diff die op een beslissing wacht. Dat drie afzonderlijke leveranciers naar dezelfde vorm van tool convergeren, is een sterker signaal dan welke marketingclaim van hen ook.

Het knelpunt verschuift, het verdwijnt niet

De afgelopen twee jaar ging het gesprek over loopbanen rond AI-codeertools vooral over de vraag of ze de persoon vervangen die de code schrijft. Het patroon met parallelle agents roept een stillere, directere vraag op: wie beoordeelt zes gelijktijdige diffs goed genoeg om degene te ontdekken die subtiel fout is? Eén functie schrijven en één pull request beoordelen zijn verschillende vaardigheden, maar ze bevinden zich tenminste op dezelfde schaal. Eén instructie schrijven en zes parallelle outputs beoordelen is dat niet — de beoordelingsstap is nu het onderdeel van de lus dat niet sneller wordt alleen omdat het model beter is geworden.

Dat is een echte verschuiving in wat schaars is. Als een agent een taak kan opsplitsen in geïsoleerde worktrees en meerdere complete pogingen kan produceren, ligt de beperking op het uitbrengen niet langer bij het genereren — maar bij jouw vermogen om diffs te lezen, het conflict te zien dat de tool heeft gemist en te beslissen welke van meerdere aannemelijke implementaties je daadwerkelijk in productie wilt hebben. Teams die dit opvatten als "de AI doet nu het codeerwerk" en niet investeren in die beoordelingscapaciteit, zullen de versie uitbrengen die er op het eerste gezicht goed uitzag, niet de versie die goed was.

Wat er daadwerkelijk moeilijker wordt

Kwaliteit van de specificatie. Wanneer één agent één output produceert, wordt een vage instructie verduidelijkt door heen-en-weer te overleggen. Wanneer een instructie zich vertakt naar zes parallelle subagents voordat je iets ziet, wordt de ambiguïteit zes keer zo groot in plaats van één keer opgelost. De instructie die je schrijft voordat je een taak met fan-out start, moet nu het werk doen dat vroeger in het vervolggesprek gebeurde.

Verificatie op snelheid. Zes diffs zorgvuldig lezen, één voor één, doet het doel van parallelisering van het werk teniet. De vaardigheid die de moeite waard is om op te bouwen, is snelle, gestructureerde triage: weten welke van de zes je regel voor regel moet lezen, welke je steekproefsgewijs tegen tests moet controleren en welke je alleen al op basis van een onderbuikgevoel moet verwerpen — zonder degene weg te gooien die daadwerkelijk correct was.

Oordeel over samenvoegen en integratie. "Geïsoleerde worktrees, geen conflicten" beschrijft de git-mechanica, niet de productlogica. Twee functies kunnen probleemloos worden samengevoegd en elkaar toch tegenspreken — de cachewijziging van de ene agent kan stilletjes de oplossing voor de dataversheid van een andere ondermijnen. Dat opmerken vereist iemand die het systeem als geheel begrijpt, niet alleen de diff die voor hem ligt.

Wat je deze week daadwerkelijk moet doen

  • Als je team al een agentische codeertool gebruikt, probeer die dan een taak te geven die expliciet is afgebakend om zich op te splitsen in 2–3 subagents in plaats van één. Let op hoeveel tijd je besteedt aan het schrijven van de eerste instructie versus het beoordelen van de output — die verhouding is wat aan het verschuiven is.
  • Oefen met het schrijven van acceptatiecriteria voordat je een taak start, niet nadat je het resultaat hebt gezien. "Splits op en kies de beste" werkt alleen als je vooraf hebt bepaald wat "beste" betekent.
  • Als je aan het begin van je loopbaan staat en bang bent dat dit je baan kleiner maakt, bekijk het dan anders: het vermogen om de diff van een onbekende snel en correct te lezen, aangescherpt gedurende maanden van codebeoordeling, is nu een rechtstreeks te gelde te maken vaardigheid in plaats van een klus die hoort bij een meer senior titel.
  • Als je een team aanstuurt, weersta dan de neiging om tijdens deze overgang de output te meten aan het aantal functies dat per week wordt uitgebracht. Een team dat agressief opsplitst maar onzorgvuldig beoordeelt, zal er snel uitzien tot de week waarin er iets in productie stukgaat.

Niets hiervan vereist dat je Meta's bewering over zes functies tegelijk zonder meer gelooft, of dat je een winnaar kiest tussen Muse Code, Claude Code en Codex. Het vereist dat je opmerkt dat drie goed gefinancierde labs onafhankelijk van elkaar besloten dat de volgende knop om aan te draaien parallellisme was, niet alleen ruwe modelkwaliteit — en dat je je eigen vaardigheidsontwikkeling plant rond het knelpunt dat daardoor ontstaat, in plaats van rond het knelpunt dat al voor je wordt opgelost.