Meta-in ulazak na tržište AI programiranja ove nedelje došao je uz konkretnu tvrdnju vrednu pažnje. Muse Code, novi agent kompanije za programiranje zasnovan na terminalu, ne piše kod samo u jednom fajlu — prema objavi Marka Zakerberga povodom lansiranja, kada je zadatak dovoljno velik, on „raspoređuje rad na zasebne podagente koji rade paralelno u izolovanim radnim stablima“, a u Metinom sopstvenom testiranju navodno je istovremeno napravio šest funkcionalnosti za jednu igru, bez kolizija. To je tvrdnja dobavljača o sopstvenom proizvodu na dan lansiranja, a ne nezavisno potvrđen rezultat, zato prema konkretnom broju treba biti skeptičan. Ali obrazac rada koji opisuje nije ideja svojstvena samo Meti — paralelno, izolovano izvršavanje agenata postaje podrazumevani obrazac u čitavoj oblasti programerskih agenata, i menja ono što zapravo znači „biti dobar u ovome“.

Tokom protekle dve godine, priča o AI alatima za programiranje uglavnom se vrtela oko brzine u jednom toku rada: jedan agent, jedan zadatak, jedan diff za pregled. To je veština koju je većina inženjera već napola usvojila — pročitaj diff, pokreni testove, isporuči. Raspoređivanje rada na više agenata koji rade u izolovanim radnim stablima ruši taj model. Više ne pregledate jednu koherentnu izmenu nastalu iz jednog toka razmišljanja. Pregledate nekoliko istovremenih, nezavisno osmišljenih izmena koje sve moraju da se spoje u jedan funkcionalan sistem, a da pritom ne protivreče jedna drugoj, ne dupliraju logiku niti se prećutno ne slažu oko toga kako neki zajednički deo baze koda treba da se ponaša.

Zašto je ovo zaista drugačija veština, a ne samo brža verzija stare

Pregled jednog diff-a koji je napisala veštačka inteligencija uglavnom je provera ispravnosti: da li radi ono što tvrdi da radi i da li kvari nešto u okolini. Pregled rezultata više paralelnih agenata dodaje sloj koji je većina ljudi do sada nikada nije morala da vežba, jer donedavno nijedan pojedinačni posao to nije zahtevao: doslednost između diff-ova. Da li su dva agenta svaki za sebe izmislila sopstvenu verziju iste pomoćne funkcije? Da li je izmena jednog agenta, navodno „izolovana“, neprimetno zavisila od fajla koji je drugi agent upravo prepravljao? Da li je korak spajanja zaista uočio stvarni konflikt ili je neprimetno odabrao pretpostavku jedne grane umesto pretpostavke druge? To nisu greške u tradicionalnom smislu — svaki pojedinačni diff može proći sopstvene testove, a da ipak, kada se spoje, proizvede sistem koji nije koherentan.

To je isti problem kojim distribuirani inženjerski timovi oduvek upravljaju sa ljudskim saradnicima, samo sabijen u minute umesto u dane. Razlika je u tome što tim mlađih inženjera prirodno traži smernice kada zadatak deluje nejasno; agent optimizovan da završi svoj dodeljeni deo često će proizvesti samouveren, sintaksički čist odgovor na pogrešno pitanje. Da bi se to uočilo, potrebna je osoba koja je dovoljno dobro razumela zadatak da ga uopšte razloži na delove — što znači da stvarno usko grlo nije „brzo pregledanje koda“, već „razbijanje dela posla na delove koji mogu bezbedno da se izvršavaju paralelno i poznavanje onih delova koji to ne mogu“.

Širi obrazac, izvan samih alata za programiranje

Vredi primetiti da ovo nije ograničeno na razvojne alate. Redizajn Guglovog polja za pretragu — predstavljen iste nedelje — objedinjuje AI Overviews i AI Mode u jedan tok koji kao ulaz može da primi tekst, slike, PDF-ove, video i otvorene Chrome kartice, a posao poverava agentu umesto parseru upita. Zajednička nit oba izdanja je ista: interfejs se udaljava od modela „daj veštačkoj inteligenciji jedno jasno uputstvo i proveri jedan jasan rezultat“ i kreće ka modelu „predaj veštačkoj inteligenciji neprecizno definisan cilj i gomilu ulaza, pa joj prepusti da utvrdi korake“. Taj obrazac pojavljuje se svuda gde se uvode agentski alati, ne samo u uređivačima koda — a to znači da će veština pregledanja i orkestriranja biti relevantna daleko izvan inženjerskih uloga, za svakoga čiji posao podrazumeva usmeravanje AI sistema kroz zadatak u više koraka, a ne kroz jedan jedini upit.

Šta konkretno vežbati

Ako pišete kôd ili upravljate njegovim razvojem, nekoliko konkretnih navika koje je moguće proveriti izgradiće ovu veštinu brže nego čitanje o njoj:

  • Naučite šta je zapravo izolovano radno stablo (git-ovaworktree funkcionalnost omogućava da se više grana istovremeno izcheckoutuje u zasebne direktorijume) pre nego što poverujete tvrdnji alata da paralelne izmene „ne mogu da se sudare“. Izolacija tokom izvršavanja ne garantuje koherentnost u trenutku spajanja — to je zaseban korak koji vredi pažljivo pratiti.
  • Namerno zadajte programerskom agentu dovoljno velik zadatak da mora da ga razloži i pročitajte kako deli posao pre nego što pročitate nastale diff-ove. Način razlaganja govori vam više o tome da li možete verovati rezultatu nego sam kôd.
  • Vežbajte pregledanje diff-ova u grupama, a ne jednog po jednog. Veština istovremenog držanja tri ili četiri povezana uvida u glavi i uočavanja mesta na kojima se ne slažu razlikuje se od pregledanja svakog od njih izolovano i odobravanja na osnovu njegovih sopstvenih zasluga.
  • Pitajte šta se dešava u slučaju konflikta, a ne samo u slučaju uspeha. Svaki alat koji tvrdi da automatski spaja paralelne izmene trebalo bi da može da vam pokaže šta radi kada dva agenta zaista menjaju istu logiku — taj put greške, više nego uspešan scenario, pokazuje da li je alat dovoljno bezbedan da mu poverite stvarni posao.

Ništa od ovoga ne zahteva da čekate da vaš poslodavac usvoji određeni proizvod. Ovaj obrazac — razložiti, rasporediti, ponovo objediniti, proveriti — sada se pojavljuje među programerskim agentima više dobavljača, kao i u potrošačkim AI interfejsima. Ljudi kojima postane prijatno da upravljaju tim ciklusom, umesto da samo pregledaju izlaz iz jednog toka rada, grade veštinu koja ostaje relevantna bez obzira na to čiji agent na kraju prevlada.