Kun Meta julkaisi Muse Coden tällä viikolla, otsikoissa oli kilpailuasetelma: jälleen yksi terminaalipohjainen koodausagentti liittyi Clauden Coden, Codexin ja Cursorin rinnalle kamppailuun kehittäjien työnkuluista. Mark Zuckerbergin omassa työkalua koskevassa kuvauksessa piilee kuitenkin kiinnostavampi viesti kaikille, jotka kirjoittavat tai tarkistavat koodia työkseen.

"Kun työ on riittävän suuri, se haarautuu erillisille rinnakkain työskenteleville aliagenteille eristetyissä worktreeissä", Zuckerberg kirjoitti kuvatessaan Muse Coden lähestymistapaa suuriin tehtäviin. "Työkopioosi ei koskaan kosketa. Testeissä saimme sen rakentamaan peliin samanaikaisesti kuusi ominaisuutta ilman törmäyksiä."

Tuo ei ole ominaisuuden kuvaus. Se on työnkuvaus — sinulle.

Mitä "eristetyt worktreet" oikeastaan tarkoittavat

Git worktree mahdollistaa saman repositorion useiden haarojen tarkistamisen ulos samanaikaisesti erillisiin hakemistoihin, jolloin useat työskentelylinjat voivat edetä ilman, että yksi checkout astuu toisen varpaille. Metan kuvauksen mukaan Muse Code käyttää tätä mekanismia antaakseen useiden aliagenttien kirjoittaa koodia yhtä aikaa koskematta käytössä olevaan työkopioosi tai toistensa tiedostoihin. Se on järkevä suunnitteluratkaisu: tiedostotason törmäykset ovat helpoimmin mekaanisesti estettävä monen agentin ristiriitojen laji, joten ne estetään mekaanisesti ja vapautetaan malli keskittymään varsinaiseen koodaamiseen.

Huomionarvoinen sana on "haarautuu". Ihminen ei koe kuutta rinnakkaista worktreeä kuutena koodivirtana, jotka pitäisi tarkistaa yksi kerrallaan peräkkäin — kyse on kuudesta suunnilleen yhtä aikaa työpöydälle saapuvasta virrasta, joista jokainen vaatii päätöksen: otetaanko tämä mukaan, tarvitseeko se uudelleentyöstöä, onko se ristiriidassa jonkin kanssa, jonka sisaragentti juuri teki toisessa worktreessä.

Todellisuudessa muuttuva taito

Viimeiset pari vuotta tekoälyavusteisen koodauksen vallitseva malli on ollut keskusteleva ja yksittäinen: yksi kehittäjä, yksi avustaja, yksi edestakaisen keskustelun säie, jota tarkistetaan suunnilleen reaaliajassa sen syntyessä. Tämä taito — hyvien kehotteiden kirjoittaminen, huonon ehdotuksen havaitseminen heti ja iterointi — on edelleen tarpeellinen. Mutta se ei ole taito, jonka Muse Coden suunnittelu asettaa etusijalle. Aliagenteille haarautuminen edellyttää, että olet jo siirtynyt toisenlaiseen työskentelytapaan: tehtävän jakamiseen etukäteen itsenäisesti suoritettaviin osiin ja useiden agenttien valmiin (tai puolivalmiin) tuotoksen tarkistamiseen kerralla sen sijaan, että ohjaisit yhtä agenttia vuoro vuorolta.

Tämä muistuttaa enemmän sprintin jakavaa teknistä vetäjää pienen tiimin kesken kuin ruudun chatbotin kanssa jakavaa pariohjelmoijaa. Yksittäiset koodauspäätökset merkitsevät vähemmän kuin työn hajottaminen (jaoitko työn osiin, jotka ovat todella toisistaan riippumattomia?) ja tarkistuskierros (pystytkö nopeasti arvioimaan, ovatko kuusi rinnakkaista diffiä kukin erikseen oikein ja kokonaisuutena johdonmukaisia?).

Eristäminen ratkaisee törmäykset, ei johdonmukaisuutta

Tätä kannattaa pysähtyä pohtimaan, koska se on helppo ohittaa: eristetyt worktreet estävät kahta agenttia ylikirjoittamasta samaa tiedostoa. Ne eivät estä kahta agenttia keksimästä itsenäisesti kahta eri tapaa tehdä sama asia — toista päivämäärän muotoilun apufunktiota, toista uudelleenyrityskäärettä tai päällekkäistä API-reittiä — koska kumpikaan agentti ei voinut nähdä, mitä toinen rakensi. Git-eristys on tiedostojärjestelmää koskeva takuu, ei suunnittelutakuu. Kuuden worktreen takaisin yhdistävä tarkistaja on ainoa tarkistuspiste, jossa päällekkäinen abstraktio, epäjohdonmukainen nimeämiskäytäntö tai kaksi ominaisuutta, jotka hiljaisesti olettavat erilaiset datarakenteet, havaitaan. Jos tarkistaja selaa diffejä ylimalkaisesti, koska rinnakkaisen tuotoksen määrä ylittää huolellisen lukemisen kapasiteetin, juuri tällainen ajautuminen päätyy tuotantoon.

Tämä muuttaa sitä, mitä "koodikatselmoinnin" on tarkoittava, kun haarautumistyökalut yleistyvät: vähemmän yhden diffien läpikäyntiä rivi riviltä (agentin syntaksi on yleensä kunnossa), enemmän diffien välistä yhteensovittamista — sen tarkistamista, että rinnakkaiset tekoälyn tuottaman työn virrat ovat keskenään yhtä mieltä jaetuista käytännöistä, jaetuista datamalleista ja jaetusta virheenkäsittelystä.

Mitä kohti kannattaa oikeasti rakentaa

Mikään tästä ei edellytä juuri Muse Codea — sama haarautumismalli näkyy suurissa koodausagenteissa, mikä viittaa siihen, että siitä on tulossa oletusarkkitehtuuri yhden toimittajan panoksen sijaan. Muutamia konkreettisia asioita, joita kannattaa harjoitella jo nyt riippumatta siitä, mitä työkalua käytät:

  • Kirjoita tehtävämäärittelyt, jotka jakautuvat siististi osiin. Ennen kuin pyydät rinnakkaista työtä, kysy itseltäsi, ovatko osat todella toisistaan riippumattomia — koskevatko ne samoja tiedostoja, samoja jaettuja vakioita tai samaa API-sopimusta? Jos kyllä, kyse ei ole kuuden rinnakkaisen agentin tehtävästä; kyse on yhdestä peräkkäin työskentelevästä agentista tai siitä, että jaat yhteiset osat ensin itse erilleen.
  • Harjoittele tarkistamista yhdistämiskohdassa, älä diffikohdassa. Totuttele tuomaan useita valmiita haaroja rinnakkain ja kysymään "ovatko nämä keskenään yhteneviä" sen sijaan, että kysyisit vain "onko jokainen näistä erikseen oikein".
  • Hallitse git worktreen perusteet. Jos käyttämäsi työkalut tulevat kuvaamaan sisäistä toimintaansa tällä tavoin, sen ymmärtäminen, mitä worktree takaa ja mitä se ei takaa, on luottamisen — tai oikeanlaisen epäluottamisen — perustaito tuotoksen arvioinnissa.
  • Sopikaa jaettujen asioiden omistajuudesta selkeästi. Vakiot, skeemat, jaetut apuohjelmat, nimeämiskäytännöt. Mitä useamman näistä lyöt lukkoon ennen haarautumisen alkamista, sitä vähemmän yhteensovittamistyötä sinulla on sen jälkeen.

Muse Coden kaltaisista työkaluista eniten hyötyvät eivät ole niitä, jotka kirjoittavat parhaat kehotteet. He ovat niitä, joista on kaikessa hiljaisuudessa tullut hyviä johtamaan pientä, nopeaa ja toisinaan huolimatonta tiimiä — vaikka jokainen tiimin jäsen olisi malli.