Agentisk KI trenger flere testere, ikke færre

Agentisk KI er i ferd med å endre måten programvare leveres på. Assistentverktøy utarbeider pull requests, agenter oppretter migreringer, og kodegjennomgangsroboter hevder at en endring er trygg før et menneske rekker å drikke ferdig kaffen. Bransjen framstiller ofte dette som en utvikling som vil føre til færre medarbeidere innen kvalitetssikring. Det er en bakvendt framstilling. Når maskiner skriver en større del av kodebasen, er den knappe ferdigheten ikke å generere kode. Det er å verifisere den uavhengig.

Utviklerundersøkelsen til Stack Overflow fra 2025 viste at 84 % av respondentene bruker eller planlegger å bruke KI-verktøy i utviklingsarbeidet, og at 51 % av profesjonelle utviklere bruker dem daglig. Andelen med et positivt syn falt til 60 %, og flere utviklere mistror aktivt nøyaktigheten til KI (46 %) enn har tillit til den (33 %). Den vanligste frustrasjonen, oppgitt av 66 %, var løsninger som nesten er riktige, men likevel ikke helt treffer. DORA-undersøkelsen rapporterte i 2025 at 90 % av fagfolk innen programvareutvikling hadde tatt i bruk KI, og at over 80 % mente KI hadde økt produktiviteten. Likevel rapporterte bare 24 % at de hadde svært stor eller stor tillit til KI. Når noe er nyttig uten å være til å stole på, utvides testerens arbeidsoppgaver – de blir ikke færre.

Høy hastighet er ikke et bevis

Jeg jobber som kvalitetsingeniør for programvare og fokuserer på agentisk testing og CI-kontroller for KI-skrevet kode. Internt lanserte vi en PR-kontrollør og en generator for testtilfeller. Begge er verktøy for å lage utkast. Ingen av dem vurderer sitt eget arbeid. Den regelen er viktig fordi agenter uttrykker seg skråsikkert. Skråsikkerhet er ikke det samme som å ha rett.

Vi lærte det på den kostbare måten. I en pilot med en KI-bygd PR-kontrollør passerte en endring CI på under 4 minutter. To dager senere viste et nedstrømsdashbord umulige temperaturer. En feil der omregningen fra Celsius til Fahrenheit var snudd, lå i en kodebane som testpakken aldri kjørte. CI-pipelinen var grønn. Produktet var feil. Grønn CI som aldri stilte det vanskelige spørsmålet, er bare skuespill.

Hendelsen inngår i et større mønster. CodeRabbits rapport om status for KI- kontra menneskeskapt kodegenerering analyserte 470 pull requests fra GitHub-prosjekter med åpen kildekode (320 skrevet i samarbeid mellom KI og mennesker, 150 bare av mennesker). KI-skrevne endringer førte til omtrent 1,7× flere problemer totalt. Logikk- og korrekthetsproblemer forekom 75 % oftere, og sikkerhetsfunn var opptil 2,74× flere. Veracodes rapport om sikkerheten til GenAI-kode fra 2026 testet modeller på ulike sikkerhetsoppgaver og fant en gjennomsnittlig beståttandel på 56 % i sikkerhetstester, knapt endret fra 55 % i den forrige rapporten. Samtidig førte omtrent 44 % av oppgavene for KI-kodegenerering til en kjent sårbarhet. Syntaksproblemet er nesten løst. Sikker og korrekt oppførsel er det ikke. Testerne er de som nekter å blande sammen de to tingene.

Hallusinerte avhengigheter er et testproblem

KI-generering finner også opp avhengigheter. USENIX Security 2025-studien Vi har en pakke til deg! undersøkte hallusinerte pakker på tvers av 16 LLM-er som genererer kode, og 576 000 prøver. Kommersielle modeller hallusinerte i gjennomsnitt pakker minst 5,2 % av tiden. Gjennomsnittet for modeller med åpen kildekode var 21,7 %, med 205 474 unike, hallusinerte pakkenavn. Vedvarende fantompakker gir angripere et enkelt mål for slop-squatting: De registrerer det oppdiktede navnet og venter på at en utvikler eller agent skal installere pakken.

Kontroll av avhengigheters opphav hører hjemme på samme nivå som funksjonstester. Hvis en agent finner opp en NuGet- eller npm-pakke, bør sammenslåingen stoppes før noen diskuterer hvor grundige enhetstestene var. Kontroll av opphav er ikke valgfri kvalitetssikring. Det er en kvalitetskontroll for endringer skrevet av KI.

Kontroller som skalerer med agentene

Da vi oppgraderte hele organisasjonen fra .NET 8 til .NET 10 på omtrent to uker ved hjelp av KI-assistert automatisering, hadde jeg ansvaret for kvalitetskontrollene. Hastigheten var reell. Det samme var behovet for kontroller som ikke stoler på agentens oppsummering. Kontrollene jeg kjører på endret kode, omfatter:

• Mål for mutasjonsscore på mellom 60 % og 70 % for endret logikk, slik at testpakken må avdekke reelle mutasjoner og ikke bare dekke kodelinjer
• Egenskapsbaserte tester av logikk med høy risiko, der eksempler alene ikke spesifiserer oppførselen godt nok
• Kontroller av avhengigheters opphav for å avdekke slop-squatting og hallusinerte pakker
• Signaler om duplisering og hyppige endringer som fanger opp agenters kopiering og omskriving
• Uavhengig verifisering av påstander fra agenter, som «migreringen er fullført», fordi en påstand er en hypotese helt til den underbygges av bevis

Mutasjonsscore er ikke et pyntetall. Den viser om testene dine oppdager en bevisst feil. Testdekningen kan øke selv om testpakken fortsatt overser Celsius-kodebanen. Egenskapsbaserte kontroller tvinger fram en modell av systemet som holder for ulike verdier, ikke bare for ett vellykket scenario. Kontroll av opphav stenger døren til pakkehyllen. Kontroller av hyppige endringer og duplisering fanger opp agentens vane med å skrive om samme idé på tre ulike måter. Til sammen gir de en bestemt innstilling: Gå ut fra at agenten tar feil helt til testpakken viser noe annet. Jeg minner om denne kalibreringen i kodegjennomgangen.

Ingen av disse kontrollene erstatter API-testing, autentiseringstesting, røykprøving eller automatisering av brukergrensesnitt. FlaUI og PowerShell fanger fortsatt opp det API-er ikke gjør. Pakking gjennom NuGet, MSI og MSM krever fortsatt validering av installasjon og stille installasjon. Agentiske arbeidsflyter øker omfanget. De gjør ikke disse fagområdene overflødige.

Flere testere, andre arbeidsoppgaver

Frykten er at agenter skriver testene, og at mennesker blir overflødige. Agenter kan utarbeide testtilfeller. De bør ikke godkjenne sine egne utkast. Respondenter i Stack Overflow-undersøkelsen som planlegger å bruke KI til testing i fremtiden, mener fortsatt at menneskelig mistillit er en viktig faktor: Når de ville bedt en annen person om hjelp, var den vanligste grunnen at de ikke stolte på svarene fra KI. Den instinktmessige skepsisen er yrkets styrke.

Det er viktig å ansette og legge til rette for folk som har kommet inn i faget via utradisjonelle veier. Jeg gikk over til kvalitetssikring etter en karriere innen HR-drift og data, fullførte en MS i informasjonssystemer ved UMBC i mai 2024, og bruker nå arbeidsdagene på å gjøre kvalitetsporter for agentisk KI praktisk anvendelige. Agentisk KI kommer ikke til å vente på at folk skal ha én bestemt bakgrunn. Faget trenger flere som kan utforme dokumentasjon, ikke færre som ukritisk godkjenner grønne bygg.

Produktspørsmålet er enkelt. Hvis agenter leverer raskere enn verifiseringen din klarer å tenke, har du ikke økt produktiviteten. Du har utsatt en hendelse. Invester i testere som behandler alle påstander fra agenter med skepsis, som bygger mutasjonstesting og proveniens inn i CI, og som beholder sin uavhengige dømmekraft der modellen er mest velformulert og minst pålitelig. Agentisk KI trenger flere testere, ikke færre.