Enamikus agentset kodeerimist kasutusele võtvates tiimides liigub pudelikael koodi loomisest ülevaatusse ning kui seda tsüklit ei parandata, on kiiruse netokasv nullilähedane.
Suuremahulistes CI-keskkondades, kus igal ööl tehakse miljoneid teste ja töötab sadu insenere, loob agent kõige rohkem väärtust vastutaja leidmisel ja probleemide esmasel analüüsil, mitte koodi genereerimisel.
Kasulik agendi väljund peab kontrollimisele vastu ja selgitab põhjuslikke seoseid, mitte ei piirdu mustrite sobitamisega.
Tõendite kogumise ja konteksti koostamise kihi kavandamine on genereerimiskihist olulisem.
Enamik arutelusid agentse kodeerimise üle algab endiselt lihtsast lubadusest: kirjutada rohkem koodi ja teha seda kiiremini.
Mõnikord kasvab sellest välja ambitsioonikam visioon, kus agendid kavandavad tööd, avavad PR-e ja viivad muudatused tootmisse inimese minimaalse sekkumisega. Enamiku inseneritiimide jaoks on lähiaja kõige selgem väärtus siiski kitsam. See seisneb iteratsioonikulu vähendamises.
Tarkvara tarnimine ei tähenda üksnes koodi genereerimist. Koodi kirjutamine on vaid üks etapp pikemas tsüklis, kuhu kuuluvad ülevaatus, testimine, juurutamine ja probleemide korral nende põhjuste uurimine. Enamik tiime, kes võtavad agentse kodeerimise kasutusele ülevaatustsüklit ümber kujundamata, nihutab pudelikaela lihtsalt protsessi hilisemasse etappi.
Ainuüksi genereerimise kiirendamine ei muuda tiimi automaatselt kiiremaks. See võib hoopis suurendada ülevaatusele, kontrollimisele ja usalduse loomisele kuluvat tööd.
Paljudes insenerikeskkondades pole kulukas mitte esimese versiooni loomine, vaid piisava kindlustunde saavutamine.
Kas muudatus lahendas probleemi või parandas süsteemi ka tegelikult? Kas see põhjustas kusagil mujal regressiooni? Kas tõrge peitub koodis, keskkonnas, testides või mõnes sõltuvuses? Kas pakutud parandus tegeleb põhjuse või ainult nähtava sümptomiga?
Agendid saavad siin abiks olla mitte seetõttu, et nad asendaksid insenere, vaid kuna nad suudavad teha korrastamata tõendite põhjal süsteemse esmase analüüsi: uurida logisid, võrrelda hiljutisi muudatusi, võtta kokku asjakohased signaalid, tuvastada tõenäolisi põhjuseid, teha kontrolle ja esitada tulemuse, mida inimene saab kriitiliselt uurida.
Paljudes tiimides ei loo agent kõige rohkem väärtust nullist koodi genereerides. Suurim väärtus seisneb probleemi otsinguruumi ahendamises enne, kui inimene kulutab selle käsitsi tegemisele tunde.
Eriti selgelt ilmneb see suuremahulistes silumistöövoogudes. Kujutage ette, et öine CI käitab miljoneid teste koodibaasides, mida muudavad sajad insenerid – ühe meie kliendi jaoks on see igapäevane reaalsus. Tõrke korral on vastutaja leidmine keeruline. Probleem võib peituda rakenduse koodis, sõltuvuses, täitmiskeskkonnas või mujal tehnoloogiapinus. Logide maht võib ulatuda gigabaitidesse ning probleemi esimesena märkav tiim ei pruugi olla selle eest vastutav.
Selline töövoog ei eelda loomupäraselt, et üks agent kirjutaks paranduse. See sobib süsteemile, mis ahendab probleemiruumi kiiresti.
Kasulik konveier võiks hankida logid, valida asjakohased tõendid, võtta olulise kokku, uurida koodi liivakastis ning koostada struktureeritud algpõhjuse analüüsi koos kindlushinnangu, jälgitavuse ja soovitatud järgmiste sammudega. Kindlushinnangu loomiseks hindab valdkonnaekspert agendi esialgset väljundit. Seejärel edastatakse see hindaja rollis LLM-ile, et edaspidine hindamine automatiseerida, säilitades samal ajal kooskõla inimese hinnanguga.
Eesmärk ei ole inseneride otsustusvõimet kõrvale jätta, vaid anda ülevaatajatele parem lähtepunkt. Regressioonide esmane analüüs, PR-ide ülevaatus, testide parandamine, väljalasete valideerimine ja juurutamisjärgne uurimine on kõik sarnase ülesehitusega. Need nõuavad palju tõendeid ja ülevaatamist ning sisaldavad rohkelt ebaselgust. Need ei eelda, et agent asendaks inseneriprotsessi, vaid aitaks sellel edasi liikuda.
Seetõttu peaksid tiimid hoolikalt kaaluma ka seda, kuidas nad neid süsteeme hindavad.
Vale küsimus on, kas agent suudab eraldiseisvalt midagi muljetavaldavat luua. Parem on küsida, kas see parandab tegelikku töövoogu, tekitamata mujal lisatakistusi.
See tähendab, et tuleb hinnata, kas väljund on kontrollimiseks piisavalt konkreetne, kas see selgitab pelga mustrite sobitamise asemel põhjuslikke seoseid ning kas see muudab ülevaatuse lihtsamaks, mitte keerulisemaks. Usutav vastus ei pruugi olla kasulik vastus. Praktikas usaldavad tiimid agendi väljundit siis, kui see peab kontrollimisele vastu ja pakub midagi konkreetset, mida üle kontrollida.
Sügavam õppetund on see, et kasulikud agentsüsteemid vajavad enamat kui genereerimist. Oluline on see, kuidas kogutakse tõendeid, koostatakse konteksti, kontrollitakse väljundeid ja tehakse määramatus ülevaatajale nähtavaks.
Seetõttu ei kujune agentse inseneritöö lähitulevik tõenäoliselt üheks hiigelhüppeks täieliku autonoomia poole. Tõenäolisemalt koosneb see läbimõeldult kavandatud tsüklitest, kus agendid aitavad tiimidel oma tööd uurida, üle vaadata, kontrollida ja täiustada, vähendades etappide vahel raisatud tööd.
See võib olla vähem dramaatiline kui laiem autonoomiavisioon, kuid vastab palju paremini sellele, kuidas kasulikke süsteeme tegelikult kasutusele võetakse.