Tällä viikolla Meta julkaisi Muse Coden, sen Muse Spark 1.2 -malliin perustuvan päätelaitteessa toimivan koodausagentin, joka kilpailee suoraan Anthropicin Claude Coden, OpenAI:n Codexin ja Cursorin kanssa. Mark Zuckerbergin omin sanoin myyntipuhe on, että se hoitaa ”kokonaisia ohjelmistokehitystehtäviä suurissa repositorioissa: muutosten suunnittelua, koodin kirjoittamista ja tulosten validointia”. Huomionarvoinen yksityiskohta on se, miten se käsittelee suuria tehtäviä: ”Kun tehtävä on riittävän suuri, se jakaa työn erillisille aliagenteille, jotka työskentelevät rinnakkain eristetyissä työpuissa. Työkopioosi ei koskaan kosketa.” Zuckerberg väitti testiajossa sen ”rakentaneen kuusi pelin ominaisuutta samanaikaisesti ilman törmäyksiä” — kyse on toimittajan väitteestä, ei riippumattomasti varmennetusta vertailutuloksesta, joten tähän tiettyyn lukuun kannattaa suhtautua epäillen. Sen taustalla oleva toimintamalli on kuitenkin todellinen: tämä on nyt alan vakiintunut myyntipuhe, ei vain Metan ominaisuus.

Mikä tarkoittaa, että näiden työkalujen välinen erottava tekijä kutistuu nopeasti. Suunnittele, koodaa, validoi, rinnakkaista — jokainen suuri laboratorio on päätymässä samaan nelivaiheiseen silmukkaan. Jos rakennat uraasi sen varaan, että ”olen hyvä saamaan agentin tekemään työn”, toimittajat itse tuotteistavat tätä taitoa parhaillaan reaaliajassa. Se, mitä ei tuotteisteta ja mitä yksikään näistä julkaisuista ei oikeasti ratkaise, on se, mitä tapahtuu rinnakkaistamisen jälkeen: jonkun on edelleen päätettävä, ovatko kuusi rinnakkain kirjoitettua koodiosaa, kuuden toistensa työtä näkemättömän aliagentin tekeminä, kukin oikein ja yhdessä johdonmukaisia.

Eristetyt työpuut ratkaisevat yhdistämiskonfliktin ongelman, eivät oikeellisuusongelmaa

Aliagenttien ajaminen erillisissä työpuissa on todellinen insinöörityön parannus — se estää yhtä agenttia jyräämästä toisen muutoksia. Samalla se kuitenkin tarkoittaa, ettei kuutta ominaisuutta rakentavilla agenteilla ollut työn aikana lainkaan näkyvyyttä toistensa päätöksiin. Jos kaksi niistä lisäsi itsenäisesti samankaltaisen apufunktion, otti käyttöön hieman erilaisen validointilogiikan samalle syötteelle tai teki yhteisen tietorakenteen suhteen yhteensopimattomia oletuksia, eristys ei havaitse sitä — se siirtää törmäyksen ”yhdistämiskonfliktista” muotoon ”julkaistava integraatiovirhe”. Kyse on rakenteellisesti erilaisesta vikatilasta kuin se, jonka estämiseen nämä työkalut suunniteltiin, ja nyt ihmisen on havaittava se.

Tästä kannattaa puhua täsmällisesti, koska on helppo sekoittaa keskenään ”agentti validoi oman tuotoksensa” ja ”tuotos on validoitu”. Se, että agentti tarkistaa koodinsa kääntyvän ja läpäisevän itse kirjoittamansa testit, ei ole sama asia kuin että arvioija kysyy, ovatko kuusi rinnakkaista muutosta keskenään ja muun koodikannan kanssa johdonmukaisia. Kyse on eri tehtävistä, ja vain toista niistä nämä työkalukehikot oikeasti myyvät.

Taito, josta on oikeasti tulossa pulaa

Jos työskentelet ohjelmistojen parissa tai niiden läheisyydessä — ohjelmistoinsinöörinä, projektipäällikkönä, laadunvarmistuksessa, teknisessä tuessa tai nykyään jopa ei-insinöörinä, joka julkaisee näillä agenteilla pieniä työkaluja — käytännön seuraus on, että ”monitiedostoisen, moniagenttisen tuotoksen johdonmukaisuuden tarkistamisesta” on muodostumassa oma alansa, joka eroaa sekä koodin kirjoittamisesta että agentin hyvästä ohjeistamisesta. Muutamia konkreettisia osa-alueita:

  • Luottamuksen kalibrointi. Tiedä jo ennen yhden rivin lukemista, millainen muutos vaatii huolellisen tarkistuksen (kaikki jaettuun tilaan tai API-sopimukseen koskeva tai jokin, johon useampi kuin yksi aliagentti on saattanut myös koskea) ja millaisen voi vilkaista nopeasti.
  • Ristikkäisten diffien lukeminen. Kun tehtävä jakautuu rinnakkaiseksi työksi, tarkasteluyksikkö ei ole yksi diffi — se on diffien muodostama kokonaisuus. Tämä tarkoittaa, että on tarkoituksella tarkistettava päällekkäinen logiikka, saman syötteen poikkeava käsittely sekä osien välinen epäjohdonmukainen nimeäminen tai oletukset, eikä vain luettava kutakin tiedostoa eristyksissä.
  • Määrittelyjen kirjoittaminen valvomattomalle suorittajalle. Ylävirran ratkaisu törmäysriskiin on tehtävän kuvaus, joka on riittävän täsmällinen, jotta rinnakkaisten agenttien ei tarvitse koordinoida toimintaansa, koska niiden rajat määriteltiin alun perin oikein. Tällaisen määrittelyn kirjoittaminen muistuttaa enemmän järjestelmäsuunnittelutaitoa kuin ohjeistamistaitoa.

Mikään tästä ei ole abstraktisti uutta — koodikatselmointi ja rajapintojen suunnittelu ovat aina olleet tärkeitä. Uutta ovat määrä ja katvealue: kun yksi ihminen voi käynnistää kuusi rinnakkaista työvirtaa iltapäivän aikana, tarvittavan poikkileikkaavan katselmoinnin määrä kasvaa sen mukana, mutta työkalut, jotka tekisivät poikkileikkaavasta katselmoinnista helppoa, eivät ole pysyneet rinnakkaisen generoinnin helppoutta tekevien työkalujen tahdissa.

Mitä asialle kannattaa oikeasti tehdä tässä kuussa

Jos tiimisi kokeilee jotakin näistä työkalukehikoista — Muse Codea, Claude Codea, Codexia tai kilpailijaa — muutama edullinen toimenpide kannattaa tehdä nyt, ennen kuin tavat jähmettyvät:

  • Kun tarkastat agentin tuottamaa työtä, kysy ennen hyväksymistä nimenomaisesti ”koskiko jokin muu tässä tehtävässä samaa tiedostoa, funktiota tai jaettua tyyppiä?” — useimmat katselmointilistat eivät kehota tähän, koska ne on kirjoitettu yhden tekijän diffien varalle.
  • Jos tiimilläsi ei ole kirjallista määrittelymuotoa tehtävien antamiseen agentille, tarjoudu laatimaan sellainen. Henkilöllä, joka vastaa siitä, ”miten briiffaamme agentin”, on lopulta suhteettoman suuri vaikutus siihen, kuinka paljon katselmointivelkaa tiimi myöhemmin kerryttää.
  • Pidä useampi kuin yksi näistä työkalukehikoista tuttuna sen sijaan, että panostaisit osaamisesi siihen, minkä nykyinen työnantajasi valitsi. Ne toimivat riittävän eri tavoin — työpuiden käsittelyssä, rinnakkaistamisen aggressiivisuudessa ja siinä, mitä ne tuovat katselmoitavaksi — että myöhempi vaihtaminen ilman ennakkotuntemusta maksaa oikeasti aikaa.

Tämän julkaisusyklin pääotsikko käsittelee sitä, minkä laboratorion agentti on nopein tai halvin. Kestävämpi urasignaali on hiljaisempi: näitä työkaluja julkaisevat yritykset optimoivat kaikki nimenomaisesti suuremman koodimäärän tuottamiseen nopeammin ja rinnakkain. Ne eivät toistaiseksi julkaise vastaavasti parempaa tapaa tarkistaa tämän koodin johdonmukaisuutta. Juuri tähän aukkoon seuraava rekrytointikysynnän aalto tulee kohdistumaan, ja se näyttäytyy katselmointi- ja järjestelmäajattelutaitona, ei ohjeistamistaitona.