Agentisk AI har ændret måden, software bliver leveret på

Agentisk AI ændrer måden, software bliver leveret på. Assistenter udarbejder pull requests, agenter opretter migreringer, og kodegennemgangsrobotter hævder, at en ændring er sikker, før et menneske når at drikke sin kaffe færdig. Branchen fremstiller ofte dette som en vej til færre medarbejdere inden for kvalitetssikring. Den betragtning vender tingene på hovedet. Når maskiner skriver en større del af kodebasen, er den knappe kompetence ikke at generere kode. Det er uafhængig verificering.

Stack Overflows udviklerundersøgelse for 2025 viste, at 84 % af respondenterne bruger eller planlægger at bruge AI-værktøjer i udviklingen, og at 51 % af de professionelle udviklere bruger dem dagligt. Den positive holdning faldt til 60 %, og flere udviklere har en udtalt mistillid til AI’ens nøjagtighed (46 %) end tillid til den (33 %). Den største frustration, som 66 % nævnte, var løsninger, der næsten er rigtige, men alligevel ikke helt. Google Clouds DORA-undersøgelse for 2025 viste, at 90 % af de professionelle softwareudviklere anvendte AI, og at over 80 % mente, at AI øgede produktiviteten, men kun 24 % angav, at de havde meget stor eller stor tillid til AI. Når noget er nyttigt, men ikke vækker tillid, udvider det netop testerens arbejdsområde i stedet for at indskrænke det.

Hurtighed er ikke et bevis

Jeg arbejder som softwarekvalitetsingeniør med fokus på agentisk testning og CI-kontroller for AI-forfattet kode. Internt har vi lanceret en PR-kodegennemser og en generator af testtilfælde. Begge værktøjer udarbejder udkast. Ingen af dem bedømmer sit eget arbejde. Den regel er vigtig, fordi agenter udtrykker sig med sikkerhed. Sikkerhed er ikke det samme som korrekthed.

Det lærte vi på den dyre måde. I et pilotprojekt med en AI-baseret PR-kodegennemser gik en ændring gennem CI på under 4 minutter. To dage senere viste et nedstrøms dashboard umulige temperaturer. En ombytning af skaleringen fra Celsius til Fahrenheit lå i en kodevej, som testsuiten aldrig afprøvede. Pipelinen var grøn. Produktet var forkert. Grøn CI, der aldrig stillede det svære spørgsmål, er rent skuespil.

Den hændelse indgår i et bredere mønster. CodeRabbits rapport om status for AI-genereret kontra menneskeskabt kode analyserede 470 open source-pull requests på GitHub (320 skrevet i fællesskab af AI og mennesker, 150 udelukkende af mennesker). AI-forfattede ændringer medførte omkring 1,7× flere problemer samlet set, og problemer med logik og korrekthed forekom 75 % oftere, mens antallet af sikkerhedsproblemer var op til 2,74× højere. Veracodes rapport om sikkerheden i GenAI-kode fra 2026 testede modeller på tværs af sikkerhedsopgaver og fandt en gennemsnitlig beståelsesprocent for sikkerhed på 56 %, kun lidt ændret fra 55 % i den foregående rapport, mens cirka 44 % af AI-opgaverne med kodegenerering introducerede en kendt sårbarhed. Syntaks er næsten et løst problem. Sikker og korrekt adfærd er det ikke. Testere er dem, der nægter at forveksle de to ting.

Hallucinerede afhængigheder er et testproblem

Kodegenerering opfinder også forsyning. USENIX Security 2025-undersøgelsen Vi har en pakke til dig! evaluerede hallucinationer af pakker på tværs af 16 kodegenererende LLM’er og 576.000 prøver. Kommercielle modeller hallucinerede i gennemsnit pakker mindst 5,2 % af tiden; open source-modeller lå i gennemsnit på 21,7 % med 205.474 unikke hallucinerede navne. Vedvarende fantompakker skaber et oplagt mål for slop-squatting: Angribere registrerer det opfundne navn og venter på, at en udvikler eller agent installerer pakken.

Kontrol af afhængigheders oprindelse hører hjemme på samme niveau som funktionelle tests. Hvis en agent opfinder en NuGet- eller npm-pakke, skal sammenlægningen af ændringen afvises, før nogen diskuterer, om enhedstestene var grundige nok. Kontrol af oprindelse er ikke valgfri hygiejne. Det er en kvalitetskontrol for AI-forfattede ændringer.

Kontroller, der kan følge med agenterne

Da vi på organisationsplan opgraderede fra .NET 8 til .NET 10 på omkring to uger ved hjælp af AI-assisteret automatisering, havde jeg ansvaret for kvalitetskontrollerne. Hastigheden var reel. Det samme var behovet for kontroller, der ikke tror på agentens opsummering. De kontroller, jeg anvender på ændret kode, omfatter:

• Mål for mutationsscore i intervallet 60 % til 70 % for ændret logik, så testsuiten skal slå reelle mutanter ihjel i stedet for blot at dække kodelinjer
• Egenskabsbaserede tests af logik med høj risiko, hvor eksempler alene ikke specificerer adfærden tilstrækkeligt
• Kontrol af afhængigheders oprindelse for at beskytte mod slop-squatting og hallucinerede pakker
• Signaler om duplikering og hyppige ændringer, der afslører agenters omskrivninger af kopieret kode
• Uafhængig verificering af agenters påstande, såsom “migreringen er færdig”, for en påstand er en hypotese, indtil den underbygges af dokumentation

Mutationsscore er ikke et forfængeligt nøgletal. Den viser, om dine tests opdager en bevidst indført fejl. Testdækningen kan stige, samtidig med at testsuiten stadig overser Celsius-kodevejen. Egenskabsbaserede kontroller tvinger systemmodellen til at holde på tværs af intervaller, ikke kun for én problemfri kodevej. Kontrol af oprindelse lukker for adgang til pakker. Hyppige ændringer og duplikering afslører agentens vane med at omskrive den samme idé på tre måder. Tilsammen udgør de en tilgang: Gå ud fra, at agenten tager fejl, indtil testsuiten beviser det modsatte. Jeg fastholder den kalibrering i kodegennemgangen.

Intet af dette erstatter API-test, test af godkendelse, smoke-tests eller UI-automatisering. FlaUI og PowerShell fanger stadig det, som API’er overser. Pakning via NuGet, MSI og MSM kræver stadig validering af installationen og den lydløse installationsproces. Agentiske arbejdsgange øger mængden. De gør ikke disse discipliner overflødige.

Flere testere, anderledes arbejde

Frygten er, at agenter skriver testene, så mennesker bliver overflødige. Agenter kan udarbejde testcases. De bør ikke godkende deres egne udkast. Blandt Stack Overflow-respondenter, der planlægger at bruge AI til test fremover, står manglende tillid til AI stadig centralt: Når de ville bede en anden person om hjælp, var den vigtigste grund, at de ikke stolede på AI’s svar. Den indstilling er fagets styrke.

Det er vigtigt at ansætte og give muligheder til folk, der har fulgt utraditionelle karriereveje. Jeg skiftede til kvalitetsarbejde efter en karriere inden for HR-drift og data, færdiggjorde en kandidatgrad i informationssystemer på UMBC i maj 2024, og bruger nu mine dage på at gøre agentiske kontrolmekanismer praktisk anvendelige. Agentisk AI venter ikke på, at alle har den samme uddannelses- og karrierebaggrund. Der er brug for flere, der kan udforme dokumentation, ikke færre, der ukritisk godkender vellykkede builds.

Produktspørgsmålet er enkelt. Hvis agenter leverer hurtigere, end jeres verifikation kan følge med, er det ikke en produktivitetsgevinst. Det er en hændelse, der blot er udskudt. Investér i testere, der betragter enhver påstand fra en agent med skepsis, integrerer mutationstestning og proveniens i CI og fastholder en uafhængig vurdering dér, hvor modellen er mest velformuleret og mindst pålidelig. Agentisk AI har brug for flere testere, ikke færre.