Lielākajai daļai komandu, kas ievieš autonomo programmēšanu, vājā vieta no koda ģenerēšanas pāriet uz pārskatīšanu; ja šo ciklu neuzlabo, kopējais ātruma pieaugums ir gandrīz nulle.
Liela mēroga nepārtrauktas integrācijas vidēs ar miljoniem testu ik nakti un simtiem inženieru vērtīgākais aģenta uzdevums ir noteikt atbildīgos un veikt sākotnējo problēmu analīzi, nevis ģenerēt kodu.
Noderīgs aģenta rezultāts iztur rūpīgu pārbaudi un izskaidro cēloņsakarības, nevis tikai atrod likumsakarības.
Pierādījumu apkopošanas un konteksta izveides slāņa projektēšana ir svarīgāka par ģenerēšanas slāni.
Vairums sarunu par autonomo programmēšanu joprojām sākas ar vienkāršu solījumu: ātrāk uzrakstīt vairāk koda.
Dažkārt tas pāraug vērienīgākā redzējumā, kurā aģenti plāno darbu, izveido izmaiņu pieprasījumus un ievieš izmaiņas ar minimālu cilvēka iesaisti. Tomēr lielākajai daļai izstrādes komandu tuvākajā nākotnē skaidrākais ieguvums ir šaurāks. Tas ir iterāciju izmaksu samazinājums.
Programmatūras piegāde nav tikai koda ģenerēšana. Koda rakstīšana ir tikai viens posms garākā ciklā, kas ietver pārskatīšanu, testēšanu, izvietošanu un problēmu izpēti, ja kaut kas noiet greizi. Komandas, kas ievieš autonomo programmēšanu, nepārveidojot pārskatīšanas ciklu, parasti tikai pārceļ vājo vietu uz vēlāku posmu.
Ātrāka ģenerēšana pati par sevi nepadara komandu ātrāku. Tā var vienīgi palielināt pārskatīšanai, pārbaudei un uzticēšanās veidošanai vajadzīgo darbu.
Daudzās izstrādes vidēs dārgi izmaksā nevis pirmā risinājuma uzmetuma izveide, bet gan pārliecības iegūšana par to.
Vai izmaiņas tiešām novērsa problēmu vai uzlaboja sistēmu? Vai tās neizraisīja regresiju citviet? Vai kļūme ir kodā, vidē, testos vai kādā atkarībā? Vai piedāvātais labojums novērš cēloni vai tikai redzamo simptomu?
Te var palīdzēt aģenti – nevis tāpēc, ka tie aizstāj inženierus, bet gan tāpēc, ka tie var veikt sākotnēju strukturētu sadrumstalotas informācijas analīzi: izpētīt žurnālus, salīdzināt nesenās izmaiņas, apkopot būtiskos signālus, noteikt iespējamos cēloņus, veikt pārbaudes un sniegt cilvēkam tālāk analizējamu rezultātu.
Daudzām komandām vērtīgākais aģenta lietojums nav koda ģenerēšana no nulles, bet gan problēmas iespējamo cēloņu loka sašaurināšana, pirms cilvēks velta vairākas stundas manuālai izpētei.
Tas īpaši skaidri redzams liela mēroga atkļūdošanas darbplūsmās. Iedomājies, ka nepārtrauktas integrācijas sistēma ik nakti izpilda miljoniem testu vairākās kodu bāzēs, kurās strādā simtiem inženieru (tā ir viena mūsu klienta realitāte). Ja rodas kļūme, ir grūti noteikt par to atbildīgo. Problēma var būt lietojumprogrammas kodā, atkarībā, testu izpildes ietvarā vai citā tehnoloģiju steka daļā. Žurnālu apjoms var sasniegt gigabaitus, un komanda, kas pirmā pamana problēmu, ne vienmēr ir par to atbildīga.
Šāda darbplūsma nav paredzēta tam, lai labojumu izstrādātu viens aģents. Tā ir piemērota sistēmai, kas ātri sašaurina problēmas iespējamo cēloņu loku.
Noderīga apstrādes plūsma varētu izgūt žurnālus, atlasīt būtiskos pierādījumus, apkopot svarīgāko, izpētīt kodu smilškastes vidē un sagatavot strukturētu pamatcēloņa analīzi ar pārliecības novērtējumu, izsekojamību un ieteiktajiem nākamajiem soļiem. Lai iegūtu pārliecības novērtējumu, attiecīgās jomas eksperts novērtē aģenta sākotnējo rezultātu. Pēc tam to nodod LVM kā vērtētājam, lai turpmāk automatizētu vērtēšanu, vienlaikus saglabājot atbilstību cilvēka vērtējumam.
Mērķis nav atteikties no inženieru spriestspējas, bet gan nodrošināt pārskatītājiem labāku sākumpunktu. Regresiju sākotnējai analīzei, izmaiņu pieprasījumu pārskatīšanai, testu labošanai, laidiena validācijai un izpētei pēc izvietošanas ir kopīga uzbūve. Šajos procesos daudz jāstrādā ar pierādījumiem un jāveic pārskatīšana, turklāt netrūkst neskaidrību. Aģentam nav jāaizstāj izstrādes process – tikai jāpalīdz to virzīt uz priekšu.
Tāpēc komandām arī rūpīgi jāapsver, kā tās vērtē šīs sistēmas.
Nav pareizi jautāt, vai aģents atsevišķā situācijā spēj radīt ko iespaidīgu. Labāk jautāt, vai tas uzlabo reālu darbplūsmu, neradot šķēršļus citviet.
Tas nozīmē vērtēt, vai rezultāts ir pietiekami konkrēts, lai to pārbaudītu, vai tas izskaidro cēloņsakarības, nevis tikai atrod likumsakarības, un vai tas pārskatīšanu atvieglo, nevis apgrūtina. Ticama atbilde ne vienmēr ir noderīga. Praksē komandas uzticas aģenta rezultātam, ja tas iztur rūpīgu pārbaudi un sniedz kaut ko konkrētu, ko var pārbaudīt.
Būtiskākā atziņa ir, ka noderīgām autonomām sistēmām nepietiek tikai ar ģenerēšanu. Tās ir atkarīgas no tā, kā tiek vākti pierādījumi un veidots konteksts, kā tiek pārbaudīti rezultāti un kā pārskatītājam tiek atklāta nenoteiktība.
Tāpēc autonomā programminženierija tuvākajā nākotnē, visticamāk, nesasniegs pilnīgu autonomiju ar vienu milzu lēcienu. Drīzāk attīstība notiks rūpīgi izstrādātos ciklos, kuros aģenti palīdz komandām izpētīt, pārskatīt, pārbaudīt un pilnveidot darbu, samazinot lieku piepūli starp posmiem.
Tas varbūt nav tik iespaidīgi kā plašākais autonomijas redzējums, taču daudz precīzāk atspoguļo noderīgu sistēmu ieviešanu praksē.