Kada je Meta ove nedelje lansirala Muse Code, naslovna poruka bila je pozicioniranje u odnosu na konkurenciju: još jedan agent za programiranje zasnovan na terminalu pridružuje se alatima Claude Code, Codex i Cursor u borbi za radne tokove programera. Ali u opisu ovog alata koji je izneo sam Mark Zakerberg krije se zanimljiviji signal za svakoga ko profesionalno piše ili pregledava kod.

„Kada je posao dovoljno velik, on se deli na zasebne podagente koji rade paralelno u izolovanim radnim stablima“, napisao je Zakerberg opisujući pristup Muse Code-a velikim zadacima. „Vaša radna kopija se nikada ne dira. Tokom testiranja smo mu zadali da istovremeno napravi šest funkcionalnosti za jednu igru, bez ikakvih kolizija.“

To nije opis funkcionalnosti. To je opis posla — za vas.

Šta „izolovana radna stabla“ zapravo znače

Git worktree omogućava vam da istovremeno izvučete više grana istog repozitorijuma u zasebne direktorijume, tako da se na više pravaca rada može napredovati bez toga da jedno preuzimanje ometa drugo. Prema Metinom opisu, Muse Code koristi ovaj mehanizam da omogući većem broju podagenata da istovremeno pišu kod, a da pritom ne diraju vašu aktivnu radnu kopiju niti datoteke jedni drugih. To je razuman inženjerski izbor: kolizije na nivou datoteka najlakše je mehanički sprečiti među konfliktima višestrukih agenata, pa ih tako i sprečavate i oslobađate model da se usredsredi na samo programiranje.

Reč na koju treba obratiti pažnju jeste „deli se“. Ljudski programer šest paralelnih radnih stabala ne doživljava kao šest tokova koda koje treba jedan po jedan ručno proveravati — to je šest tokova koji mu otprilike istovremeno sleću na sto, a za svaki je potrebna odluka: da li ovo prihvatiti, da li je potrebna dorada, da li je u sukobu s nečim što je susedni agent upravo uradio u drugom radnom stablu.

Veština koja se zapravo menja

Tokom poslednjih nekoliko godina, dominantni model programiranja uz pomoć veštačke inteligencije bio je konverzacijski i pojedinačan: jedan programer, jedan asistent, jedna nit razmene poruka, uz približno praćenje u realnom vremenu dok se rezultat stvara. Ta veština — dobro postavljanje upita, pravovremeno uočavanje lošeg predloga, iteriranje — i dalje je neophodna. Ali to nije veština za koju je Muse Code osmišljen da je optimizuje. Deljenje na podagente pretpostavlja da ste već prešli na drugačiji način rada: unapred razlažete zadatak na delove koji mogu nezavisno da se izvršavaju, a zatim istovremeno pregledate gotov (ili polugotov) rezultat više agenata, umesto da korak po korak usmeravate jednog agenta.

To je bliže ulozi tehničkog vođe koji deli sprint među malim timom nego radu programera u paru, gde je ekran podeljen s četbotom. Pojedinačne odluke pri programiranju manje su važne od razlaganja (da li ste podelili posao po linijama koje su zaista nezavisne?) i pregleda (možete li brzo da utvrdite da li je šest paralelnih razlika pojedinačno ispravno i kolektivno koherentno?).

Izolacija rešava kolizije, ne koherentnost

Vredi zastati i razmisliti o ovome, jer se lako previde: izolovana radna stabla sprečavaju dva agenta da prepišu istu datoteku. Ona ni na koji način ne sprečavaju dva agenta da nezavisno osmisle dva različita načina da urade istu stvar — drugog pomoćnika za formatiranje datuma, drugog omotača za ponovne pokušaje, dupliranu API rutu — jer nijedan agent nije mogao da vidi šta drugi gradi. Git izolacija je garancija na nivou sistema datoteka, a ne garancija dizajna. Osoba koja spaja šest radnih stabala nazad u jednu celinu jedina je kontrolna tačka na kojoj se otkrivaju duplirana apstrakcija, nedosledna konvencija imenovanja ili dve funkcionalnosti koje neprimetno pretpostavljaju različite oblike podataka. Ako ta osoba površno pregledava razlike zato što obim paralelnog izlaza nadmašuje mogućnost pažljivog čitanja, upravo ovakvo odstupanje dospeva u produkciju.

To menja ono što „pregled koda“ treba da znači kada alati za deljenje na više tokova postanu uobičajeni: manje pregledanja svake pojedinačne linije jedne razlike (sintaksa agenta je obično ispravna), a više usklađivanja razlika — proveravanja da li se paralelni tokovi rada koje je generisala veštačka inteligencija međusobno slažu oko zajedničkih konvencija, zajedničkih modela podataka i zajedničke obrade grešaka.

Ka čemu zapravo treba težiti

Ništa od ovoga ne zahteva baš Muse Code — isti obrazac deljenja na više tokova pojavljuje se kod glavnih agenata za programiranje, što ukazuje na to da postaje podrazumevana arhitektura, a ne opklada na jednog dobavljača. Nekoliko konkretnih stvari koje vredi vežbati već sada, bez obzira na to koji alat koristite:

  • Pišite specifikacije zadataka koje se mogu uredno razložiti. Pre nego što zatražite paralelni rad, zapitajte se da li su delovi zaista nezavisni — da li dodiruju iste datoteke, iste zajedničke konstante, isti API ugovor? Ako je odgovor potvrdan, to nije posao za šest paralelnih agenata; to je posao za jednog agenta koji radi sekvencijalno ili za vas, da najpre ručno izdvojite zajedničke delove.
  • Vežbajte pregled na tački spajanja, a ne na tački razlike. Naviknite se da povučete nekoliko završenih grana jednu pored druge i pitate „da li se međusobno slažu“, a ne samo „da li je svaka pojedinačno ispravna“.
  • Upoznajte osnove Git worktree-ja. Ako će alati koje koristite na ovaj način opisivati svoje interne mehanizme, razumevanje toga šta worktree garantuje, a šta ne garantuje, predstavlja osnovni preduslov za poverenje u rezultat — ili za njegovo ispravno nepoverenje.
  • Jasno odredite vlasništvo nad zajedničkim elementima. Konstante, šeme, zajednički pomoćni alati, konvencije imenovanja. Što više toga precizno utvrdite pre početka deljenja na više tokova, to ćete manje posla imati oko usklađivanja nakon toga.

Najviše koristi od alata kao što je Muse Code neće imati oni koji najbolje postavljaju upite. Imaće je oni koji su se neprimetno izveštili u vođenju malog, brzog i povremeno traljavog tima — čak i kada je svaki član tog tima model.