Hos de fleste teams flytter agentisk kodning flaskehalsen fra generering til gennemgang. Nettogevinsten i hastighed er tæt på nul, hvis processen ikke forbedres.
I store CI-miljøer med millioner af natlige test og hundredvis af udviklere skaber en agent størst værdi ved at placere ansvar og foretage indledende fejlvurdering – ikke ved at generere kode.
Nyttige resultater fra en agent kan modstå kritisk gennemgang og forklarer årsagssammenhænge frem for blot at matche mønstre.
Udformningen af laget til indsamling af dokumentation og sammensætning af kontekst er vigtigere end genereringslaget.
De fleste diskussioner om agentisk kodning tager stadig udgangspunkt i et enkelt løfte: at skrive mere kode hurtigere.
Nogle gange udvikler det sig til en mere ambitiøs vision om agenter, der planlægger arbejdet, opretter PR'er og leverer ændringer med minimal menneskelig indgriben. Men for de fleste udviklingsteams er den tydeligste værdi på kort sigt mere afgrænset. Det handler om at reducere omkostningerne ved hver iteration.
Softwarelevering handler ikke kun om at generere kode. At skrive kode er kun ét trin i en længere proces, der omfatter gennemgang, test, udrulning og undersøgelse, når noget går galt. De fleste teams, der indfører agentisk kodning uden at gentænke gennemgangsprocessen, flytter blot flaskehalsen længere frem i forløbet.
Hurtigere generering gør ikke automatisk et team hurtigere. Det kan blot flytte mere arbejde over på gennemgang, verificering og opbygning af tillid.
I mange udviklingsmiljøer er det dyre ikke at fremstille et første udkast, men at nå frem til en sikker vurdering.
Løste ændringen rent faktisk problemet, eller forbedrede den systemet? Medførte den en regression et andet sted? Skyldes fejlen koden, miljøet, testene eller en afhængighed? Løser den foreslåede rettelse årsagen eller kun det synlige symptom?
Her kan agenter hjælpe – ikke fordi de erstatter udviklere, men fordi de kan foretage en struktureret første gennemgang af uoverskuelig dokumentation: undersøge logfiler, sammenligne nylige ændringer, sammenfatte relevante signaler, spore sandsynlige årsager, køre kontroller og levere noget, som et menneske kan efterprøve.
I mange teams skaber en agent størst effekt ved noget andet end at generere kode fra bunden. Den indsnævrer problemets søgerum, før et menneske bruger timevis på at gøre det manuelt.
Det ses særligt tydeligt i omfattende arbejdsgange til fejlfinding. Forestil dig, at et natligt CI-system kører millioner af test på tværs af kodebaser, som hundredvis af udviklere har ændret – sådan er virkeligheden for en af vores kunder. Når noget fejler, er det svært at finde frem til den ansvarlige. Problemet kan ligge i applikationskoden, en afhængighed, test-harnesset eller et andet sted i stakken. Logfiler kan fylde flere gigabyte, og det første team, der opdager problemet, er ikke altid det ansvarlige team.
I sådan en arbejdsgang er det ikke oplagt at lade én agent skrive rettelsen. Den egner sig til et system, der hurtigt indsnævrer problemområdet.
En nyttig pipeline kan hente logfiler, udvælge relevant dokumentation, sammenfatte det væsentlige, undersøge kode i en sandkasse og udarbejde en struktureret årsagsanalyse med sikkerhedsscore, sporbarhed og forslag til næste skridt. For at generere en sikkerhedsscore bedømmer en fagekspert agentens første resultat. Bedømmelsen gives derefter til en LLM, der fungerer som dommer, så fremtidige bedømmelser kan automatiseres og fortsat stemme overens med menneskelig vurdering.
Målet er ikke at fjerne udviklernes faglige vurdering, men at give dem, der gennemgår arbejdet, et bedre udgangspunkt. Indledende vurdering af regressioner, gennemgang af PR'er, reparation af test, validering af releases og undersøgelser efter udrulning har alle samme grundform. De kræver omfattende dokumentation og gennemgang og er fulde af tvetydigheder. De kræver ikke, at en agent erstatter udviklingsprocessen, men blot at den hjælper processen videre.
Derfor bør teams også nøje overveje, hvordan de evaluerer disse systemer.
Det forkerte spørgsmål er, om en agent isoleret set kan frembringe noget imponerende. Det bedre spørgsmål er, om den forbedrer en reel arbejdsgang uden at skabe friktion andre steder.
Det betyder, at man skal vurdere, om resultatet er konkret nok til at blive verificeret, om det forklarer årsagssammenhænge frem for blot at matche mønstre, og om det gør gennemgangen lettere i stedet for sværere. Et plausibelt svar er ikke nødvendigvis et nyttigt svar. I praksis har teams tillid til resultater fra en agent, når de kan modstå kritisk gennemgang og giver dem noget konkret at kontrollere.
Den vigtigere lære er, at nyttige agentbaserede systemer afhænger af mere end generering. De afhænger af, hvordan dokumentation indsamles, kontekst sammensættes, resultater kontrolleres, og usikkerhed synliggøres for den, der gennemgår arbejdet.
Derfor bliver den nærmeste fremtid for agentbaseret softwareudvikling næppe ét stort spring mod fuld autonomi. Den vil snarere bestå af en række omhyggeligt udformede processer, hvor agenter hjælper teams med at undersøge, gennemgå, verificere og forbedre deres arbejde med mindre spild mellem trinnene.
Det er måske mindre dramatisk end den overordnede fortælling om autonomi, men langt tættere på den måde, nyttige systemer rent faktisk bliver taget i brug på.