Tillidskløften i AI-genereret kode: udbredelsen er afgjort, ejerskabet er ikke

Fire undersøgelser offentliggjort hen over 2025 og 2026 har i stilhed afgjort en diskussion, branchen stadig var i gang med. Hver for sig er de en overskrift. Læst samlet beskriver de én forskydning, og det er ikke den, de fleste kommentarer handler om.

Udbredelsen er ikke længere spørgsmålet

DORA's rapport fra 2025 opgør den daglige brug til omkring 90 % af udviklerne. Det tal lukker diskussionen om udbredelse: der er ingen nævneværdig gruppe tilbage at overbevise, og en organisation, der overvejer, om den vil tillade AI-assisteret udvikling, tager stilling til noget, der allerede er sket.

Det, der ikke fulgte med, er tilliden. I Stack Overflows undersøgelse fra 2025 mistroede 46 % af udviklerne præcisionen i AI-værktøjer, mens 33 % stolede på den, og tallene for tillid er faldet år for år, mens brugen er steget. De, der er tættest på resultatet, er de mindst villige til at stå inde for det.

Et værktøj, som næsten alle bruger, og som flere mistror end stoler på, er ikke en fortælling om produktivitet. Det er en fortælling om styring.

Syntaksen er løst, sikkerheden er ikke

Veracodes test fra 2026 på over hundrede modeller giver den mistillid en form. Syntaktisk korrekthed er reelt et løst problem. Andelen af genereret kode, der består en sikkerhedstest, står stille på 56 %, stort set uændret fra året før, og uden sikkerhedsrettede prompts i testopsætningen.

Det ubehagelige er ikke tallet. Det er, at de to kurver peger hver sin vej set fra den, der skal gennemgå koden: jo mere flydende og troværdig den genererede kode bliver, jo dyrere bliver det at læse den kritisk. Kode, der ser færdig ud, bliver gennemgået som kode, der er færdig.

Afstanden, der ikke er blevet mindre

Gartner har opgjort, at kun 41 % af generative AI-prototyper i gennemsnit når i produktion. Kategorien er bred, og tallet er ikke et pejlemærke for det enkelte projekt, men det måler den samme afstand fra en anden vinkel: noget, der kan demonstreres, er ikke noget, en organisation kan drifte. Vi har beskrevet driftssiden af det i operationel AI over for AI-pilotprojekter, og mønstret er det samme, uanset om det er et modelbaseret pilotprojekt eller et vibe-kodet internt værktøj.

Flaskehalsen er altså flyttet. Den er ikke længere, hvad det koster at frembringe software, der virker. Den er, hvad det koster at kunne svare på, om den software man allerede har: hvem må ændre den, hvad gør den når den fejler, hvilke data rører den, og hvem står på mål, når den tager fejl.

Derfor dukkede specifikationsdrevet udvikling op nu

Fremkomsten af specifikationsdrevet værktøj — GitHubs Spec Kit er det tydeligste eksempel med sit forløb fra specifikation over plan og opgaver til implementering — bliver som regel forklaret som en måde at få bedre output fra en model. Det er den mindste halvdel. Den egentlige funktion er at placere hensigten et holdbart sted uden for den genererede kode, hvor den kan gennemgås, diskuteres og bevares, når implementeringen bliver kasseret.

Det er præcis den bevægelse, vi beskriver for forretningsbyggede prototyper i sådan bliver en forretningsbygget AI-prototype til produktionssoftware: prototypen er en kravspecifikation skrevet i det forkerte sprog, og arbejdet består i at udlede hensigten, klassificere hver del som bevar, genbrug efter verifikation eller byg om, og kræve dokumentation, før noget går i luften. Bevar hensigten som udgangspunkt; bevar kun den genererede kode, hvor den kan bestå en gennemgang.

Hvor det lander i fire dele af praksis

På indkøbssiden er det argumentet i sådan specificerer man AI i et udbud: at kræve en leverandørerklæring om, at ingen AI har skrevet nogen del af koden, kan hverken håndhæves eller give mening ret meget længere, mens krav om dokumenteret test, scanning, sporbarhed og navngivet ejerskab kan begge dele. På driftssiden beskriver at vide, at et AI-system stadig virker og pligterne som ibrugtager efter AI-forordningen, hvad der skal være på plads, efter systemet er sat i drift, og det er den halvdel af livscyklussen, en prototype aldrig rører.

Den holdning, vi vil forsvare

Det meste af det, der bliver skrevet om det her, behandler kvaliteten af AI-genereret kode som flaskehalsen og peger derfor på bedre modeller, bedre prompts eller bedre statisk analyse som svaret. Vi mener, det læser dokumentationen bagvendt. Kvaliteten bliver bedre; sikkerhedstallet fra 2026 står stille frem for at falde, og syntaksen er gået fra at være et reelt problem til at være et ikke-problem på cirka to år.

Det, der ikke er blevet bedre, er organisationens evne til at optage software, der ankommer hurtigere, end den kan gennemgås, ejes og driftes. Den evne er ikke en egenskab ved værktøjet. Den består af specifikationer, der overlever en implementering, gennemgange der fungerer som porte, og navngivet ansvar for systemer i drift. De teams, der bygger den, bliver ved med at blive hurtigere. De, der ikke gør, samler software op, der virker, og som ingen tør ændre, og det er et dyrere problem end det, AI-assisteret udvikling blev hentet ind for at løse.

Navngivet ansvar for et driftssystem er ikke en politik, man skriver én gang. Det skal overleve, at systemet skifter hænder, og det er den samme test, vi anvender i starten af enhver opgave om operationel AI: hvis den, der byggede det, forsvandt i morgen, kunne den næste så stadig se, hvad det gør, og hvorfor.

Er AI-genereret kode mindre sikker end kode skrevet af mennesker?

Den brugbare sammenligning er ikke menneske mod maskine, men gennemgået mod ikke-gennemgået. Veracodes test fra 2026 fandt, at omkring 56 % af den genererede kode bestod en sikkerhedstest uden sikkerhedsrettede prompts, og den andel har ikke rykket sig på et år. Den praktiske konklusion er, at genereret kode skal gennem de samme porte som al anden kode, i den mængde den nu ankommer i.

Hvorfor falder udviklernes tillid til AI-værktøjer, mens brugen stiger?

Fordi de to ting måler hver sit. Brugen måler, om værktøjet sparer tid på en opgave. Tilliden måler, om resultatet kan bruges uden at blive kontrolleret, og efterhånden som flere bruger værktøjerne til mere betydningsfuldt arbejde, har flere oplevet tilfælde, hvor det ikke kunne. Stack Overflows undersøgelse fra 2025 opgjorde 46 % med mistillid til præcisionen mod 33 % med tillid.

Hvad er specifikationsdrevet udvikling, og hvorfor nu?

Det er et forløb, der sætter en skreven specifikation, derefter en plan og derefter opgaver, foran implementeringen, med hensigten placeret uden for koden. Det er relevant nu, fordi genererede implementeringer er billige og udskiftelige, mens hensigten hverken er det ene eller det andet. En specifikation overlever en omskrivning; en promptlog gør ikke.

Hvad bør en organisation ændre først?

Gør ejerskabet eksplicit, før I gør noget som helst andet hurtigere. Ethvert system, der når produktion, skal have en navngiven ejer, en specifikation nogen kan læse, og en gennemgang, der faktisk kan sige nej. De tre ting gør resten af hastigheden forsvarlig at bruge.

Kilder

1. State of AI-assisted Software Development 2025 — DORA, Google Cloud
2. 2025 Developer Survey: AI — Stack Overflow
3. 2026 GenAI Code Security Report — Veracode
4. AI Maturity Matters: Proportion of AI and GenAI Prototypes Making It Into Production — Gartner
5. Spec Kit: spec-driven development — GitHub