Useimmissa tiimeissä agenttipohjainen koodaus siirtää pullonkaulan tuottamisesta katselmointiin. Ilman palautesyklin korjaamista nopeus ei juuri parane.
Laajoissa CI-ympäristöissä, joissa ajetaan miljoonia testejä öisin ja työskentelee satoja insinöörejä, agentin arvokkain tehtävä on ohjata ongelmat oikeille omistajille ja luokitella ne, ei tuottaa koodia.
Hyödyllinen agentin tuotos kestää tarkastelun ja selittää syy-yhteydet pelkän kaavojen tunnistamisen sijaan.
Todisteiden keräämisen ja kontekstin kokoamisen kerroksen suunnittelu on tärkeämpää kuin tuottamiskerroksen suunnittelu.
Agenttipohjaisesta koodauksesta käytävä keskustelu alkaa yhä useimmiten yksinkertaisesta lupauksesta: enemmän koodia nopeammin.
Joskus lupaus laajenee kunnianhimoisemmaksi visioksi, jossa agentit suunnittelevat työn, avaavat PR-pyyntöjä ja julkaisevat muutoksia lähes ilman ihmisen osallistumista. Useimmille ohjelmistokehitystiimeille selkein lähitulevaisuuden hyöty on kuitenkin rajallisempi. Kyse on iteroinnin kustannusten pienentämisestä.
Ohjelmistojen toimittaminen ei ole pelkkää koodin tuottamista. Koodin kirjoittaminen on vain yksi vaihe pidemmässä syklissä, johon kuuluvat katselmointi, testaus, käyttöönotto ja ongelmatilanteiden selvittäminen. Jos tiimi ottaa agenttipohjaisen koodauksen käyttöön uudistamatta katselmointisykliä, pullonkaula vain siirtyy prosessin myöhempään vaiheeseen.
Pelkkä tuottamisen nopeuttaminen ei automaattisesti nopeuta tiimin työtä. Se voi vain lisätä katselmointiin, varmentamiseen ja luottamuksen rakentamiseen tarvittavaa työtä.
Monissa ohjelmistokehitysympäristöissä kallista ei ole ensimmäisen version tuottaminen vaan riittävän varmuuden saavuttaminen.
Korjasiko muutos todella ongelman tai paransiko se järjestelmää? Aiheuttiko se regressiovirheen muualla? Johtuuko virhe koodista, ympäristöstä, testeistä vai riippuvuudesta? Korjaako ehdotettu ratkaisu syyn vai ainoastaan näkyvän oireen?
Agentit voivat auttaa tässä. Ne eivät korvaa insinöörejä, mutta voivat käydä jäsentämättömän todistusaineiston järjestelmällisesti läpi: tarkastaa lokeja, vertailla viimeaikaisia muutoksia, tiivistää olennaiset signaalit, jäljittää todennäköisiä syitä, suorittaa tarkistuksia ja palauttaa tuloksen, jota ihminen voi arvioida kriittisesti.
Monissa tiimeissä agentista saadaan suurin hyöty muualla kuin koodin tuottamisessa tyhjästä. Agentti voi rajata ongelman hakualuetta ennen kuin ihminen käyttää tunteja samaan työhön käsin.
Tämä näkyy erityisen selvästi laajamittaisen virheenkorjauksen työnkuluissa. Kuvittele öisin toimiva CI-järjestelmä, joka suorittaa miljoonia testejä satojen insinöörien muokkaamissa koodikannoissa. Yhdelle asiakkaistamme tämä on arkipäivää. Kun jokin epäonnistuu, ongelmaa on vaikea ohjata oikealle omistajalle. Ongelma voi olla sovelluskoodissa, riippuvuudessa, testien arviointikehyksessä tai muualla teknisessä pinossa. Lokien koko voi nousta gigatavuihin, eikä ongelman ensimmäisenä havaitseva tiimi aina vastaa sen aiheuttaneesta osasta.
Tällaisessa työnkulussa ei ole luontevaa antaa korjauksen kirjoittamista yhden agentin tehtäväksi. Siihen sopii järjestelmä, joka rajaa ongelma-alueen nopeasti.
Hyödyllinen käsittelyputki voisi hakea lokit, valita olennaisen todistusaineiston, tiivistää tärkeät tiedot, tarkastaa koodia eristetyssä ympäristössä ja tuottaa jäsennellyn juurisyyanalyysin, johon sisältyvät varmuusarvio, jäljitettävyys ja ehdotukset seuraavista vaiheista. Varmuusarvion muodostamista varten aihealueen asiantuntija arvioi agentin alkuperäisen tuotoksen. Arvio syötetään sitten tuomarina toimivalle Suurelle kielimallille, jotta pisteytys voidaan jatkossa automatisoida ja pitää samalla ihmisen arvion mukaisena.
Tarkoituksena ei ole poistaa insinöörien harkintaa vaan antaa katselmoijille parempi lähtökohta. Regressioiden luokittelu, PR-katselmointi, testien korjaaminen, julkaisun validointi ja käyttöönoton jälkeinen tutkinta ovat kaikki samankaltaisia prosesseja. Niissä käsitellään paljon todistusaineistoa ja tehdään runsaasti katselmointia, ja ne ovat täynnä monitulkintaisuutta. Agenttia ei pyydetä korvaamaan ohjelmistokehitysprosessia vaan ainoastaan auttamaan sen viemisessä eteenpäin.
Tästä syystä tiimien kannattaa myös harkita tarkkaan, miten ne arvioivat näitä järjestelmiä.
Väärä kysymys on, pystyykö agentti tuottamaan yksinään jotakin vaikuttavaa. Parempi kysymys on, parantaako se todellista työnkulkua aiheuttamatta kitkaa muualla.
On siis arvioitava, onko tuotos riittävän täsmällinen varmennettavaksi, selittääkö se syy-yhteydet pelkän kaavojen tunnistamisen sijaan ja helpottaako se katselmointia sen vaikeuttamisen sijaan. Uskottavalta kuulostava vastaus ei välttämättä ole hyödyllinen. Käytännössä tiimit luottavat agentin tuotokseen, kun se kestää tarkastelun ja tarjoaa jotakin konkreettista tarkistettavaksi.
Perimmäinen opetus on, että hyödylliset agenttipohjaiset järjestelmät tarvitsevat muutakin kuin sisällön tuottamista. Niiden toimivuus riippuu siitä, miten todistusaineisto kerätään, konteksti kootaan ja tuotokset tarkistetaan sekä miten epävarmuus tuodaan katselmoijan nähtäväksi.
Siksi agenttipohjaisen ohjelmistokehityksen lähitulevaisuus ei todennäköisesti ole yksi valtava harppaus täyteen autonomiaan. Todennäköisemmin käyttöön tulee joukko tarkasti suunniteltuja palautesyklejä, joissa agentit auttavat tiimejä tarkastamaan, katselmoimaan, varmentamaan ja hiomaan työtään niin, että vaiheiden välillä hukataan vähemmän aikaa ja vaivaa.
Tämä ei ehkä kuulosta yhtä dramaattiselta kuin visio laajasta autonomiasta, mutta se vastaa paljon paremmin tapaa, jolla hyödylliset järjestelmät todella otetaan käyttöön.