Deze week bracht Meta Muse Code uit, een codeeragent voor de terminal die is gebouwd op Meta's Muse Spark 1.2-model, waarmee het rechtstreeks de concurrentie aangaat met Anthropic's Claude Code, OpenAI's Codex en Cursor. De pitch is, in de woorden van Mark Zuckerberg zelf, dat het "complete software engineering tasks across large repos: planning changes, writing code, validating the results" uitvoert. Het detail waar je bij stil moet staan, is hoe het grote opdrachten aanpakt: "When a job is big enough, it fans out to separate sub-agents working in parallel in isolated worktrees. Your working copy is never touched." Zuckerberg beweerde dat het tijdens een test "build six features for a game simultaneously with no collisions" had — een claim van de leverancier, geen onafhankelijk geverifieerde benchmark, dus neem het specifieke aantal met scepsis. Het patroon erachter is wel echt: dit is inmiddels de standaardpitch in de hele sector, niet iets wat alleen Meta biedt.

Dat betekent dat het onderscheid tussen deze tools snel kleiner wordt. Plannen, coderen, valideren, paralleliseren — elk groot lab komt uit op dezelfde lus in vier stappen. Als je een carrière opbouwt rond "ik ben goed in een agent het werk laten doen", wordt die vaardigheid in real time door de leveranciers zelf tot een commodity gemaakt. Wat niet tot een commodity wordt gemaakt, en wat geen van deze lanceringen daadwerkelijk oplost, is wat er gebeurt na de fan-out: iemand moet nog steeds beslissen of zes stukken code die parallel zijn geschreven door zes subagents die elkaars werk niet konden zien, afzonderlijk correct en gezamenlijk coherent zijn.

Geïsoleerde worktrees lossen een merge-conflictprobleem op, geen correctheidsprobleem

Subagents in afzonderlijke worktrees laten draaien is een echte technische verbetering — het voorkomt dat de ene agent de wijzigingen van de andere overschrijft. Maar het betekent ook dat de agents die deze zes features bouwden tijdens hun werk geen enkel zicht hadden op elkaars beslissingen. Als twee van hen onafhankelijk dezelfde soort helperfunctie toevoegden, iets verschillende validatielogica voor dezelfde invoer introduceerden of onverenigbare aannames over een gedeelde datastructuur maakten, vangt isolatie dat niet op — het stelt de botsing uit van een "merge conflict" naar een "integratiebug die wordt uitgebracht". Dat is een structureel ander faalmechanisme dan het mechanisme dat deze tools moesten voorkomen, en het is het mechanisme dat een mens nu moet opmerken.

Hierover moet je precies zijn, omdat het gemakkelijk is om "de agent heeft zijn eigen uitvoer gevalideerd" te verwarren met "de uitvoer is gevalideerd". Een agent die controleert of zijn code compileert en slaagt voor de tests die hij zelf heeft geschreven, is niet hetzelfde als een reviewer die vraagt of zes parallelle wijzigingen consistent zijn met elkaar en met de rest van de codebase. Dat zijn verschillende taken, en slechts één daarvan is wat deze harnesses daadwerkelijk verkopen.

De vaardigheid die daadwerkelijk schaars wordt

Als je in of rond software werkt — als engineer, PM, QA, in technische ondersteuning, of nu zelfs als niet-engineer die met deze agents kleine tools uitbrengt — dan is de praktische implicatie dat "multi-file-, multi-agentuitvoer op consistentie controleren" uitgroeit tot een eigen discipline, los van code schrijven en los van een agent goed aansturen. Een paar concrete onderdelen ervan:

  • Vertrouwenskalibratie. Weten welk soort wijziging een zorgvuldige controle nodig heeft voordat je ook maar één regel hebt gelezen (alles wat gedeelde toestand of een API-contract raakt, of iets wat mogelijk door meer dan één subagent is aangeraakt), tegenover welk soort wijziging je veilig vluchtig kunt doornemen.
  • Cross-diff lezen. Wanneer een taak zich vertakt in parallel werk, is de revieweenheid niet één diff — het is de verzameling diffs als geheel. Dat betekent dat je bewust controleert op dubbele logica, uiteenlopend gedrag bij dezelfde invoer en inconsistente naamgeving of aannames tussen de onderdelen, in plaats van elk bestand alleen te lezen.
  • Specificaties schrijven voor een uitvoerder zonder toezicht. De oplossing stroomopwaarts voor het botsingsrisico is een taakbeschrijving die precies genoeg is dat parallelle agents niet hoeven te coördineren, omdat hun grenzen vanaf het begin correct zijn getrokken. Zo'n specificatie schrijven lijkt meer op een systeemontwerpvaardigheid dan op een promptvaardigheid.

Niets hiervan is in abstracte zin nieuw — code review en interfaceontwerp zijn altijd al belangrijk geweest. Wat nieuw is, zijn het volume en de blinde vlek: wanneer één persoon in een middag zes parallelle werkstromen kan starten, schaalt de hoeveelheid benodigde cross-cutting review daarmee mee, maar de tooling om cross-cutting review eenvoudig te maken heeft de tooling die parallelle generatie eenvoudig maakt niet bijgebeend.

Wat je er deze maand daadwerkelijk aan kunt doen

Als je team een van deze harnesses aan het uitproberen is — Muse Code, Claude Code, Codex of een concurrent — zijn er een paar goedkope stappen die je nu kunt zetten, voordat gewoonten verharden:

  • Vraag bij het beoordelen van door agents gegenereerd werk vóór goedkeuring expliciet: "heeft iets anders in deze taak hetzelfde bestand, dezelfde functie of hetzelfde gedeelde type aangeraakt?" — de meeste reviewchecklists vragen hier niet naar, omdat ze voor diffs van één auteur zijn geschreven.
  • Als je team geen geschreven specificatie-indeling heeft voor het overdragen van taken aan een agent, bied dan aan er een op te stellen. Degene die eigenaar is van "hoe we de agent briefen" krijgt uiteindelijk onevenredig veel invloed op hoeveel reviewschuld het team later opbouwt.
  • Blijf vertrouwd met meer dan één van deze harnesses, in plaats van je vaardigheid te verbinden aan degene die je huidige werkgever heeft gekozen. Ze verschillen genoeg — in de manier waarop ze met worktrees omgaan, in hoe agressief ze parallelliseren en in wat ze ter review aanbieden — dat later onvoorbereid overstappen echt tijd kost.

De kop uit deze lanceringscyclus zal gaan over welk lab de snelste of goedkoopste agent heeft. Het duurzamere carrièresignaal is stiller: de bedrijven die deze tools uitbrengen, optimaliseren allemaal expliciet voor meer code, sneller en parallel gegenereerd. Tot nu toe brengen ze niet een overeenkomstig betere manier uit om die code op consistentie te controleren. In die kloof zal de volgende ronde van de vraag naar personeel zichtbaar worden, en die zal zich uiten als een vaardigheid in review en systeemdenken, niet als een promptvaardigheid.