2026 m. gegužę Meta atleido apie 10 % darbuotojų, o maždaug 7 000 žmonių perkėlė į dirbtinio intelekto komandas. Sprendimas brendo tuo metu, kai vadovybė, Reuters šaltinių teigimu, buvo itin optimistiška dėl agentinių įrankių galimybių. Praėjo keturi mėnesiai po sprendimo priėmimo ir vidiniame susirinkime Zuckerbergas pripažino, kad agentų taikymas programavime nedavė tokių rezultatų, kaip buvo tikėtasi („trajectory of the agentic development over at least the last four months hasn't really accelerated in the way that we expected“).
Jei apsiskaičiavo tokia organizacija, kuri šiemet į DI infrastruktūrą planuoja investuoti iki 145 mlrd. dolerių, – apsiskaičiuoti gali kiekvienas.
Šią klaidą dažnai matau iš arti. Vadovas pamato pirmuosius rodiklius – programuotojų našumas išauga kelis kartus – ir mintyse nubrėžia tiesę į šviesią ateitį. Jei per metus tiek, kiek bus po dvejų? Bet 2025-ųjų–2026-ųjų šuolis buvo ne pastovaus pagreičio pradžia, o naujos disciplinos gimimas. Jos pradžioje esame visi ir išmokti reikės gerokai daugiau, nei atrodo iš pirmųjų įspūdingų skaičių. Investuoti laiko į įvaldymą – taip pat daugiau, nei norisi. O matuoti – ne viską, ką lengva suskaičiuoti, o tai, kas padės discipliną įvaldyti.
Agentų inžinerija – tai ne sprintas ir ne maratonas. Tai lenktynės, kurios greitėja tau jas įvaldant – nauja bėgimo disciplina, kurios taisyklių dar niekas nespėjo surašyti. Organizacijos, kurios išmoks ją bėgti teisingai, atitrūks taip, kad kitoms bus sunku pasivyti. Bet kol kas dažniau matome priešingus pavyzdžius – paskubintų sprendimų, kurie baigėsi brangiai. Meta – tik vienas iš jų.
Todėl pasimokykime iš svetimos ir labai brangios klaidos – pažiūrėkime, kur tiksliai ji slypi. Šiame straipsnyje parodysiu, ką iš tikrųjų sako naujausi duomenys, kodėl keturi populiariausi agentų inžinerijos matavimo būdai meluoja – net jei jie sukrenta į tvarkingą „dashboard'ą“ – ir koks yra tikrasis rodiklis, pagal kurį verta vesti komandą į priekį. Tas, kurio pritrūko Meta.
Ar agentų inžinerijos nauda reali?
Taip – nauda reali ir išmatuota realiais skaičiais, ne nuomonių apklausomis. Faros AI 2026 m. tyrimas išanalizavo dvejų metų Git kodo saugyklų duomenis: 22 000 inžinierių, daugiau nei 4 000 komandų. Rezultatai aiškūs: užbaigtų „epic'ų“ vienam inžinieriui padaugėjo 66 %, užduočių pralaidumas („task throughput“) išaugo 33,7 %, „pull request'ų“ rodiklis – 16,2 %.
Tą patį matau ir organizacijose: nauda komandų produktyvumo lygmeniu reali, ir suprantu vadovus, kurie nori jos daugiau.
Viskas gražu, bet turime ir kitą medalio pusę. Ji dažniausiai nepasiekia vadovų arba jie pasirenka ją ignoruoti, ir būtent ji galiausiai nulems, ar produktyvumo šuolis apskritai atsipirks.
Kokia yra spartos kaina?
Trumpai: tikimybė, kad įlietas („merged“) kodo pakeitimas sukels incidentą gamybinėje aplinkoje, išaugo daugiau nei tris kartus. Kokybė blogėja greičiau, nei auga produktyvumas – ir kuo giliau DI įsitvirtina komandose, tuo blogėjimas spartesnis.
Antroji tų pačių Faros AI duomenų pusė atrodo taip: klaidų („bug'ų“) vienam inžinieriui padaugėjo 54 %. Incidentų ir „pull request'ų“ santykis išaugo daugiau nei tris kartus. Peržiūros laiko mediana pailgėjo penkis kartus. O pakeitimų, įliejamų be jokios peržiūros, padaugėjo 31 %.
Per tą patį laikotarpį DI sugeneruoto kodo priėmimo rodiklis pakilo nuo 20 % iki 60 %. Tyrimo autoriai daro išvadą: daugumoje organizacijų DI nebe asistuoja programuotojams, o jiems vadovauja („AI is not assisting developers. In most organizations, it is leading them.“).
Už šių skaičių slypi du žmogiški reiškiniai, kuriuos matau beveik kiekvienoje komandoje. Pirmas: agentai padarė lengvą darbo pradžią, bet ne pabaigą. Pradėti dešimt užduočių šiandien gali per valandą. Užbaigti jas taip, kad kokybė išliktų aukšta – vis dar sunkiausia dalis. Antras: labiausiai patyrę komandos nariai buvo palaidoti kodo peržiūrose. Jie tapo „reviewer'iais“, dirbančiais pilnu etatu. Brangiausia organizacijos techninė patirtis šiandien eikvojama klaidoms gaudyti, o ne krypčiai nustatyti, ir tuo pačiu jų motyvacija krenta, skeptiškumas auga.
Gal tikiesi, kad tavo komandas tai aplenks, nes procesai brandūs? Tyrimas šią iliuziją išsklaido: „Strong engineering foundations do not protect you.“ Aukšti DORA rodikliai, brandžios DevOps praktikos, drausmingi procesai – tokios organizacijos patiria tą patį kokybės smukimą kaip ir visos kitos. Su tuo visiškai sutinku: agentų inžinerija – nauja sritis, ir joje visi kol kas esame „junior“ lygio. Skirtumas tik tas, kad stiprios komandos dėl drausmingų procesų klaidas gamybinėje aplinkoje ištaiso greičiau.
Todėl klausimas ne „ar tai palies mus?“. Klausimas – ką organizacija daro pamačiusi pirmuosius produktyvumo šuolius. Ir būtent čia dalis vadovų žengia patį brangiausią žingsnį.
Kas nutinka, kai organizacija paskuba?
Problemos neišnyksta – jos pasislenka į dešinę („shift right“): iš kodo peržiūros į testavimą, iš testavimo į gamybinę aplinką, iš gamybinės – pas klientus.
Dalis organizacijų, pamačiusios pirmuosius produktyvumo šuolius, suskubo daryti išvadą: „vadinasi, mums reikia mažiau žmonių“. Bet skaičiai, kuriais jos rėmėsi, rodė tik kairę pusę – pagreitį. Dešinė pusė – incidentai, klaidos, peržiūrų skolos – pasirodo vėliau. Kai kodas jau gamybinėje aplinkoje, o žmonės jau už durų.
Ford už šią pamoką sumokėjo trejais metais ir milijardais dolerių. Įmonė kokybės kontrolę patikėjo dirbtinio intelekto sistemoms, o patyrusius inžinierius paleido – kartu su jais pro duris išėjo ir žinios, kuriomis tos sistemos turėjo remtis. „Mistakenly, we thought that by just introducing artificial intelligence… that would produce a high-quality product“, – pripažino Ford techninės inžinerijos viceprezidentas Charles Poon. Klaidingai manėme: įdiegsime DI – ir kokybė atsiras savaime. Galiausiai Ford pasamdė atgal 350 inžinierių veteranų. Taip, tai automobilių pramonė, ne agentų inžinerija – bet mechanizmas identiškas: patirtis išėjo anksčiau, nei kas nors suprato, kad būtent ji laikė kokybę.
Klarna tą patį pripažino dar 2025-aisiais: DI pakeitus apie 700 klientų aptarnavimo darbuotojų ir smukus aptarnavimo kokybei, vadovas pasakė „We went too far“ – ir vėl pradėjo samdyti žmones. Šie atvejai ne išimtys: 55 % vadovų, atleidusių darbuotojus dėl DI, šiandien pripažįsta klydę.
Atkreipk dėmesį į bendrą bruožą. Visos šios organizacijos sprendimus dėl žmonių priėmė pagal pirmuosius greičio rodiklius – disciplinoje, kurioje pačios dar buvo „junior“ lygio. Greitis buvo išmatuotas. Branda – ne.
Tad kokiais prietaisais agentų inžinerija matuojama šiandien ir kaip kiekvienas iš jų apgauna?
Kaip organizacijos matuoja agentų inžineriją šiandien?
Dažniausiai vienu iš keturių būdų. Visi keturi patogūs, visi keturi kažką parodo – ir visi keturi nutyli svarbiausią klausimą: ar komanda bręsta. Štai jie, nuo primityviausio iki subtiliausio.
Pirmas – DI sąskaitos dydis. Logika paprasta: kiek išleidžiame „token'ams“, tiek naudojame DI. Gerai: matoma finansų ataskaitoje, nereikia jokios papildomos infrastruktūros. Bet gauni tai, ką matuoji – komandos išmoksta deginti „token'us“, o ne kurti vertę. Silicio slėnyje šis reiškinys turi vardą – „tokenmaxxing'as“. Be to, kylant DI kainoms toks matas apskritai netvarus.
Antras – „pull request'ų“ skaičiaus augimas. Lyginant su praėjusiais metais, pažangios komandos fiksuoja 3–4x šuolį. Tai geras rodiklis: lengva matuoti, labai aiškus, verta stebėti nuolat. Bet jis neatsako į svarbiausią klausimą: kuriame brandos lygyje komanda dirba? 3–4x gali reikšti, kad komanda įvaldė pirmą lygį – delegavimą vienam agentui – ir ten apsistojo. O trečio lygio, orkestravimo, potencialas dar kelis kartus didesnis ir augimas čia eksponentinis: jei šiemet galima pasiekti 3–4x palyginti su 2025-aisiais, bręstanti komanda kitąmet turėtų rodyti 6–8x.
Trečias – DI indėlio dalis („AI Contribution Ratio“). Kokia dalis „pull request'ų“ sukurta kartu su DI. Globaliai priėmimo rodiklis pakilo nuo 20 % iki 60 %, o pažengusios komandos, kurias stebiu, jau ties 99 % – beveik visus jų PR autorystės prasme kuria agentai. Gerai: matai, kokią darbo dalį apskritai liečia DI, ir gali lyginti komandas tarpusavyje. Bet rodiklis turi lubas ir neturi gylio: nesimato, ar komanda išnaudoja visą agentų potencialą, ar naudoja juos tik paviršutiniškai. Kai daugiau nei 99 % kodo rašys DI – o tai tik laiko klausimas – šis skaičius nebebus svarbus.
Ketvirtas – naudojimo dažnumo apklausos. Koks procentas inžinierių DI įrankius naudoja kasdien, kas savaitę, kas mėnesį. Gerai: pamatai pasiskirstymą organizacijoje ir randi, kur DI naudojimas stringa – tipiškai inžinieriai adaptuojasi greičiau nei produkto („discovery“) komandos, ir šį atotrūkį verta žinoti. Deja, apklausų atsakymai šališki, o kai kasdienis DI naudojimas taps savaime suprantamas kaip el. paštas, klausimas apskritai praras prasmę.
Jei jau „su'vibecodine'inai“ savo „dashboard'ą“ matuoti komandas – sveikinu, esi toliau už daugumą, bet pasitikrink: ar nematuoji tai ką tiesiog lengva išmatuoti? Aktyvumo metrikos („pull request'ų“ skaičius, DI indėlio dalis ir pan.) nuteikia optimistiškai – skaičiai auga, visiems ramu, o atsakymo, ar organizacija iš tikrųjų bręsta, kaip nebuvo, taip ir nėra.
Koks šiandien yra svarbiausias agentų inžinerijos rodiklis?
Svarbiausias rodiklis šiandien – kiek atsakomybės gali patikėti agentams, išlaikant aukštą kokybę. Tai ir yra komandos agentų inžinerijos – arba, agentinės inžinerijos („agentic engineering“) – brandos matas.
Kodėl pabrėžiu „šiandien“? Nes disciplina per jauna, kad kas nors žinotų, kurios metrikos bus prasmingiausios kitais metais – brandžios komandos jas ilgainiui atsirinks pačios. O kol taisyklės nesurašytos, branda yra vienintelis matas, kuris nemeluoja. Ją matuoji pagal lygius, kuriuos aprašiau straipsnyje apie agentų inžineriją – čia panagrinėsiu giliau, ką kiekvienas jų reiškia komandos kasdienybėje.
Prieš gilinantis – dėsningumas, kuris kartojasi kiekviename lygyje. Komanda kaskart pereina tą patį vidinį ciklą: iš pradžių tvirtina kiekvieną agento veiksmą („human-in-the-loop“), o įgijusi pasitikėjimą ir susistačiusi saugiklius – paleidžia agentą dirbti savarankiškai ir tik prižiūri („human-on-the-loop“). Branda auga ne tada, kai komanda paleidžia daugiau agentų, o tada, kai išmoksta saugiai paleisti iš rankų daugiau atsakomybės.
Dar vienas svarbus akcentas: per lygius kyla ne komanda kaip visuma, o kiekvienas inžinierius atskirai, savo tempu. Komandos branda – tai jos žmonių brandos vidurkis: kai visi nariai stabiliai dirba, tarkime, virš antro lygio, antrame lygyje yra ir visa komanda. Todėl vadovui verta matyti abu pjūvius – komandos vidurkį, kuris rodo bendrą kryptį, ir kiekvieno inžinieriaus lygį, nes vidurkį aukštyn kelia ne įrankiai, o žmonių įgūdžiai.
0 lygis – DI kaip pašnekovas
Komanda naudoja DI pokalbio forma arba kaip pagalbininką integruotoje programavimo aplinkoje („IDE“). Iš pradžių DI darbo procese beveik nėra: komandos nariai kodą rašo patys, naudojasi DI pasiūlytais programinio kodo variantais arba įsikelia pasiūlymus iš pokalbio lango. Vėliau „IDE“ viduje jau dirba agentas, galintis pats leisti įrankius, bet kiekvieną jo veiksmą reikia tvirtinti rankiniu būdu – taip programuotojai pradeda suprasti, kaip agentas mąsto ir pamažu įgauna pasitikėjimą. Šiame lygyje programuotojo kasdienybė atrodo taip: kopijuoja klaidų išrašus („stack trace“) į pokalbį, trečią kartą iš naujo aiškina projekto architektūrą, po kiekvieno pakeitimo pats leidžia testus, dešimtis kartų per dieną šokinėja tarp užduočių sistemos ir kodo redaktoriaus. Šiame lygyje kodą vis dar rašo ir už jį atsako programuotojas, o patys įrankiai neleidžia atsitraukti – „human-in-the-loop“ be pasirinkimo. Čia šiandien yra dauguma organizacijų – ir nemažai jų mano, kad tai jau agentų inžinerija. Dar ne. Tai 2025-ieji – ir dabar tai jau priešistorė.
1 lygis – delegavimas vienam agentui
Programuotojas agentui patiki vientisą, didesnę užduotį – funkcionalumą, modulį, testus – ir vertina rezultatą, o ne kiekvieną žingsnį. Iš pradžių agentas persikelia į komandinę eilutę („CLI“) ir imasi kur kas didesnių, daugiažingsnių užduočių: jau prijungtas prie užduočių sistemos, pats leidžia testus, gal net diegia. Svarbiausius veiksmus programuotojas vis dar tvirtina pats – jis tampa atidžiu vis gabesnio kolegos prižiūrėtoju, o tvirtinimų daugėja ir kiekvienas reikalauja tikro įvertinimo, ne reflekso. Būtent čia komanda įgauna pamatinę agentų inžinerijos patirtį: apibrėžti agentus, valdyti leidimus ir kontekstą („context window“), pažinti modelius, dirbti planavimo režimais, naudoti įgūdžius („skills“), „hooks'us“ ir komandas, prijungti reikiamus įrankius. Vėliau ateina lūžis: agentas paleidžiamas „YOLO“ režimu, pakeitimai įgauna greitį, kurio programuotojas nebespėja sekti. Jis „atitolsta nuo kodo“ ir tampa prižiūrinčiu („human-on-the-loop“), o agentas užduotis atlieka nuo pradžios iki galo. Tam reikia neakivaizdžios kompetencijos – sutvarkytos aplinkos, kurioje agentas pats pasileidžia kompiliavimą, testus ir įrankius be žmogaus rankų. Būtent šiame lygyje gimsta tie šiuo metu įspūdingi 3–4x. Komanda pasiruošusi kilti, kai agentui patikimos užduotys didėja, o pataisymų po peržiūros – vis mažiau.
2 lygis – delegavimas keliems agentams
Keli agentai dirba lygiagrečiai su skirtingomis užduotimis, ir vidinis ciklas prasideda iš naujo. Iš pradžių kiekvienas agentas vis dar laukia žmogaus patvirtinimo, ir koordinavimas atima daug dėmesio: programuotojas be perstojo šokinėja tarp agentų, laukiančių jo „taip / ne“, o produktyvumo lubas nustato jo peržiūros greitis. Būtent šis spaudimas komandas perstumia toliau: 3–5 agentai sukasi lygiagrečiai skirtingose užduotyse ar kodo šakose, programuotojas dėmesį perjunginėja tarp agentų, o ne tarp užduočių, ir pradeda jaustis kaip maža komanda viename asmenyje. Paleisti kelis agentus be saugiklių – neatsakinga, todėl čia komanda privalo išmokti sukurti kokybės vartus („quality gates“) kiekviename proceso taške – statinę analizę, saugumo ir priklausomybių patikras – ir valdyti kokybę atgalinio spaudimo („backpressure“) principu. Atsiranda ir nauji įgūdžiai: užduočių skaidymas, agentų konteksto lango valdymas, rezultatų suderinimas. Būtent šiame lygyje komandos pirmą kartą pajunta anksčiau aprašytą spartos kainą – peržiūros tampa siauriausia vieta („bottleneck“), o patyrusieji rizikuoja virsti pilno etato „reviewer'iais“. Tobulėdamos šiame lygyje komandos vis labiau pasitiki savo ir agentų pajėgumais, o kodo ir galutinio produkto kokybė išgryninama taip, kad patikrai reikia vis mažiau žmogaus įsikišimo. Peržiūrų srautas susibalansuoja, labiausiai patyrę techniniai žmonės vėl randa laiko strateginiams žingsniams – ir tai juos atveda prie trečio lygio.
3 lygis – agentų orkestravimas
Komanda sustyguoja agentų tarpusavio darbą, kur vienų rezultatai yra pradiniai duomenys kitiems: agentai prižiūri kitus agentus, o vieno žmogaus priežiūroje gali suktis šimtai agentų. Grįžimo prie kiekvieno veiksmo tvirtinimo čia nebėra – šiame lygyje žmogus praktiškai visada „human-on-the-loop“. Jo vaidmuo keičiasi iš esmės: neberašo kodo ir nebeskaito jo eilutė po eilutės, o projektuoja procesą – kokybės vartus, automatines patikras, agentų tarpusavio peržiūras ir orkestravimo šablonus: nuoseklųjį, lygiagretųjį, maršruto parinkimo („routing“). Kartu sprendžia, kada užtenka pagalbinio agento („sub-agent“), o kada reikia skirstančiojo („router“). Programuotojas „vadovauja fabrikui“, o nebe „stovi prie staklių“. Čia slypi tas eksponentinis potencialas, apie kurį kalbėjau pasakodamas apie „pull request'ų“ skaičiaus augimo rodiklį.
Yra ir ketvirtas lygis – bet jis atskiro pokalbio tema, kurią nagrinėju mokymuose.
Kodėl Meta iš tikrųjų apsiskaičiavo?
Ne todėl, kad agentai neveikia, – o todėl, kad lūkesčiai buvo pastatyti ant aktyvumo pagreičio, o ne ant organizacijos brandos. Greitis be brandos matavimo – tai bėgikas, kuris matuoja tik tempą, bet ignoruoja pulsą: kurį laiką lekia įspūdingai greitai. Paskui pasitraukia iš trasos dar prieš finišą.
Esame pačioje agentų inžinerijos eros pradžioje – disciplinos, kurios matavimo modelių dar niekas nespėjo apibrėžti. Būtent todėl seni matavimo įpročiai čia ne tik neveikia, bet ir aktyviai klaidina. Nauda reali – įvairių rodiklių stebėjimas tą patvirtina. Kaina irgi reali – ir auga greičiau. Skirtumas tarp organizacijų, kurios laimės, ir tų, kurios sumokės gamybinėje aplinkoje, bus ne įrankiai ir ne sąskaitų dydis. Skirtumas – matavimo modelis ir vadovas, kuris supranta, ką matuoja.
„Code is cheap. Leadership isn't.“ Kodą rašyti pigu. Vadovauti – ne. Greitį šiandien gauni beveik dovanų. Žinoti, ką matuoti, ir vesti komandą į kitą brandos lygį – vadovo darbas, kurio nedeleguosi nei agentui, nei apklausai.
Jei nori tiksliai suprasti, kuriame lygyje tavo komanda ir kaip išmatuoti kelią į kitą – mano mokymuose tam skirta atskira dalis: matavimo karkasas, brandos lygiai ir konkretus planas agentų inžinerijos pradžiai tavo įmonėje.
