Daugumoje agentinį programavimą diegiančių komandų kliūtis nuo generavimo persikelia į peržiūrą, o nepertvarkius šio ciklo bendras spartos prieaugis būna beveik nulinis.
Didelio masto CI aplinkose, kuriose kasnakt atliekami milijonai testų ir dirba šimtai inžinierių, vertingiausia agento užduotis yra nustatyti atsakingus asmenis ir atlikti pirminę analizę, o ne generuoti kodą.
Naudinga agento išvestis atlaiko nuodugnią patikrą ir paaiškina priežastinius ryšius, o ne tik atpažįsta dėsningumus.
Įrodymų rinkimo ir konteksto sudarymo sluoksnio projektavimas yra svarbesnis už generavimo sluoksnį.
Diskusijos apie agentinį programavimą dažniausiai vis dar prasideda nuo paprasto pažado: greičiau parašyti daugiau kodo.
Kartais šis pažadas išauga į ambicingesnę viziją, kurioje agentai planuoja darbus, kuria PR ir pateikia pakeitimus beveik be žmogaus įsikišimo. Tačiau daugumai inžinerijos komandų aiškiausia artimiausio laikotarpio nauda yra konkretesnė. Tai iteracijų sąnaudų mažinimas.
Programinės įrangos pateikimas neapsiriboja kodo generavimu. Kodo rašymas tėra vienas ilgesnio ciklo etapas; į šį ciklą taip pat įeina peržiūra, testavimas, diegimas ir problemų tyrimas. Dauguma komandų, kurios diegia agentinį programavimą nepertvarkydamos peržiūros ciklo, tik perkelia kliūtį į vėlesnį etapą.
Vien generavimo paspartinimas savaime nepadidina komandos darbo spartos. Dėl jo gali tiesiog prireikti daugiau pastangų peržiūrai, tikrinimui ir pasitikėjimui rezultatu užsitikrinti.
Daugelyje inžinerijos aplinkų brangiausia ne parengti pirmąjį variantą, o įsitikinti rezultatu.
Ar pakeitimas iš tiesų išsprendė problemą arba patobulino sistemą? Ar dėl jo kur nors kitur neatsirado regresija? Ar triktis slypi kode, aplinkoje, testuose ar priklausomybėje? Ar siūlomas pataisymas šalina priežastį, ar tik matomą simptomą?
Čia agentai gali padėti ne todėl, kad pakeičia inžinierius, o todėl, kad gali struktūruotai atlikti pirminę netvarkingų įrodymų analizę: patikrinti žurnalus, palyginti naujausius pakeitimus, apibendrinti reikšmingus signalus, atsekti tikėtinas priežastis, atlikti patikras ir pateikti žmogui rezultatą, kurį šis galėtų nuodugniai išnagrinėti.
Daugelyje komandų didžiausią naudą agentas teikia ne generuodamas kodą nuo nulio. Jo nauda – susiaurinti problemos paieškos erdvę, kad žmogui nereikėtų tam skirti daugybės valandų.
Tai ypač akivaizdu didelio masto derinimo procesuose. Įsivaizduokite, kad naktinė CI sistema atlieka milijonus testų kodų bazėse, kurias keičia šimtai inžinierių (vienam iš mūsų klientų tai – kasdienybė). Įvykus trikčiai sunku nustatyti, kas už ją atsakingas. Problema gali slypėti programos kode, priklausomybėje, testavimo infrastruktūroje ar kitoje technologijų dėklo dalyje. Žurnalai gali užimti gigabaitus, o problemą pirmoji pastebėjusi komanda ne visada yra už ją atsakinga.
Tokiai darbo eigai nebūtinai reikia vieno agento, kuris parašytų pataisymą. Jai reikia sistemos, kuri greitai susiaurintų problemos erdvę.
Naudingas procesas galėtų gauti žurnalus, atrinkti reikšmingus įrodymus, apibendrinti tai, kas svarbu, patikrinti kodą izoliuotoje aplinkoje ir pateikti struktūruotą pagrindinės priežasties analizę su patikimumo įverčiu, atsekamumu ir siūlomais tolesniais veiksmais. Kad būtų galima apskaičiuoti patikimumo įvertį, srities ekspertas įvertina pradinę agento išvestį. Tada šis įvertinimas pateikiamas LLM vertintojui, kad vėliau vertinimas būtų automatizuotas, bet išliktų suderintas su žmogaus sprendimu.
Siekiama ne atsisakyti inžinerinio vertinimo, o suteikti vertintojams tvirtesnį atspirties tašką. Regresijų pirminė analizė, PR peržiūra, testų taisymas, leidimo patvirtinimas ir tyrimas po diegimo yra panašaus pobūdžio. Visiems šiems procesams reikia daug įrodymų ir peržiūros, juose gausu neapibrėžtumo. Jais nesiekiama, kad agentas pakeistų inžinerijos procesą – jis tik turi padėti šį procesą tęsti.
Todėl komandos taip pat turėtų atidžiai rinktis, kaip vertinti šias sistemas.
Klaidinga klausti, ar agentas gali savarankiškai sukurti ką nors įspūdingo. Geriau klausti, ar jis pagerina realią darbo eigą, nesukeldamas papildomų kliūčių kitur.
Reikia įvertinti, ar išvestis pakankamai konkreti, kad ją būtų galima patikrinti, ar ji paaiškina priežastinius ryšius, o ne tik atpažįsta dėsningumus, ir ar dėl jos peržiūra tampa lengvesnė, o ne sunkesnė. Įtikinamas atsakymas nebūtinai yra naudingas. Praktiškai komandos pasitiki agento išvestimi, kai ši atlaiko nuodugnią patikrą ir suteikia ką nors konkretaus, ką galima patikrinti.
Esminė pamoka ta, kad naudingoms agentinėms sistemoms nepakanka vien generavimo. Jų veiksmingumas priklauso nuo to, kaip renkami įrodymai, sudaromas kontekstas, tikrinama išvestis ir vertintojui parodomas neapibrėžtumas.
Todėl mažai tikėtina, kad artimiausiu metu agentinė inžinerija vienu milžinišku šuoliu pasieks visišką autonomiją. Labiau tikėtini kruopščiai suprojektuoti ciklai, kuriuose agentai padės komandoms tikrinti, peržiūrėti, patvirtinti ir tobulinti savo darbą, tarp etapų išeikvojant mažiau pastangų.
Tai galbūt skamba ne taip įspūdingai kaip platesnė autonomijos vizija, tačiau daug tiksliau atspindi, kaip iš tiesų diegiamos naudingos sistemos.