Shopify turi savo, kiek neįprastą DI agentą programinei įrangai kurti. Jis vadinasi River, gyvena įmonės Slack kanaluose ir dirba kaip komandos narys: skaito kodą, leidžia testus, daro pakeitimus, kuria ir peržiūri pull request'us. Vien pagrindinėje Shopify kodo saugykloje River per savaitę sukuria beveik du tūkstančius pull request'ų. Labiausiai jis išsiskiria viena savybe: River dirba tik bendruose kanaluose. Į asmenines žinutes jis neatsako – mandagiai pasiūlo pokalbį perkelti ten, kur mato visi. Shopify vadovas Tobi Lütke aprašė, ką tai davė: per du mėnesius priimtų River pull request'ų dalis išaugo nuo 36 % iki 77 %. Pokytį padarė žmonės: komanda agentą greitai priėmė ir valdė jį kartu, o ne kiekvienas sau. Čia ir atsiskleidė River vertė – ir tai vienas pagrindinių Multiplayer AI principų.
Šią istoriją pasakoju vis dažniau, kai kalbuosi su savo komandomis ar kitų įmonių vadovais, nes tikiu, kad būtent to šiuo metu labiausiai reikia. Dabar agentai kodą rašo greičiau nei bet kada, bet viso proceso greitis smarkiai nesikeičia. Vienose komandose darbų srautas sulėtėja pull request'ų peržiūrose: kodo daugiau, nei žmonės spėja patikrinti, o agentų rašytu kodu dar visiškai nepasitikima. Kitose – dar iki programavimo: produkto komanda nespėja sugalvoti ir aprašyti, ką kurti, – programuotojai su agentais tai įgyvendina greičiau, nei darbai nugula į backlog'us. Silicio slėnis šiais metais abiem bėdoms siūlo vieną vaistą ir vadina jį Multiplayer AI. Ar jis tikrai jas pašalins? Atsakymas priklauso nuo to, kodėl darbų srautas sulėtėja būtent tose vietose.
Kur šiandien stringa agentų inžinerija?
Agentų inžinerija („agentic engineering“) šiandien stringa ten, kur yra laukiama žmogaus sprendimo. Tą patį rodo ir dideli tyrimai: Faros AI savo ataskaitoje pagal tūkstančių komandų įrankių duomenis išmatavo, kiek laiko užduotis praleidžia kiekviename etape. Aktyvaus darbo laikas pailgėjo 50,7 % – pakeitimai tapo didesni, o užduotys dažniau grąžinamos taisyti, – tuo pat metu laikas peržiūroje pailgėjo net 301,4 %. Dalis komandų peržiūros tiesiog atsisakė: be jokios peržiūros pakeitimų padaugėjo 76,3 %, ir turbūt jokio kito patikrinimo vietoje jos neatsirado.
Harvardo ekonomistai Fiona Chen ir Jamesas Strattonas, išnagrinėję 718 įmonių duomenis, tą patį pamatė iš kitos pusės: agentai pull request'ų skaičių padidina 23 %, bet įmonės rezultatas beveik nekinta, nes kiekvieno pakeitimo peržiūra užtrunka 49 % ilgiau. Taip yra todėl, kad programuotojas nežino, kiek galima pasitikėti kodu, kurį parašė agentai. Stack Overflow 2026 m. apklausoje svarbiems sprendimams DI pasitiki vos 6,6 % programuotojų, o 48 % – tik tada, kai rezultatą lengva patikrinti.
Produkto pusėje darbų srautas sulėtėja anksčiau. Refactoring.fm apklausoje tik 27 % inžinierių sako, kad perskaitę užduotį supranta ir problemą, ir sėkmės kriterijus, o dažniausia perdarymo priežastis – neaiškūs arba apskritai neužrašyti priėmimo kriterijai. Agentas tokią užduotį vis tiek įvykdys, tik rezultatą teks perdarinėti ar net išmesti. Agentų inžinerija šiandien stringa dviejose vietose – iki kodo rašymo ir po jo. Abiem atvejais darbas laukia žmogaus, bet priežastys skiriasi.
Kodėl darbų srautas sulėtėja būtent ten?
Produkto pusėje darbas keliauja iš vienų rankų į kitas. Produkto vadovas savo poreikį užrašo į užduotį, programuotojas ją perduoda agentui, agentas pagamina pakeitimą, ir kiekviename žingsnyje dalis pradinės idėjos pasimeta. Multiplayer AI manifesto autorius Sergejus Karajevas šią kainą vadina konteksto mokesčiu („context tax“): sumoki jį kaskart, kai kontekstą kopijuoji iš vieno pokalbio į kitą ir perduodi toliau. Kuo daugiau rankų, tuo didesnis mokestis.
Programuotojams DI agentai jau tapo kasdienybe. Produkto žmonės prie jų dar tik pratinasi ir dažniausiai dirba su pokalbių įrankiais. Lenny Rachitsky apklausoje populiariausias įrankis lieka ChatGPT, o agentinės platformos, pasak autorių, tarp produkto vadovų plinta lėtai. Atotrūkis tik didėja: programuotojas su agentais dirba vis greičiau, produkto vadovas su pokalbių langu vos spėja iš paskos. Multiplayer AI žada, kad jie pagaliau judės vienodu greičiu.
Peržiūroje priežastis kita – pasitikėjimas. Programuotojas skaito kiekvieną eilutę, nes nežino, ar komandos testai, automatiniai patikrinimai ir peržiūros agentas pastebės kito agento klaidas. Kol komanda neturi kuo patikimai patikrinti agento darbo, žmogus viską tikrina pats, o kodo srautas vis auga. Perdavimas čia irgi prisideda: agentas valandą tyrinėjo, rinkosi ir atmetinėjo variantus, o kodą peržiūrintis kolega gavo tik galutinį pakeitimų sąrašą („diff“). Jis matė atsakymą, bet ne kelią iki jo.
Darbų srautas sulėtėja perdavimuose ir ten, kur trūksta pasitikėjimo. Pirmąją priežastį Multiplayer AI šalina tiesiogiai, antrąją – tik iš dalies.
Kas yra Multiplayer AI?
Multiplayer AI – tai darbo būdas, kai tos pačios komandos žmonės dirba su tais pačiais DI agentais bendrose sesijose ir mokosi vieni iš kitų, užuot kiekvienas sėdėjęs savo privačiame pokalbyje. Taip jį apibrėžia manifestas, kurį rugsėjį paskelbė įmonės Superconductor komanda. Pats žodis atėjo iš žaidimų, kuriuos žaidžia keli žmonės vienu metu. Į programinę įrangą jį prieš dešimtmetį atnešė Figma, kai dizaineriai pirmąkart galėjo vienu metu dirbti prie to paties projekto. Šiais metais terminą beveik kartu ėmė vartoti ir investuotojai, ir DI kūrėjai: Y Combinator jį įtraukė į sąrašą idėjų, kurioms ieško startuolių, o Anthropic pristatė Claude Tag – agentą, kuris Slack kanale dirba su visais iš karto.
Ar įrankis tikrai multiplayer, patikrinti paprasta užduodant vieną klausimą: ar tavo kolega gali įsijungti į tą pačią agentų sesiją, ją valdyti ir bendrauti su agentais? Superconductor įkūrėjas savo pristatyme būtent tai laiko svarbiausiu požymiu, ypač peržiūroje, kai pakeitimą tikrinantis kolega klausimą užduoda ne autoriui, o tiesiai agentui.
Dirbdamas vienas (Singleplayer AI), su kolegomis gali pasidalyti rezultatais arba tuo, kas padės jiems pasiekti panašių: bendromis instrukcijomis (AGENTS.md / CLAUDE.md), skill'ais repozitorijoje, išsamiu pull request'o aprašu. Tai naudinga, ir dauguma komandų net to dar nedaro. Bendra sesija leidžia dalytis mintimis dar kuriant. Čia įrankiai labai skiriasi: vieni sesiją rodo visiems ir leidžia ją perimti, kiti leidžia tik stebėti, treti apsiriboja bendra užduočių lenta. Todėl kiekvieną įrankį verta tikrinti atskirai: kuo daugiau bendro darbo jis leidžia, tuo daugiau trinties sumažina perdavimuose.
Kaip Multiplayer AI mažina trintį perdavimuose?
Grįžkime prie River. Shopify inžinieriai aprašo, kaip atrodo geras pokalbis su juo. Vienas žmogus užduoda klausimą, agentas skaito kodą ir dalijasi įžvalgomis. Tada įsiterpia antras žmogus su reikalavimais ar nauja kryptimi, ir agentas ją priima, nepamesdamas ankstesnio konteksto. Trečias, įsiterpęs su tuo pačiu klausimu, tuščio lango nebeatsidaro – jis tęsia šį pokalbį. Perdavimas tiesiog neįvyksta, nes kontekstas jau yra ten, kur vyksta darbas. Shopify vadovas Lütke tai apibendrina taip: „The risk is not that AI does the work. The risk is that AI does the work and we never learn from it.“ Pavojus ne tas, kad darbą atlieka DI, o tas, kad mes iš to nieko neišmokstame.
Didžiausią naudą čia matau produkto žmonėms. Kai produkto vadovas, dizaineris ar verslo analitikas nuo pirmo reikalavimo sėdi tame pačiame kanale su agentu, poreikio nebereikia perpasakoti. Jis jau yra sesijos kontekste, o kūrimui prasidėjus jį galima patikslinti tą pačią akimirką. Ženklų, kad taip ir bus, jau yra. Figma 2026 m. ataskaitoje per metus kūrime dalyvaujančių dizainerių dalis išaugo nuo 21 % iki 41 %, dizainu užsiimančių programuotojų – nuo 44 % iki 60 %, o daugiau nei pusė apklaustųjų sako visiškai atsisakę nuoseklių perdavimų (tiesa, apklausti tik Figma naudotojai). Ramp produkto vadovai agento darbą tikrina veikiančioje peržiūros aplinkoje, ir visos jų agento Inspect sesijos yra viešos be jokių išimčių.
Peržiūrai Multiplayer AI padeda kitaip. Kas peržiūri kodą, mato visą kelią iki rezultato: kokius nurodymus agentas gavo, kur suklydo, kurį variantą atmetė. Bendroje sesijoje agentas greičiau tobulėja, todėl greičiau užsitarnauja ir pasitikėjimą. Taip priimtų River pull request'ų dalis išaugo nuo 36 % iki 77 %: žmonės matydavo, kur agentas užstringa, ir užrašydavo, ką jam reikėjo žinoti. Viešai dirbančio agento klaidas pastebi visa komanda, ir vieno žmogaus pataisymu toliau naudojasi visi. Dirbant atskirai kiekvienas instrukcijas derina savo kompiuteryje ir agentu išmoksta pasitikėti tik pats. Manau, kad komandoms perėjus prie Multiplayer AI peržiūra nustos būti vien paskutiniu patikrinimu: programuotojas prisijungs prie sesijos agentui dar dirbant ir dalį klaidų pastebės iki pull request'o. Tik pasitikėjimo bendra sesija už komandą nesukurs.
Ko Multiplayer AI neišspręs?
Pirma – pasitikėjimas. Agentas jį turi užsitarnauti testais, automatiniais patikrinimais ir peržiūros agento išvadomis, o tokią sistemą komandai teks susikurti pačiai. Harvardo tyrime peržiūros bottleneck'as išliko net tose įmonėse, kurios įsidiegė DI peržiūros įrankius, tad neužtenka, kad agento kodą patvirtintų kitas agentas.
Be to, Multiplayer AI nesumažina kodo, kurį reikia patikrinti. Dažniausiai jo tik padaugėja, nes agentą dabar gali paleisti ne tik programuotojai. Ramp produkto vadovas Geoffas Charlesas pasakoja apie maždaug tūkstantį pull request'ų per mėnesį iš žmonių, kurie nėra inžinieriai, – įmonei teko susikurti atskirą peržiūros agentą. Lütke perspėja ir apie kitą kraštutinumą, kurį Shopify vadina „šlamšto granatomis“ (slop grenades): agentui leidžiama daryti, ką nori, pull request'as pateikiamas jo neperskaičius, o peržiūra numetama kolegoms.
Antra – atsakomybė. Jei sesiją valdė penki žmonės, kieno tada klaida? Bendras agentas nereiškia bendros atsakomybės. Konteksto perdavimų Multiplayer AI sumažina, bet atsakomybę vis tiek reikės perduoti – ir tai tampa dar svarbiau. Produkto vadovas patvirtina poreikį, inžinierius – kodą, ir šių parašų už juos neuždės joks agentas. Charlesas siūlo produkto ir inžinerijos komandoms iš naujo susitarti dėl trijų dalykų: duomenų, agentams suprantamų reikalavimų ir prototipo.
Trečia – organizacija. Figma duomenimis, didžiausias atotrūkis tarp lūkesčių ir rezultato susidaro ten, kur žmonės DI jau naudoja aktyviai, o organizacija dar neturi bendrų standartų, procesų ir įrankių. Bendras agentas be bendrų taisyklių tėra didesnis pokalbis.
Kaip Multiplayer AI pakeis programinės įrangos kūrimo procesą?
Patikrintam receptui dar per anksti: pirmosios įmonės savo įrankius pačios susikūrė tik šiais metais. Taip buvo ir su elektros varikliais: prieš 130 metų fabrikai iš jų naudos nematė keturis dešimtmečius, kol neperprojektavo paties fabriko. Kryptį jau galima nuspėti iš to, kaip dirba Shopify ir Ramp, todėl, tikėtina, mūsų laukia keturi pokyčiai: užduotis taps pokalbiu, ginčai dėl sprendimų persikels į bendrą agentų sesiją, komandos žinios kaupsis ten pat, o klausimai, į kuriuos agentas jau žino atsakymą, nebepasieks kitų komandos narių, nes taip greičiau dirbti komandoms agentų eroje.
Šiandien kiekvienoje komandoje yra žmogus, dažniausiai techninis vadovas, pas kurį suplaukia visi klausimai: kokia užduoties būsena, kodėl pasirinktas būtent šis sprendimas, ką pakeitė agentas. Multiplayer AI manifeste tam skirtas atskiras principas: žmonės nėra maršrutizatoriai („people are not routers“). Ko gali paklausti agento, to neklausk žmogaus. Bendras agentas mato visus komandos kanalus, sesijas ir pakeitimus, tad į tokius klausimus atsakys pats, niekam nepertraukęs darbo. Vieno žmogaus agentas to padaryti negali: jis žino tik tai, apie ką su juo bendravo tas vienas žmogus. Žmonėms liks tik tie klausimai, į kuriuos agentai neturi atsakymo.
Kas lieka vadovui?
Taigi visų darbų srauto sulėtėjimų Multiplayer AI nepašalins. Produkto pusėje jis šalina pačią priežastį: idėja pasieks agentą neperpasakota, o produkto žmonės pagaliau dirbs viename kanale su programuotojais ir agentu. Peržiūroje jis tik padeda: pasitikėjimą agentu kuria komandos kokybės užtikrinimo sistema, o ja pasirūpinti ir nuspręsti, kas kam perduoda atsakomybę, turi vadovas. Agentas gali dirbti su visais iš karto. Pasirašyti už rezultatą vis dar turės žmonės.
Kodėl būtent kodo peržiūros šiandien labiausiai lėtina agentų inžineriją, apie tai rašysiu kitame straipsnyje.
„Code is cheap. Leadership isn't.“ Kodą rašyti pigu. Vadovauti – ne. Jei nori, kad perdavimai ir nepasitikėjimas agentais nustotų lėtinti tavo komandų darbą, tam skirti mano mokymai vadovams.
