Tällä viikolla Meta julkaisi Muse Coden, Muse Spark 1.2 -malliin perustuvan terminaalipohjaisen koodausagentin, joka asettuu suoraan kilpailemaan Anthropicin Claude Coden ja OpenAI:n Codexin kanssa. Pääominaisuus ei ole mallin laatu – vaan arkkitehtuuri. Kuten Mark Zuckerberg kuvaili sitä: ”kun työ on riittävän suuri, se haarautuu erillisiksi rinnakkain työskenteleviksi aliagenteiksi eristetyissä worktree-työpuissa. Työkopioosi ei koskaan kosketa.” Hän kertoi Metan omien testien osoittaneen työkalun rakentaneen kuusi pelin ominaisuutta samanaikaisesti ilman yhteentörmäyksiä.

Suhtaudu tähän nimenomaiseen väitteeseen sen ansaitsemalla varauksella – kyse on toimittajan kuvauksesta omasta sisäisestä testistään, ei riippumattomasti varmennetusta vertailutestistä, ja ”beta” tarkoittaa, ettei kaikkia särmiä ole vielä hiottu pois. Suuntaa ei kuitenkaan oikeastaan kyseenalaisteta, koska kyse ei ole vain Metasta. Claude Code ja Codex ovat kehittyneet samaan suuntaan: yksi ohje sisään, useita eristettyjä työvirtoja ulos, joista jokainen on päätöstä odottava ehdokasdiffi. Se, että kolme erillistä toimittajaa päätyy samaan työkalun muotoon, on vahvempi signaali kuin yhdenkään niistä markkinointiväitteet.

Pullonkaula siirtyy, ei katoa

Viimeisten kahden vuoden ajan tekoälypohjaisista koodaustyökaluista käydyssä urakeskustelussa on enimmäkseen pohdittu sitä, korvaavatko ne koodia kirjoittavan ihmisen. Rinnakkaisagenttien toimintamalli nostaa esiin hiljaisemman ja välittömämmän kysymyksen: kuka tarkistaa kuusi samanaikaista diffiä riittävän hyvin huomatakseen sen yhden, joka on hienovaraisesti väärin? Yhden ominaisuuden kirjoittaminen ja yhden PR:n tarkistaminen ovat eri taitoja, mutta ne ovat sentään samassa mittakaavassa. Yhden ohjeen kirjoittaminen ja kuuden rinnakkaisen tuotoksen tarkistaminen eivät ole – tarkistusvaihe on nyt silmukan osa, joka ei nopeudu vain siksi, että malli parani.

Kyse on aidosta muutoksesta siinä, mikä on niukkaa. Jos agentti voi haarauttaa tehtävän eristettyihin worktree-työpuihin ja tuottaa useita valmiita yrityksiä, ohjelmiston julkaisemisen rajoite ei enää ole tuottaminen – vaan kykysi lukea diffit, huomata työkalulta jäänyt yhteentörmäys ja päättää, mikä useista uskottavista toteutuksista on se, jonka todella haluat tuotantoon. Tiimit, jotka suhtautuvat tähän ajatellen ”tekoäly hoitaa nyt koodaamisen” ja jättävät investoimatta tarkistuskapasiteettiin, julkaisevat version, joka näytti ensi silmäyksellä oikealta, eivät versiota, joka oli oikea.

Mikä oikeastaan vaikeutuu

Määrittelyn laatu. Kun yksi agentti tuottaa yhden tuloksen, epämääräinen ohje täsmentyy edestakaisessa keskustelussa. Kun ohje haarautuu kuudelle rinnakkaiselle aliagentille ennen kuin näet mitään, epäselvyys kuusinkertaistuu sen sijaan, että se ratkaistaisiin kerralla. Ohjeen, jonka kirjoitat ennen haarautuvan tehtävän käynnistämistä, on nyt tehtävä se työ, joka ennen tapahtui jatkokeskustelussa.

Nopea varmennus. Kuuden diffiä huolellinen lukeminen yksi kerrallaan vesittää työn rinnakkaistamisen tarkoituksen. Rakennettava taito on nopea ja jäsennelty esikarsinta: tietää, mitkä kuudesta luetaan rivi riviltä, mitkä tarkistetaan pistokokein testejä vasten ja mitkä hylätään pelkän vaikutelman perusteella – hylkäämättä samalla sitä, joka oli oikeasti oikein.

Yhdistämistä ja integrointia koskeva harkinta. ”Eristetyt worktree-työpuut, ei yhteentörmäyksiä” kuvaa git-mekaniikkaa, ei tuotteen toiminnallista logiikkaa. Kaksi ominaisuutta voi yhdistyä siististi ja silti olla ristiriidassa keskenään – yhden agentin välimuutos voi huomaamatta heikentää toisen tietojen tuoreutta parantavaa korjausta. Tämän havaitseminen edellyttää jotakuta, joka ymmärtää järjestelmän kokonaisuutena, ei vain edessään olevaa diffiä.

Mitä tällä viikolla oikeasti kannattaa tehdä

  • Jos tiimisi käyttää jo agenttimaista koodaustyökalua, kokeile antaa sille tehtävä, joka on nimenomaisesti rajattu haarautumaan 2–3 aliagentille yhden sijaan. Huomaa, kuinka paljon aikaa käytät alkuperäisen ohjeen kirjoittamiseen verrattuna tuotoksen tarkistamiseen – tämä suhde on se asia, joka on muuttumassa.
  • Harjoittele hyväksymiskriteerien kirjoittamista ennen tehtävän käynnistämistä, ei sen jälkeen kun näet tuloksen. ”Haarauta ja valitse paras” toimii vain, jos määrittelit etukäteen, mitä ”paras” tarkoittaa.
  • Jos olet urasi alkuvaiheessa ja pelkäät tämän pienentävän työsi merkitystä, katso asiaa toisesta näkökulmasta: kyky lukea tuntemattoman tekijän diffi nopeasti ja oikein, kuukausien koodikatselmuksissa hioutuneena, on nyt suoraan rahaksi muutettavissa oleva taito eikä vain vaiva, joka liittyy korkeamman tason tehtävänimikkeeseen.
  • Jos johdat tiimiä, vastusta tuotoksen mittaamista tällä siirtymäkaudella viikossa julkaistujen ominaisuuksien määrällä. Aggressiivisesti haarautuva mutta huolimattomasti tarkistava tiimi näyttää nopealta aina siihen viikkoon asti, kunnes jokin hajoaa tuotannossa.

Mikään tästä ei edellytä, että uskot Metan väitteen kuuden ominaisuuden samanaikaisesta rakentamisesta sellaisenaan tai että valitset voittajan Muse Coden, Claude Coden ja Codexin väliltä. Riittää, että huomaat kolmen hyvin resursoidun laboratorion päätyneen toisistaan riippumatta siihen, että seuraava vipu on rinnakkaisuus, ei pelkkä mallin raaka laatu – ja suunnittelet oman osaamisesi kehittämisen tämän synnyttämän pullonkaulan ympärille sen sijaan, että keskittyisit siihen, mitä puolestasi jo ratkaistaan.