Hierdie week het Meta Muse Code vrygestel, ’n terminaalgebaseerde koderingsagent wat op sy Muse Spark 1.2-model gebou is en dit in direkte mededinging met Anthropic se Claude Code, OpenAI se Codex en Cursor plaas. Die kernboodskap, in Mark Zuckerberg se eie woorde, is dat dit "volledige sagteware-ingenieurstake oor groot repos aanpak: veranderinge beplan, kode skryf en die resultate valideer." Die besonderheid waaroor ’n mens moet nadink, is hoe dit groot take hanteer: "Wanneer ’n taak groot genoeg is, versprei dit die werk na afsonderlike subagente wat parallel in geïsoleerde werkbome werk. Jou werkkopie word nooit aangeraak nie." Zuckerberg het beweer dat ’n toetslopie dit "ses kenmerke vir ’n speletjie gelyktydig sonder botsings laat bou het" — ’n verskafferseis, nie ’n onafhanklik geverifieerde maatstaf nie, dus moet die spesifieke getal skepties benader word. Die patroon daaragter is egter werklik: dit is nou die standaardboodskap in die bedryf, nie net ’n Meta-kenmerk nie.

Wat beteken dat die onderskeid tussen hierdie nutsmiddels vinnig kleiner word. Beplan, kodeer, valideer, paralleliseer — elke groot laboratorium beweeg na dieselfde vierstap-lus. As jy ’n loopbaan bou rondom "Ek is goed daarmee om ’n agent die werk te laat doen," word daardie vaardigheid intyds deur die verskaffers self gekommoditiseer. Die ding wat nie gekommoditiseer word nie, en wat geeneen van hierdie bekendstellings werklik oplos nie, is wat ná die verspreiding gebeur: iemand moet steeds besluit of ses stukke kode wat parallel geskryf is deur ses subagente wat nie mekaar se werk kon sien nie, elk korrek en gesamentlik samehangend is.

Geïsoleerde werkbome los ’n samesmeltingskonflikprobleem op, nie ’n korrektheidsprobleem nie

Om subagente in afsonderlike werkbome te laat loop, is ’n werklike ingenieursverbetering — dit keer dat een agent ’n ander een se wysigings oorskryf. Maar dit beteken ook dat die agente wat daardie ses kenmerke bou, geen insig in mekaar se besluite gehad het terwyl hulle gewerk het nie. As twee van hulle onafhanklik ’n soortgelyke helperfunksie bygevoeg het, effens verskillende valideringslogika vir dieselfde invoer ingestel het, of onversoenbare aannames oor ’n gedeelde datastruktuur gemaak het, vang isolasie dit nie op nie — dit stel die botsing uit van ’n "samesmeltingskonflik" na ’n "integrasiefout wat vrygestel word". Dit is ’n struktureel ander mislukkingsmodus as die een wat hierdie nutsmiddels ontwerp is om te voorkom, en dit is die een wat ’n mens nou moet raaksien.

Dit is die moeite werd om hier presies te wees, want dit is maklik om "die agent het sy eie uitvoer gevalideer" met "die uitvoer is gevalideer" te verwar. Dat ’n agent nagaan of sy kode saamstel en die toetse slaag wat hy self geskryf het, is nie dieselfde as dat ’n beoordelaar vra of ses parallelle veranderinge konsekwent is met mekaar en met die res van die kodebasis nie. Dit is verskillende take, en slegs een daarvan is wat hierdie harnasse werklik verkoop.

Die vaardigheid wat werklik skaars word

As jy in of rondom sagteware werk — as ingenieur, PM, QA, tegniese ondersteuningspersoon, of selfs nou as ’n nie-ingenieur wat klein nutsmiddels met hierdie agente lewer — is die praktiese implikasie dat "die hersiening van multi-lêer-, multi-agent-uitvoer vir konsekwentheid" besig is om ’n eie dissipline te word, onderskei van kode skryf en onderskei van ’n agent goed aanspoor. ’n Paar konkrete dele daarvan:

  • Vertrouekalibrasie. Om, voordat jy ’n enkele reël lees, te weet watter soort verandering ’n noukeurige deurloop benodig (enigiets wat gedeelde toestand, ’n API-kontrak of iets raak waaraan meer as een subagent moontlik ook gewerk het) teenoor watter soort veilig vinnig deurgelees kan word.
  • Kruisverskil-lees. Wanneer ’n taak in parallelle werk versprei word, is die hersieningseenheid nie een verskil nie — dit is die stel verskille saam. Dit beteken dat ’n mens doelbewus moet kyk vir gedupliseerde logika, uiteenlopende gedrag vir dieselfde invoer, en inkonsekwente benamings of aannames oor die verskillende dele heen, eerder as om net elke lêer afsonderlik te lees.
  • Spesifikasieskryfwerk vir ’n onbewaakte uitvoerder. Die stroomop-oplossing vir botsingsrisiko is ’n taakbeskrywing wat presies genoeg is dat parallelle agente nie hoef te koördineer nie, omdat hul grense in die eerste plek korrek getrek is. Om so ’n spesifikasie te skryf, is nader aan ’n stelselontwerpvaardigheid as aan ’n aansporingsvaardigheid.

Niks hiervan is in die abstrakte sin nuut nie — kodehersiening en koppelvlakontwerp was nog altyd belangrik. Wat nuut is, is die volume en die blinde kol: wanneer een persoon ses parallelle werkstrome in ’n middag kan aktiveer, skaal die hoeveelheid kruisliggende hersiening wat nodig is daarmee, maar die nutsmiddels om kruisliggende hersiening maklik te maak, het nie tred gehou met die nutsmiddels wat parallelle generering maklik maak nie.

Wat om hierdie maand werklik daaromtrent te doen

As jou span een van hierdie harnasse loods — Muse Code, Claude Code, Codex of ’n mededinger — is ’n paar laekoste-stappe die moeite werd om nou te doen, voordat gewoontes stol:

  • Wanneer jy agentgegenereerde werk hersien, vra uitdruklik "het enigiets anders in hierdie taak aan dieselfde lêer, funksie of gedeelde tipe geraak?" voordat jy goedkeur — die meeste hersieningskontrolelyste vra nie hiervoor nie, omdat hulle vir verskille deur ’n enkele outeur geskryf is.
  • As jou span nie ’n geskrewe spesifikasieformaat het om take aan ’n agent oor te dra nie, bied aan om een op te stel. Die persoon wat "hoe ons die agent inlig" besit, kry uiteindelik buite verhouding veel invloed op hoeveel hersieningskuld die span later opbou.
  • Bly vertroud met meer as een van hierdie harnasse eerder as om jou vaardigheid te verpand aan die een wat jou huidige werkgewer gekies het. Hulle tree genoegsaam verskillend op — in werkboombestuur, in hoe aggressief hulle paralleliseer, en in wat hulle vir hersiening uitlig — dat ’n latere koue oorskakeling werklike tyd kos.

Die opskrif uit hierdie bekendstellingsiklus sal gaan oor watter laboratorium se agent die vinnigste of goedkoopste is. Die meer blywende loopbaansignaal is stiller: die maatskappye wat hierdie nutsmiddels lewer, optimaliseer almal uitdruklik vir meer kode, vinniger gegenereer, in parallel. Tot dusver lewer hulle nie ’n ooreenstemmend beter manier om daardie kode vir konsekwentheid na te gaan nie. Daardie gaping is waar die volgende rondte aanstellingsvraag gaan verskyn, en dit sal as ’n hersienings- en stelseldenkvaardigheid verskyn, nie as ’n aansporingsvaardigheid nie.