2025-ųjų liepą Johns Hopkinso universiteto robotas be žmogaus pagalbos pašalino tulžies pūslę – tikruose audiniuose, prisitaikydamas prie kaskart kitokios anatomijos ir taisydamas savo paties klaidas. Startuolių ir tyrimų grupių, kuriančių tokius robotus, daugėja.
Kyla natūralus klausimas – kai chirurgines operacijas pradės perimti robotai, ar patikėsi robotų priežiūrą gydytojui, kuris pats niekada nėra operavęs?
Panašias diskusijas galime kelti ir programinės įrangos srityje: ar gali agentus prižiūrėti inžinierius, kuris niekada neprogramavo? Arba plačiau – koks inžinierius turi prižiūrėti agentus, kurių kodas 100 % keliauja į gamybines aplinkas? Iš karto prisipažinsiu – galutinio atsakymo neturi niekas. Esu paieškose, o ir pokytis pernelyg greitas, kad kas nors sąžiningai galėtų pasakyti „žinau“. Remiuosi savo patirtimi ir dviem žinomais programinės įrangos kūrimo inovatoriais – Claude Code kūrėju Borisu Cherny iš Anthropic ir Elizabeth Stone iš Netflix. Ten, kur jų mintys sutampa su tuo, ką matau praktikoje, dėliojasi tobulo agentų inžinieriaus („agentic engineer“) paveikslas.
Kodėl agentų inžinieriaus darbas yra empiriškas?
Programinės įrangos kūrimo procese iššūkius sprendžiame pakankamai apibrėžtai. Parenki šabloną („pattern“), gerąją praktiką („best practice“), biblioteką ar karkasą („framework“), pritaikai savo kode – ir problema išspręsta. Kuo didesnė patirtis, tuo lengviau parinkti ir pritaikyti, tuo didesnė tikimybė, kad suveiks. Šiandien vis didesnė darbo dalis atrodo kitaip. Šie sprendimai paliekami agentams, inžinierius eksperimentuoja su modeliais ir ieško, kaip suformuoti kontekstą ar kitaip sukurti terpę, kurioje iš DI „ištrauktų“ geriausią rezultatą. Vietoj recepto – bandymai, matavimai ir koregavimai – tai ir yra empiriškumas.
Borisas Cherny į modelį siūlo žiūrėti beveik kaip į gyvą būtybę. Kiekviena modelių karta elgiasi kitaip, turi kiek kitokį charakterį, ir tenka skirti laiko su ja susipažinti, o tada perderinti agentus atliepiant naujo modelio galimybes. Y Combinator pokalbyje jis tai suformulavo sakiniu, kuris yra vertas plakato: „it's not a theoretical science, it's become an empirical science“. Darbas su modeliais nebėra teorinis mokslas – jis tapo empiriniu. Pamiršk, ką išmokai apie ankstesnę modelių kartą: nauji elgsis kitaip – adaptuok savo agentus.
Čia galime apibrėžti pirmą bruožą: savo supratimą tobulas agentų inžinierius vertina kaip laikiną hipotezę ir tikrina ją eksperimentu, o ne atmintimi. Todėl pasirodžius naujam modeliui pirmiausia susipažįsta su skirtumais, kas pasikeitė, kokių instrukcijų jam nebereikia – ir tik tada bando. Patyręs agentų inžinierius dar bandys išspręsti problemas, kurių negalėjo išspręsti su ankstesniais modeliais. Po kelių modelių kartų taip dirbantis inžinierius atsiduria kitoje lygoje nei tas, kuris naujus modelius naudoja tik paviršutiniškai.
Kodėl negalima prisirišti prie to, ką sukūrei?
Empiriškumas turi ir skaudesnę pusę – tenka pamiršti tai, kas dar vakar veikė. Su naujausiais Anthropic modeliais iš agentų instrukcijų failų gali ištrinti apie 80 % teksto, ir rezultatas ne pablogės – pagerės. Tą patį padarė patys Anthropic: išleisdami naują modelį, iš Claude Code sisteminių instrukcijų išmetė maždaug 80 % teksto. Cherny patarimas dar griežtesnis: kas šešis mėnesius ištrink savo instrukcijas ir pažiūrėk, kaip elgsis modelis – tikėtina, rezultatas bus geresnis.
Popieriuje tai skamba kaip higiena. Praktikoje – kaip amputacija. Ištrinti savo rašytą kodą – tarsi griauti namą, kurį neseniai pastatei. Tą jausmą pažįstu ir pats. Dar iki vasaros kūrėme savo agentų orkestravimo variklius. Išėjus penktos versijos Anthropic modeliams – Sonnet 5, Opus 5, Fable 5 – padėjome juos į stalčių, nes modeliai išmoko orkestruotis patys. Mėnesių darbas. Ir vis dėlto sprendimas buvo teisingas: esmė ne pats trynimas, o gebėjimas neįstrigti prie to, ką sukūrei. „Unlearning“ kvadratu. Agentų amžiuje organizacija, kuri tik kaupia senas praktikas, optimizuojasi modeliui, kurio nebėra.
Taip greitai besikeičiančioje srityje tenka išmokti gyventi ir su dideliu naujienų triukšmu. Madingi terminai keičiasi kas mėnesį, o pagrindai – kaip veikia modeliai, agentai, programinė įranga – išlieka. Todėl pakanka sekti oficialius šaltinius ir skaityti oficialią dokumentaciją – to užtenka, kad neatsiliktum, bet tuo pačiu ir nepaskęstum „naujienų sriuboje“.
Šiame nuolatiniame pokytyje ilgametė patirtis įgauna kitą prasmę. Pagrindai netapo mažiau svarbūs – jie susitelkė į tuos dešimt procentų sprendimų, kurių agentui nepatikėsi: duomenų modelius, sistemų ribas, viską, ką vėliau brangu keisti net su agentais. Būtent ten šiandien atsiduria dvidešimties metų patirtis – ir būtent todėl agentų negali prižiūrėti žmogus, kuris pats niekada neprogramavo.
Kodėl Netflix ieško sisteminių mąstytojų?
Elizabeth Stone, Netflix produkto ir technologijų vadovė, Lenny tinklalaidėje į klausimą apie šią profesiją atsako taip: „we need more systems thinkers in a world with AI“ – DI pasaulyje reikia daugiau sisteminių mąstytojų. Siaura, gili specializacija jai atrodo vis labiau ribota, todėl Netflix samdo daugiau universalių kompetencijų specialistų. Savo komandose matau tą patį, ir ne todėl, kad taip madinga: specifinės srities darbas atitenka agentams, tad mąstymas turi pakilti lygiu aukščiau – apie visą sistemą ir jos kuriamą vertę, o ne tik apie savo „Jira ticket'ą“.
Gera žinia – sisteminio mąstymo, pasak Stone, galima išmokti. Tai įprotis, kurį gali ugdyti: spręsdamas problemą pažvelk į ją iš aukščiau ir paklausk – ar iš čia ji neatrodo kitaip? Ir kaip ją spręstum turėdamas naujus, galingus DI įrankius? Tik ilgai klausimų būsenoje neužsibūk – įstrigsi.
Empiriškumas, laisvė nuo savo kūrinių, gebėjimas naviguoti besikeičiančioje aplinkoje, sisteminis matymas – bruožai lyg ir aiškūs. Bet vien jų sąrašo neužtenka: dar svarbiau, kaip žmogus elgiasi, kai technologija keičia žaidimo taisykles greičiau, nei spėjame priprasti. Čia ir prasideda įdomiausia dalis.
Kodėl transformacijai reikia skeptikų?
Pradėsiu nuo nepatogios naujienos DI optimistams: skeptikai šioje transformacijoje – ne kliūtis, o būtina jos dalis, ir beveik visi esame tą stadiją praėję. Aš taip pat. Į teiginį, kad agentai netrukus rašys didžiąją dalį mūsų kodo, dar praėjusiais metais žiūrėjau lygiai taip, kaip šiandien dar daugelis: mandagiai linksėdamas ir netikėdamas nė vienu žodžiu.
Skeptikai yra įsitikinę: „DI šito nepadarys.“ Tai verdiktas, kuris užveria pokalbį. Bet tos abejonės organizacijai reikia: ji neleidžia pažado priimti be įrodymo ir verčia kalbėti demonstracijomis, matavimais, eksperimentais, o ne nuomonėmis. Skeptikas iškelia kartelę – ir ta kartelė naudinga net tada, kai dėl atsakymo jis klysta. Tad įdomiau ne tai, kaip skeptiką nutildyti, o kuo jis virsta, kai šią stadiją palieka.
Kas yra optimistiškas inžinierius?
Optimistiškas inžinierius yra įsitikinęs, kad agentai gali išspręsti beveik viską, tik jiems trūksta tinkamos aplinkos. Ten, kur skeptikas nukerta savo „DI šito nepadarys“, optimistas sako: „DI neturėjo reikiamos informacijos, kad tai padarytų.“ Iš pirmo žvilgsnio skirtumas atrodo nedidelis, bet keičia viską. Vietoj nuosprendžio technologijai optimistas spragą dokumentacijoje ar procese ištaiso ir dar pasimoko. Todėl optimistas į kiekvieną agento sesiją žiūri kaip į gabų naujoką, kuris perskaitys tik tai, kas užrašyta, – ir viską jam pateikia: kokybės reikalavimus, architektūros sprendimus, paaiškinimą, kam produktas apskritai egzistuoja. Ginčuose jis rodo ne argumentus, o veikiančias demonstracijas, ir naujus darbo būdus pirmiausia išbando savo projektuose, savo vardu. Visi bruožai, apie kuriuos kalbėjau iki šiol, – empiriškumas, laisvė nuo savo kūrinių, gebėjimas naviguoti besikeičiančioje aplinkoje, sisteminis matymas – yra būtent jo bruožai.
Ir vis dėlto būti optimistu neužtenka. Kai specifikacija, kodas, testai ir peržiūra sutelkti vienose rankose, klaidingą supratimą nėra kam užginčyti, ir klaidai atviras kelias į gamybinę aplinką. Patikra turi ateiti iš šalies. Todėl šalia optimisto reikia dar vieno balso.
Kuo konstruktyvus skeptikas skiriasi nuo paprasto?
Konstruktyvus skeptikas dėl technologijos nebesiginčija – jis netiki, kad sistema gali pasitikrinti pati. Jo pozicija: „DI tai gali, bet iš kur žinosim, jei padarys blogai?“ Ginčas persikelia nuo to, ką DI sugeba, prie to, ar pastebėsime jo klaidą, – o kasdienybėje užtenka trijų žodžių: „Iš kur žinosim?“ Šis klausimas tinka viskam – kodui, peržiūros procesui, įspūdingai demonstracijai.
Nuo paprasto skeptiko jį skiria trys požymiai. Pirma, jo abejonė baigiasi ne draudimu, o riba: agentams laisvę duodame ten, kur klaidą pigu atšaukti ir lengva pastebėti, – ir štai ką reikia įrodyti, kad ribą pastumtume toliau. Antra, jo abejonės virsta darbais – testų rinkiniais, testų mutacijomis, specialiai įterptomis klaidomis, rizikos žemėlapiais: paprasto skeptiko abejones girdi susirinkimuose, konstruktyvaus – matai kode. Trečia, jis nori būti paneigtas: kai jo nubrėžta riba įveikiama, pats pirmas tai paskelbia ir ribą praplečia. O skeptikas, kurio ribos metų metais nejuda, nors modeliai akivaizdžiai tobulėja, nebe atsargus – jis tiesiog įpratęs sakyti „ne“.
Kaip atrodo tobulas agentų inžinierius?
Tobulas agentų inžinierius talpina abi šias laikysenas – optimizmą, kuris kuria, ir skepsį, kuris tikrina, – ir moka jas keisti kaip kepures. Geriausi inžinieriai, kuriuos pažįstu, tai daro sąmoningai: šiandien kuria, rytoj patys bando sugriauti tai, ką sukūrė.
Žmonių, kurie įtikinamai nešioja abi kepures, nedaug. Todėl dažniausiai realus kelias – abi laikysenos vienoje komandoje: optimistas juda į priekį, konstruktyvus skeptikas jį tikrina ir kelia klausimus. Ne atvirkščiai, ir ši tvarka svarbi: pirma tempas, paskui ribos. Komandoje, kurioje priekyje eina skeptikas, niekas taip ir nepamato, ką agentai jau moka.
Kokį inžinierių augina tavo organizacija?
Grįžtu į operacinę. Roboto pjūvis tolygesnis už pavargusią ranką, ir tai nebe ateities klausimas. Roboto operacinėje aš nebijau. Bijau operacinės, kurioje robotą prižiūri niekada skalpelio nelaikęs žmogus, – ir lygiai taip pat tos, kurioje chirurgas atsisako net pažiūrėti, ką robotas jau moka. Pirmoji – optimizmas be supratimo. Antroji – skepsis be ribos. Tobulas agentų inžinierius yra atsakymas į abi baimes vienu metu.
Tavo organizacijoje beveik neabejotinai jau dirba ir optimistų, ir skeptikų. Klausimas vienas: ar jie sujungti į sistemą, ar tyliai trukdo vienas kitam. Pirmuoju atveju turi agentų inžineriją – arba agentinę inžineriją, – kurios ribos juda tokiu greičiu, kokiu ateina naujovės. Antruoju – du talentus, kurie vienas kitą stabdo.
„Code is cheap. Leadership isn't.“ Kodą rašyti pigu. Vadovauti – ne. Tobulo agentų inžinieriaus darbo skelbimu nenusipirksi – jį augini: optimistus, kuriems saugu bandyti, skeptikus, kurių abejonės virsta darbais, ir sistemą, kurioje jie stiprina vienas kitą. Jei šias paieškas nori tęsti, tam skirti mano mokymai vadovams.
