Ko razvoj pospešimo z umetno inteligenco, lahko količina sprememb hitro preseže zmogljivost ročnih pregledov in testiranja. Takšno ozko grlo upočasni objave, napake pa se lahko odkrijejo prepozno, ko so popravki zahtevnejši. Ključno vprašanje zato ni le, kako razvijati hitreje, temveč kako v enakem tempu ohraniti zanesljiv nadzor nad vsako spremembo.
Pri tem uporabljamo razvojni tok od razvojne veje posamezne funkcionalnosti, prek skupne razvojne veje, do veje za izdajo. Zato se vsi koraki zagotavljanja kakovosti ne izvajajo na isti točki procesa. Nekateri agenti delujejo že pred prvo združitvijo spremembe v skupno razvojno vejo, kjer pomagajo razvijalcem odkriti težave čim prej, drugi pa preverjanja izvajajo po združitvi, ko lahko spremembo ocenijo v širšem kontekstu celotne aplikacije. Pred pripravo izdaje so tako izvedena vsa ključna preverjanja kakovosti, pri čemer ostaja cilj enak: zagotoviti stabilno in preverjeno aplikacijo za objavo.
Posamezne korake zagotavljanja kakovosti smo povezali v sistem petih agentov. Vsak prevzame jasno določeno nalogo – od prvega pregleda zahteve za združitev kode do potrditve, da so avtomatski testi uspešno opravljeni in je objava varna.
Ta agent razvijalcu pomaga, še preden ta sploh odpre zahtevo za združitev kode. Pogleda, kaj se je v kodi spremenilo, in presodi, ali gre za nov uporabniški tok, ki ga še noben avtomatski test ne pokriva. Če je tako, sam napiše nove avtomatske teste zanj – po vzoru obstoječih, brez podvajanja dela, ki je že narejeno – in jih tudi zažene. Poleg tega glede na obsežnost spremembe izbere in požene tudi relevantne že obstoječe avtomatske teste, da preveri, ali je zaradi spremembe prišlo do nedelovanja dela aplikacije.
Agent se vključi ob vsaki zahtevi za združitev kode, še preden jo pogleda recenzent. Pozna pravila projekta, zato ne prijavlja stvari, ki so zanj morda videti narobe, so pa v resnici namerne. Prijavi tisto, kar dejansko šteje – napake, ki bi povzročile podrtje aplikacije in varnostna tveganja. Ob vsaki najdeni težavi tudi predlaga, kako naj jo razvijalec odpravi.
Agent ne piše in ne poganja ničesar – le presoja, ali sprememba potrebuje pokritost z avtomatskimi testi. Če avtomatskih testov ni, kjer bi morali biti, to javi in združitev spremembe se ustavi, dokler pokritost ni urejena – s tem prepreči, da bi netestirana funkcionalnost tiho pristala pri uporabnikih.
Ko se sprememba združi z glavno kodo, se v ozadju zažene celoten nabor avtomatskih testov. Namesto da bi razvijalec sam brskal po dolgih izpisih, agent pregleda vsak padli ali nestabilen avtomatski test, poišče vzrok in ga zna ločiti – ali gre za pravi hrošč v aplikaciji ali le za avtomatski test, ki je postal krhek zaradi manjše spremembe na strani. Pripravi pregleden povzetek stanja avtomatskih testov in v primeru resnih napak samodejno odpre prijavo z vsemi potrebnimi podatki.
Ta agent gre korak dlje – padle avtomatske teste poskuša popraviti sam. Najprej se prepriča, ali gre za pravo napako ali le za občasno nihanje, nato pa glede na to izbere pravi pristop. Ko je popravek narejen, ga ne vzame za samoumevnega, ampak avtomatski test požene še večkrat, da se prepriča, da rešitev res drži – šele takrat velja za zaključeno. Nič ne skriva in nič ne izklaplja; če nečesa ne zna popraviti, to prizna in prepusti človeku.
Pet agentov razvoja rutinske kontrole premakne tja, kjer so najbolj učinkovite – neposredno v razvojni tok – ekipi pa pusti presojo, odločanje in odgovornost. Tako se težave odkrijejo prej, popravki so hitrejši, standard izvedbe pa ostaja enak tudi takrat, ko se tempo razvoja poveča.
In rezultat razvojnega procesa pri katerem je preverjanje kakovosti vgrajeno v vsak korak? Kakovost.
Ko umetna inteligenca piše vse več kode, se pojavi paradoks: hitrost razvoja raste, a z njo tudi tveganje, da kakovost procesa postane slepa pega. Vprašanje ni več, ali nam umetna inteligenca pomaga -vprašanje je, ali še vedno razumemo, kaj gradimo.
Generativna umetna inteligenca dviguje učinkovitost razvojnih ekip na načine, ki so bili še pred kratkim nepredstavljivi. Na prvi pogled je to izključno dobra novica. A tu se pojavi vprašanje, ki ga v navdušenju pogosto preskočimo: kakovost kode je postala bolj merljiva kot kdajkoli prej – kakovost razvojnega procesa pa bolj nevidna.
Ko umetna inteligenca ustvari kodo, ki deluje, a je nihče ni resnično razumel; ko se testi pišejo po uvedbi, namesto pred njo; ko pregled izvorne kode postane formalnost nad generirano vsebino – se v ekipi kopiči procesni dolg. Ta je zahrbtnejši od tehničnega, ker ga ni mogoče izmeriti z orodjem za analizo kode. Pokaže se šele, ko gre kaj narobe.
V ekipi smo se tega problema lotili konkretno. Razvili smo UI agenta, ki samodejno zbira, analizira in strukturira podatke o napakah iz sistema za sledenje napakam ter jih postavlja v kontekst projektne dokumentacije. Njegov namen ni zgolj zbiranje statistike – je zaznavanje vzorcev, ki jih človeška ekipa v vsakodnevnem tempu spregleda.
Ideja izhaja iz preproste ugotovitve: napake niso samo tehnični, ampak tudi procesni signal. Če se iste napake pojavljajo znova in znova v istem modulu, to ne govori le o kodi – govori o tem, kako je bila funkcionalnost specificirana, kako je bila implementirana in kako je bila pregledana. Agent te vzorce bere samodejno, ne da bi kdo v ekipi to moral početi ročno.
Agent deluje v štirih fazah.
Najprej naloži kontekst: Prebere funkcionalne specifikacije iz projektne dokumentacije in zgradi model projekta – katere funkcionalnosti obstajajo, kako so opisane, kaj je bilo dogovorjeno. To je ključni korak, ki agenta loči od preprostega orodja za statistiko napak.
Nato pridobi napake: Iz sistema za sledenje napakam pobere vse napake za izbrano časovno obdobje, skupaj z vsemi metapodatki -z datumom nastanka, avtorjem prijave, statusom, zgodovino sprememb in posnetki zaslona.
Sledi klasifikacija: Vsako napako agent razvrsti po tipu (vizualna, vsebinska, logična, varnostna, performančna, integracijska), resnosti (kritična, visoka, srednja, nizka) in področju (frontend, backend, integracija, infrastruktura). Klasifikacija temelji na kombinaciji metapodatkov iz sistema za sledenje napakam in semantične analize naslova ter opisa napake. Hkrati agent vsako napako poveže z ustrezno uporabniško zgodbo iz specifikacije.
Na koncu sestavi poročilo: Strukturiran dokument z ugotovitvami.
Poleg osnovne statistike – koliko napak, katere vrste, kdo jih je prijavil – agent išče vzorce, ki so za ročno analizo prezahtevni.
Zazna ponavljajoče se vzorce: Besedne zveze, ki se pojavljajo v opisih napak znova in znova (npr. validacija, datum, uvoz, shranjevanje), kar pogosto kaže na sistemsko pomanjkljivost, ne na posamično napako.
Zazna skoke: Neobičajno visoko koncentracijo napak v kratkem obdobju, ki pogosto kaže na tvegan zajem ali slabo pregledano spremembo.
Oceni tudi kakovost samih prijav: Napake brez opisa ali brez korakov za reprodukcijo so signal, da ekipa nima skupnega standarda za poročanje.
Posebej zanimiv je razdelek kontekstualne analize, ki ga generira umetna inteligenca: ali porazdelitev napak kaže na slabo specifikacijo, tehnični dolg ali znake regresije; katera področja zahtevajo pozornost; kakšna je priporočena prioritizacija za naslednji sprint.
Saj že vrabci na strehi čivkajo o tem, a vseeno. Kakovost agentove analize je neposredno odvisna od kakovosti vhodnih podatkov. Če prijavljene napake nimajo opisov ali korakov za reprodukcijo, agent tega ne more nadomestiti. Agent torej ni samo orodje za analizo – je ogledalo procesne discipline ekipe.
Prav tako je klasifikacija napak po področjih omejena z natančnostjo opisa: agent sklepa na podlagi besedila, ne pozna pa notranje arhitekture sistema. Zato so rezultati najboljši tam, kjer so napake dobro opisane in kjer je projektna dokumentacija ažurna.
Avtonomna generacija kode je realnost, ki jo je nesmiselno zavračati. Naslednji korak ni upočasnitev – je odločitev, da procesu posvetimo enako pozornost kot kodi sami. Agent za poročanje napak je korak v tej smeri: ne nadomešča presoje ekipe, ampak ji daje podatke, ki jih brez avtomatizacije ne bi imela.
Kakovost programske opreme nikoli ni bila samo v tem, kakšna je koda. Vedno je bila v tem, kako nastane – in v ekipi, ki za to odgovarja.
