De fleste team som tar i bruk agentisk koding, flytter flaskehalsen fra generering til gjennomgang. Uten å forbedre denne sløyfen blir netto hastighetsgevinst nær null.
I store CI-miljøer med millioner av nattlige tester og hundrevis av utviklere er agentens mest verdifulle oppgave å finne ansvarlig team og foreta innledende feilsøking, ikke å generere kode.
Nyttige resultater fra en agent tåler kritisk gjennomgang og forklarer årsakssammenhenger, ikke bare mønstre.
Utformingen av laget for innhenting av dokumentasjon og sammenstilling av kontekst er viktigere enn genereringslaget.
De fleste diskusjoner om agentisk koding tar fortsatt utgangspunkt i et enkelt løfte: å skrive mer kode raskere.
Noen ganger utvides dette til en mer ambisiøs visjon der agenter planlegger arbeid, oppretter PR-er og leverer endringer med minimal menneskelig innblanding. Men for de fleste utviklingsteam er den tydeligste verdien på kort sikt mer avgrenset. Det handler om å redusere kostnadene ved iterasjon.
Programvareleveranse handler om mer enn å generere kode. Å skrive kode er bare ett trinn i en lengre sløyfe som omfatter gjennomgang, testing, utrulling og undersøkelser når noe går galt. De fleste team som tar i bruk agentisk koding uten å endre gjennomgangssløyfen, flytter bare flaskehalsen til et senere trinn.
Raskere generering gjør ikke automatisk teamet raskere. Det kan bare føre til at mer arbeid må legges i gjennomgang, verifisering og tillitsbygging.
I mange utviklingsmiljøer er det kostbare ikke å lage et førsteutkast, men å bli trygg på at løsningen holder.
Løste endringen faktisk problemet, eller forbedret den systemet? Førte den til en regresjon et annet sted? Ligger feilen i koden, miljøet, testene eller en avhengighet? Løser den foreslåtte rettelsen årsaken eller bare det synlige symptomet?
Her kan agenter hjelpe, ikke fordi de erstatter utviklere, men fordi de kan foreta en strukturert første gjennomgang av uoversiktlig dokumentasjon: undersøke logger, sammenligne nylige endringer, oppsummere relevante signaler, spore sannsynlige årsaker, kjøre kontroller og levere noe et menneske kan etterprøve.
I mange team er den mest verdifulle bruken av en agent ikke å generere kode fra grunnen av. Det er å avgrense søkeområdet rundt et problem før noen bruker timevis på å gjøre det manuelt.
Dette er spesielt tydelig i omfattende arbeidsflyter for feilsøking. Se for deg at nattlig CI kjører millioner av tester på tvers av kodebaser som hundrevis av utviklere arbeider med – slik virkeligheten er for en av kundene våre. Når noe feiler, er det vanskelig å finne riktig ansvarlig team. Problemet kan ligge i applikasjonskoden, en avhengighet, testrammeverket eller et annet sted i teknologistakken. Loggene kan være på flere gigabyte, og teamet som først oppdager problemet, er ikke alltid teamet som har ansvaret for det.
En slik arbeidsflyt tilsier ikke at én agent skal skrive rettelsen. Den egner seg for et system som raskt avgrenser problemområdet.
En nyttig behandlingskjede kan hente logger, velge relevant dokumentasjon, oppsummere det vesentlige, undersøke kode i et sandkassemiljø og utarbeide en strukturert rotårsaksanalyse med konfidensvurdering, sporbarhet og forslag til neste trinn. For å generere en konfidensvurdering vurderer en fagekspert agentens første resultat. Vurderingen mates deretter inn i en LLM som fungerer som dommer, slik at fremtidig poengsetting kan automatiseres og fortsatt samsvare med menneskelige vurderinger.
Målet er ikke å fjerne utviklernes faglige skjønn, men å gi dem som gjennomgår arbeidet, et bedre utgangspunkt. Innledende regresjonsanalyse, PR-gjennomgang, reparasjon av tester, validering av utgivelser og undersøkelser etter utrulling følger alle samme mønster. De krever mye dokumentasjon og gjennomgang og er fulle av tvetydigheter. De ber ikke en agent om å erstatte utviklingsprosessen, bare om å bidra til å drive den fremover.
Derfor bør team også være nøye med hvordan de vurderer disse systemene.
Det er feil å spørre om en agent kan skape noe imponerende isolert sett. Et bedre spørsmål er om den forbedrer en reell arbeidsflyt uten å skape friksjon andre steder.
Det innebærer å vurdere om resultatet er konkret nok til å kunne verifiseres, om det forklarer årsakssammenhenger fremfor bare å gjenkjenne mønstre, og om det gjør gjennomgangen enklere i stedet for vanskeligere. Et plausibelt svar er ikke nødvendigvis et nyttig svar. I praksis stoler team på agentens resultater når de tåler kritisk gjennomgang og gir dem noe konkret å kontrollere.
Den dypere lærdommen er at nyttige agentiske systemer avhenger av mer enn generering. De avhenger av hvordan dokumentasjon innhentes, kontekst sammenstilles, resultater kontrolleres og usikkerhet synliggjøres for den som gjennomgår arbeidet.
Derfor blir den nærmeste fremtiden for agentisk utvikling neppe ett stort sprang mot full autonomi. Mer sannsynlig blir det et sett med nøye utformede sløyfer der agenter hjelper team med å undersøke, gjennomgå, verifisere og forbedre arbeidet, med mindre bortkastet innsats mellom trinnene.
Det er kanskje mindre dramatisk enn den store fortellingen om autonomi, men ligger langt nærmere måten nyttige systemer faktisk tas i bruk på.