Når AI skriver mere kode, end der kan testes

Af: Ole Chr. Hansen, Q Nation A/S

En ny ubalance i softwareudviklingen

Softwareorganisationer har i årtier forsøgt at øge udviklingshastigheden gennem bedre værktøjer, genbrug, automatisering, DevOps og agile arbejdsformer. Med generativ AI og kodningsagenter ændres tempoet på en mere grundlæggende måde. Udviklere kan få forslag til funktioner, tests, dokumentation og refaktorering på få sekunder. Agenter kan arbejde på tværs af filer, løse afgrænsede opgaver, oprette pull requests og reagere på fejl fra bygge- og testværktøjer.

Det skaber et attraktivt billede: flere features, kortere time-to-market og mindre tid brugt på rutinepræget kode. Men organisationens samlede leverancekapacitet består af mere end kodeproduktion. Kode skal forstås, reviews, integreres, testes, sikres, driftsmodnes og godkendes. Hvis én del af værdistrømmen accelererer kraftigt, mens de efterfølgende kontrol- og læringsaktiviteter udvikler sig langsommere, opstår der kø, ventetid og stigende risiko.

For testmanageren er dette ikke blot et kapacitetsproblem. Det er et styringsproblem. Mere kode betyder flere ændringer, flere mulige interaktioner og et større areal, hvor fejl kan gemme sig. Samtidig kan AI-genereret kode se overbevisende og professionel ud, selv når den bygger på forkerte antagelser, kopierer et uegnet mønster eller mangler robusthed og sikkerhed.

Den centrale udfordring er derfor ikke, om AI kan skrive kode. Det kan teknologien allerede. Udfordringen er, om organisationen kan skabe tilstrækkelig og rettidig evidens for, at den øgede ændringsmængde kan frigives forsvarligt.

Mere kode er ikke det samme som mere værdi

Kode er et mellemprodukt. Forretningsværdi opstår først, når en ændring løser et relevant behov og fungerer sikkert i den virkelige kontekst. En organisation kan derfor øge antallet af producerede kodelinjer, pull requests eller afsluttede udviklingsopgaver uden tilsvarende at øge kundeværdien.

Forskning i AI-assisteret softwareudvikling beskriver AI som en forstærker af organisationens eksisterende styrker og svagheder. Organisationer med stærke tekniske praksisser, hurtige feedbacksløjfer og god intern koordinering har bedre forudsætninger for at omsætte AI til værdi. Hvor systemet allerede er præget af teknisk gæld, langsomme reviews, ustabile testmiljøer og uklar prioritering, kan AI øge presset på de svage led.

Samtidig er evidensen for produktivitetsgevinster ikke entydig. METR (Forskningsorganisation med fokus på AI) undersøgte i 2025 erfarne open source-udviklere, der arbejdede på velkendte repositories. Udviklerne forventede selv at blive hurtigere med AI, men brugte i studiets konkrete kontekst længere tid. Resultatet kan ikke generaliseres til alle teams, opgaver eller værktøjer, men det udfordrer antagelsen om, at AI automatisk skaber nettogevinst. Tid brugt på at formulere opgaver, vente, kontrollere, rette og forstå genereret kode indgår også i regnestykket.

For testmanageren er pointen afgørende: Hvis ledelsen alene ser på udviklernes lokale output, kan den overse omkostningerne senere i værdistrømmen. En feature, der kodes på én dag, men kræver flere dages afklaring, review, fejlretning og regressionstest, er ikke nødvendigvis leveret hurtigere. Produktivitet skal måles fra idé til stabil værdi – ikke fra prompt til pull request.

Flaskehalsen flytter downstream

Når kodeproduktionen accelererer, flytter køen typisk til code review, integration, testmiljøer, sikkerhedskontrol, brugeraccept og release governance. Den klassiske reaktion er at bede testorganisationen om at “teste hurtigere” eller automatisere mere. Det kan være relevant, men løser ikke alene den strukturelle ubalance.

Testkapacitet er ikke blot antallet af testere eller automatiserede testcases. Den omfatter adgang til testbare builds, stabile miljøer, repræsentative data, tilstrækkelige testorakler, domæneviden, analysekapacitet og tid til at undersøge uventet adfærd. Hvis disse kapabiliteter ikke skalerer med ændringsmængden, bliver testarbejdet reaktivt.

En voksende kø skaber desuden sin egen risiko. Ændringer bliver større, fordi de venter længere på feedback. Udvikleren har mindre frisk kontekst, når en fejl opdages. Flere samtidige ændringer gør årsagsanalyse vanskeligere. Testmiljøer bliver belastede af parallelle leverancer, og teams konkurrerer om de samme specialister og testdata. Den øgede ventetid kan udligne eller overstige den tid, AI sparede i kodningen.

Det er derfor misvisende at placere problemet hos testen alene. Hvis organisationen skaber mere work-in-progress, end den kan validere og frigive, er der tale om et flowproblem. Den rigtige ledelsesreaktion er at balancere hele værdistrømmen, reducere batchstørrelser, forbedre testbarheden og begrænse mængden af samtidige ændringer.

AI-genereret kode ændrer risikobilledet

AI-genereret kode kan indeholde de samme fejltyper som menneskeskrevet kode: forkert logik, manglende validering, dårlig fejlhåndtering, performanceproblemer, sikkerhedssårbarheder og brud på arkitekturprincipper. Men produktionsmåden tilfører nogle særlige risici.

For det første kan genereringen øge variationen. To prompts til samme opgave kan give forskellige implementeringer, biblioteker og designvalg. For det andet kan koden være plausibel uden at passe til organisationens lokale konventioner, sikkerhedskrav eller driftsmodel. For det tredje kan udvikleren få et svagere mentalt ejerskab, hvis store dele accepteres uden dyb forståelse. Det gør review, fejlsøgning og senere vedligeholdelse vanskeligere.

AI kan også reproducere forældede eller usikre mønstre. Leverandørundersøgelser har rapporteret betydelige sikkerhedsproblemer i genereret kode. Sådanne tal skal læses kritisk, fordi opgaver, modeller og målemetoder varierer, men de understøtter en robust konklusion: funktionel korrekthed i et eksempel er ikke evidens for sikker og produktionsklar kode.

Endelig kan agentiske udviklingsværktøjer handle med større autonomi. De kan læse repositories, afvikle kommandoer, ændre konfiguration og interagere med eksterne services. Dermed bliver værktøjets rettigheder, datatilgang og modstandsdygtighed over for prompt injection en del af produktionsrisikoen. Organisationen skal ikke kun teste den genererede funktion; den skal også styre selve den mekanisme, der ændrer systemet.

Hvorfor mere testautomatisering ikke er hele svaret

Det er nærliggende at matche AI-genereret kode med AI-genererede tests. Kodningsassistenter kan skrive unit tests hurtigt, og agentiske løsninger kan forsøge at øge dækning eller reparere fejlende tests. Det er værdifuldt, men kan skabe en farlig symmetri: Den samme model eller kontekst producerer både implementeringen og beviset for, at implementeringen er korrekt.

En genereret unit test bekræfter ofte den adfærd, som koden allerede udviser, ikke nødvendigvis den adfærd, forretningen har brug for. Hvis kravfortolkningen er forkert, kan kode og test være enige om den samme fejl. Høj strukturel dækning kan derfor eksistere samtidig med manglende forretningsmæssig dækning.

Automatisering skalerer desuden kendte kontroller bedre end ukendt læring. Den er stærk til regression, kontrakter, regler og stabile orakler. Den er svagere, når testgrundlaget er uklart, brugeroplevelsen skal vurderes, komplekse systeminteraktioner skal forstås, eller nye risici skal opdages. Exploratory testing, domæneanalyse og tværfaglig risikovurdering bliver ikke mindre nødvendige, fordi regressionspakken vokser.

En større automatiseret testportefølje har også en vedligeholdelsesomkostning. Hvis AI producerer mange overlappende tests, kan køretid, fejlanalyse og falske alarmer vokse. En test, der er billig at generere, er ikke gratis at eje. Testmanageren bør derfor optimere efter informationsværdi og stabil feedback, ikke efter antallet af scripts.

Fra fuld regression til intelligent risikoselektion

Når ændringsmængden overstiger den tilgængelige testkapacitet, kan organisationen ikke løse problemet ved blindt at køre alt ved hver ændring. Den må vælge intelligent. Risikobaseret test bliver dermed ikke kun en planlægningsteknik, men en løbende mekanisme til at styre flow.

Valget bør kombinere flere signaler: ændringens forretningskritikalitet, kodens kompleksitet, berørte integrationer, historisk fejltæthed, sikkerhedseksponering, brugeromfang, observability og mulighed for sikker rollback. AI kan hjælpe med change-impact analysis og testselektion, men beslutningsgrundlaget skal være transparent nok til, at teams kan forstå, hvorfor bestemte tests vælges eller fravælges.

En praktisk model er at skabe forskellige testbaner. Lavrisikoændringer med stærke automatiserede kontroller kan få en hurtig bane. Ændringer i kritiske beregninger, adgangskontrol, dataflytning eller tværgående integrationer kræver dybere analyse, flere testniveauer og eventuelt uafhængigt review. Kontrolniveauet følger dermed risikoen i stedet for at være ens for alle ændringer.

Testmanageren bør samtidig beskytte et minimum af brede kontroller. Intelligent selektion må ikke blive en undskyldning for aldrig at gennemføre bred regression eller robusthedstest. Selektionen skal valideres mod fundne fejl og produktionshændelser: Hvilke fejl slap igennem, fordi relevante tests ikke blev valgt? Lærer modellen og processen af disse hændelser?

Kvalitet skal flyttes ind i kodeproduktionen

Hvis test først bliver involveret, når AI-genereret kode ligger klar til validering, er organisationen allerede bagud. Kvalitetskontroller skal indbygges i selve udviklingssløjfen. Det omfatter tydelige acceptkriterier, arkitekturregler, secure coding-standarder, statisk analyse, dependency scanning, kontrakttest og lokale testkrav før en ændring kan afleveres.

Det betyder ikke, at alle udviklere skal være testeksperter. Det betyder, at den hurtige kodeproduktion skal møde hurtige og tydelige kvalitetsbegrænsninger. En agent bør eksempelvis ikke få lov til at afslutte en opgave alene på baggrund af, at koden kompilerer. Den skal forholde sig til relevante tests, sikkerhedskrav, logning, fejlhåndtering og dokumentation.

Testmanageren kan bidrage ved at omsætte kendte fejlmønstre og produktrisici til maskinlæsbare kontrolmekanismer og reviewkriterier. Hvis organisationen gentagne gange oplever problemer med tidszoner, afrunding, rettigheder eller idempotens, bør disse erfaringer være en del af udviklingskonteksten og de automatiske kontroller.

Shift-left må dog ikke forstås som at flytte alt testarbejde til udviklerne. Nogle kvalitetsproblemer viser sig først i integration, realistisk belastning, drift eller faktisk brugeradfærd. En moden strategi kombinerer tidlige kontroller med observability, kontrollerede releases og læring fra produktionen.

Testbarhed bliver en strategisk kapabilitet

Jo mere kode der produceres, desto vigtigere bliver det, at systemet er let at observere, styre og isolere. Testbarhed reducerer tiden fra ændring til pålidelig feedback og er derfor en direkte modvægt til den nye flaskehals.

Et testbart system har tydelige interfaces, deterministiske komponenter, mulighed for kontrolleret dataopsætning, relevante logs og metrikker samt mekanismer til at simulere fejl. Integrationer kan valideres gennem kontrakter, og kritiske beslutninger kan forklares gennem sporbar logning. Feature flags og sikre rollback-mekanismer gør det muligt at begrænse konsekvensen af fejl.

Testbarhed skal behandles som et arkitektur- og produktkrav, ikke som testerens private problem. Testmanageren bør synliggøre, hvor manglende testbarhed skaber kø og omkostning. Hvis en ændring kræver flere dages manuel opsætning eller et ustabilt fælles miljø, er det et systemisk leveranceproblem.

AI kan hjælpe med at generere testhooks, mocks og observability-kode, men også her kræves styring. For mange test-specifikke genveje kan forvrænge produktionsadfærden eller skabe sikkerhedsrisici. Formålet er ikke at producere flest hjælpemekanismer, men at skabe pålidelig og repræsentativ kontrol.

Målinger, der afslører den virkelige flaskehals

Når AI indføres, har ledelsen brug for målinger, der viser effekten på hele systemet. Antal genererede linjer, accepterede AI-forslag eller afsluttede udviklingsopgaver fortæller kun om aktivitet. De kan endda skabe incitament til større ændringsmængde uden højere værdi.

Testmanageren bør følge gennemløbstid fra ændring til valideret release, køtid før review og test, ændringsstørrelse, fejlretningstid, ustabile tests, genåbnede defekter og change failure rate. Produktionshændelser, rollback-frekvens og kundepåvirkning viser, om den øgede hastighed er bæredygtig. Samtidig bør organisationen måle mængden af manuelt efterarbejde på AI-genereret kode.

Det er vigtigt at etablere en baseline før skalering. Uden et før-billede kan organisationen ikke afgøre, om AI faktisk har forbedret flowet, eller om udviklingen blot producerer mere arbejde til resten af systemet. Sammenligningen bør foretages på tværs af hele værdistrømmen og over tilstrækkelig tid til at fange vedligeholdelse og produktionskonsekvenser.

Målingerne skal bruges diagnostisk, ikke til at rangere individer. Hvis udviklere belønnes for output, mens testere måles på lukkede testcases, optimerer grupperne hver sin lokale del. Målet bør være hurtig levering af stabil værdi og reduceret usikkerhed.

Kompetencer og ansvar i den nye arbejdsdeling

Når AI skriver en større del af koden, ændres udviklerens rolle fra ren produktion mod specifikation, vurdering, integration og ansvar. Det samme sker i test. Testeren skal i mindre grad konkurrere med AI om at producere testtrin og i højere grad være ekspert i risiko, orakler, dækningsstrategi og kritisk evaluering.

Det kræver fortsat stærke tekniske og testfaglige grundkompetencer. En person kan kun bedømme genereret kode og tests sikkert, hvis vedkommende forstår domænet, arkitekturen og de relevante fejlmekanismer. Overafhængighed af AI kan ellers skabe en kompetencegæld, hvor organisationen mister evnen til selv at diagnosticere komplekse problemer.

Ansvar skal være entydigt. AI kan foreslå og udføre, men en identificerbar person eller rolle ejer accepten af ændringen. Review må ikke reduceres til en formalitet, og det skal være legitimt at afvise genereret kode, selv når det forsinker en lokal leverance.

Testmanageren får her en brobyggende rolle mellem udvikling, arkitektur, sikkerhed, drift og forretning. Opgaven er ikke at etablere en separat testmur, men at sikre, at kvalitetsrisici bliver forstået og håndteret gennem hele flowet.

En pragmatisk handlingsplan for testmanageren

Første skridt er at gøre ubalancen synlig. Kortlæg værdistrømmen fra behov til produktion og identificér, hvor arbejdet venter. Sammenlign ændringsmængde med review-, test- og releasekapacitet. Undersøg, om AI har reduceret samlet gennemløbstid, eller blot har flyttet køen.

Dernæst bør organisationen afgrænse AI-anvendelsen efter risiko. Definér, hvilke opgaver agenter må udføre, hvilke data og systemer de må tilgå, og hvilke kontroller der altid kræves. Start med små ændringer og korte feedbacksløjfer. Begræns work in progress, så teams ikke producerer en stor beholdning af uvalideret kode.

Styrk derefter de tekniske fundamenter: hurtige unit- og komponenttests, kontrakttest for integrationer, stabile pipelines, sikkerhedsscanning, repræsentative testdata og bedre observability. Automatisér de kontroller, der har stabile orakler og høj gentagelsesværdi, men reserver kapacitet til exploratory testing og komplekse risici.

Etablér en evaluering af AI-genereret kode. Brug repræsentative opgaver og sammenlign med en baseline. Mål ikke kun kodetid, men review, efterbearbejdning, defekter, vedligeholdelse og driftsstabilitet. Indsaml særlige fejlmønstre og før dem tilbage til prompts, kontrolmekanismer, arkitektur og kompetenceudvikling.

Endelig skal teststrategien gøres dynamisk. Når ændringsmængden, kodekritikaliteten eller modeladfærden ændrer sig, skal testindsatsen kunne justeres. En strategi skrevet før AI-indførelsen kan ikke forventes automatisk at håndtere en ny produktionsøkonomi.

Konklusion: Balancér flowet, ikke kun kodeproduktionen

AI kan gøre softwareudvikling hurtigere, men den kan også gøre det hurtigere at skabe uvalideret kompleksitet. Hvis kodeproduktionen accelererer uden tilsvarende forbedringer i review, testbarhed, automatiserede kontroller, miljøer og risikostyring, vokser køen og den resterende risiko.

Det betyder ikke, at testorganisationen skal forsøge at matche hver ny kodelinje med mere manuel test. Den skal hjælpe organisationen med at ændre måden, arbejdet flyder på: mindre batchstørrelser, færre samtidige ændringer, stærkere tidlige kontrolmekanismer, intelligent testselektion, bedre observability og kontrolniveauer, der følger risikoen.

Den vigtigste ledelsesindsigt er, at lokal hastighed ikke er det samme som samlet leveranceevne. Hvis AI gør udvikleren hurtigere, men reviewkøen længere, testmiljøet mere belastet og produktionsfejlene dyrere, har organisationen ikke skabt produktivitet. Den har skabt en hurtigere vej til sin næste flaskehals.

Testmanagerens rolle er derfor at flytte samtalen fra “Hvor meget kode producerer vi?” til “Hvor hurtigt kan vi skabe troværdig evidens for, at ændringen leverer værdi uden uacceptabel risiko?”

Når organisationen kan skalere denne evidens sammen med kodeproduktionen, bliver AI en reel accelerator. Indtil da bør mere kode betragtes som mere arbejde, der endnu ikke er bevist værdifuldt.