Pri večini ekip, ki uvajajo agentsko kodiranje, se ozko grlo z ustvarjanja premakne na pregledovanje. Če tega cikla ne izboljšajo, je neto povečanje hitrosti skoraj nično.
V velikih okoljih CI z milijoni nočnih testov in stotinami inženirjev agent največ koristi prinese pri usmerjanju do odgovornih ekip in začetni obravnavi težav, ne pri ustvarjanju kode.
Uporaben rezultat agenta prestane temeljit pregled in pojasni vzročne povezave, ne le ujemanja vzorcev.
Zasnova plasti za zbiranje dokazov in sestavljanje konteksta je pomembnejša od plasti za ustvarjanje.
Večina razprav o agentskem kodiranju se še vedno začne s preprosto obljubo: hitreje napisati več kode.
Včasih se ta obljuba razširi v ambicioznejšo vizijo agentov, ki načrtujejo delo, odpirajo zahteve PR in uvajajo spremembe z minimalnim človeškim posredovanjem. Toda za večino inženirskih ekip je najočitnejša kratkoročna korist bolj omejena. Gre za zmanjšanje stroškov iteracij.
Dostava programske opreme ni zgolj ustvarjanje kode. Pisanje kode je le ena faza daljšega cikla, ki vključuje pregledovanje, testiranje, uvajanje in preiskovanje, ko gre kaj narobe. Večina ekip, ki uvede agentsko kodiranje, ne da bi preoblikovala cikel pregledovanja, svoje ozko grlo zgolj premakne v poznejšo fazo.
Hitrejše ustvarjanje samo po sebi ekipe ne naredi nujno hitrejše. Lahko le poveča količino dela, potrebnega za pregledovanje, preverjanje in vzpostavljanje zaupanja.
V številnih inženirskih okoljih ni najzahtevnejša priprava prvega osnutka, temveč pridobivanje zaupanja v rezultat.
Ali je sprememba res odpravila težavo oziroma izboljšala sistem? Ali je kje drugje povzročila regresijo? Ali je napaka v kodi, okolju, testih ali odvisnosti? Ali predlagani popravek odpravlja vzrok ali le vidni simptom?
Agenti lahko pri tem pomagajo, vendar ne zato, ker bi nadomestili inženirje. Opravijo lahko strukturiran prvi pregled nepreglednih dokazov: pregledajo dnevnike, primerjajo nedavne spremembe, povzamejo pomembne signale, sledijo verjetnim vzrokom, izvedejo preverjanja in vrnejo ugotovitve, ki jih lahko človek podrobneje preuči.
V številnih ekipah največ koristi ne prinese agent, ki ustvarja kodo povsem od začetka. Največ koristi prinese, ko zoži prostor iskanja okoli težave, še preden človek za ročno preiskovanje porabi več ur.
To je še posebej očitno pri obsežnih postopkih odpravljanja napak. Predstavljajte si nočno okolje CI, ki izvaja milijone testov v kodnih zbirkah, v katere posega na stotine inženirjev – tako je pri eni od naših strank. Ko nekaj odpove, je težavo težko usmeriti do odgovorne ekipe. Težava je lahko v aplikacijski kodi, odvisnosti, testnem ogrodju ali kje drugje v tehnološkem skladu. Dnevniki lahko obsegajo več gigabajtov, ekipa, ki prva opazi težavo, pa zanjo ni vedno odgovorna.
Takšen delovni proces po naravi ne zahteva enega agenta, ki bi napisal popravek. Zasnovan je za sistem, ki hitro zoži prostor možnih težav.
Uporaben potek lahko pridobi dnevnike, izbere relevantne dokaze, povzame bistvene informacije, pregleda kodo v peskovniku ter pripravi strukturirano analizo temeljnega vzroka z oceno zanesljivosti, sledljivostjo in predlaganimi naslednjimi koraki. Oceno zanesljivosti se določi tako, da področni strokovnjak najprej oceni začetni rezultat agenta. Ta ocena se nato posreduje velikemu jezikovnemu modelu v vlogi ocenjevalca, ki avtomatizira prihodnje ocenjevanje in ga hkrati ohranja usklajenega s človeško presojo.
Cilj ni odpraviti inženirske presoje, temveč pregledovalcem zagotoviti boljše izhodišče. Začetna obravnava regresij, pregled zahtev PR, popravilo testov, potrjevanje izdaj in preiskovanje po uvedbi imajo enako osnovno obliko. Vsi zahtevajo veliko dokazov in pregledovanja ter vsebujejo veliko nejasnosti. Od agenta ne zahtevajo, da nadomesti inženirski proces, temveč le, da ga pomaga premakniti naprej.
Zato morajo biti ekipe previdne tudi pri ocenjevanju teh sistemov.
Napačno vprašanje je, ali lahko agent samostojno ustvari nekaj impresivnega. Boljše vprašanje je, ali izboljša resnični delovni proces, ne da bi drugje povzročil dodatne ovire.
Preveriti je treba, ali je rezultat dovolj konkreten za preverjanje, ali pojasnjuje vzročne povezave in ne le prepoznava vzorcev ter ali pregledovanje olajša, namesto da bi ga otežil. Verjeten odgovor ni nujno tudi uporaben. V praksi ekipe zaupajo rezultatu agenta, kadar ta prestane temeljit pregled in jim ponudi nekaj konkretnega za preverjanje.
Globlji nauk je, da uporabni agentski sistemi zahtevajo več kot le ustvarjanje. Odvisni so od načina zbiranja dokazov, sestavljanja konteksta in preverjanja rezultatov ter od tega, kako je negotovost predstavljena pregledovalcu.
Zato kratkoročna prihodnost agentskega inženirstva najverjetneje ne bo en sam velik preskok k popolni avtonomiji. Verjetneje bo šlo za nabor skrbno zasnovanih ciklov, v katerih agenti ekipam pomagajo pregledovati, preverjati in izboljševati delo z manj nepotrebnega truda med posameznimi koraki.
To je morda manj dramatično od širše zgodbe o avtonomiji, vendar precej bolje odraža, kako se uporabni sistemi dejansko uvajajo.