Når AI skriver og leverer koden, arbejder erfarne udviklere 19% langsommere

Softwareagenter som Devin, Claude Code og GitHub Copilot Workspace tager nu en opgavebeskrivelse, læser en kodebase, skriver kode, der løser opgaven, eksekverer tests, indtil de består, og åbner et pull request – uden at en udvikler skriver en eneste linje. Devin, bygget af Cognition AI, gør dette i isolerede cloudmiljøer. På tværs af den produktionsmæssige brugerbase bliver 67 pct. af de pull requests, agenten åbner autonomt, godkendt. Claude Code læser et helt repository, planlægger ændringer på tværs af flere filer, kører testsuiten og itererer uden instruktion mellem hvert trin. Disse værktøjer er i produktionsbrug, ikke i forskningsforhåndsvisninger.

Det, der adskiller dem fra tidligere kodegenereringsværktøjer, er feedback-loops. En forslagsmotor genererer tekst og stopper; en autonom agent genererer kode, kører den, læser, hvad der kommer tilbage, og prøver igen. Den underliggende stillads er den samme på tværs af værktøjer: en stor sprogmodel læser kontekst – kodebase, problembeskrivelse, fejllog – genererer en plan, eksekverer den gennem værktøjer som shell-kommandoer, filredigeringer og git-operationer, læser resultatet og reviderer. Løkken fortsætter, indtil agenten lykkes eller opbruger sit ressourcebudget.

Løkken, der erstattede editoren

Graden af autonomi på tværs af tilgængelige værktøjer spænder over tre niveauer. I den assisterede ende foreslår GitHub Copilot de næste par linjer, mens en udvikler skriver. Et niveau op omskriver multi-fil-editorer som Cursor på tværs af en kodebase efter udviklerens anvisning og foretager de ændringer, udvikleren specificerer. I den autonome ende opererer Devin og sammenlignelige systemer uafhængigt i længere perioder og træffer sekventielle beslutninger om, hvad der skal læses, hvad der skal ændres, og hvad der skal testes, og dukker kun op for godkendelser, som systemet ikke kan håndtere alene.

Det evalueringsframework, der måler fremskridt på tværs af disse værktøjer, er SWE-bench, skabt af forskere fra Princeton og Stanford. Det tester agenter på virkelige fejlrapporter fra open source Python-repositories – Django, Flask, scikit-learn – og måler, hvor stor en procentdel en agent kan lukke korrekt. Den nuværende højeste publicerede score på den kuraterede Verified-delmængde, 96 pct., tilhører Claude Opus 5. Det tal repræsenterer ægte kapacitet: evnen til at diagnosticere en virkelig softwarefejl, skrive en rettelse og bekræfte, at den består projektets egne tests.

Hvad benchmarken skjuler

96 pct.-scoren kommer med en vigtig asterisk. SWE-bench Verified er trukket fra 500 nøje udvalgte opgaver. Da forskere anvendte en kontamineringsresistent variant – SWE-bench Pro, designet ved hjælp af problemer, der ikke kunne have optrådt i nogen models træningsdata – faldt en tidligere model, der scorede over 80 pct. på Verified, til under 50 pct. på Pro. Noget af benchmarkpræstationen afspejler fortrolighed med evalueringssættet, ikke generaliseret problemløsningsevne. Kløften er en kendt forskningsudfordring, ikke en kritik af noget specifikt værktøj.

En separat undersøgelse fandt noget sværere at bortforklare. METR, en AI-sikkerhedsforskningsorganisation, gennemførte et randomiseret kontrolleret forsøg med erfarne open source-udviklere, der arbejdede på deres egne repositories. Udviklere, der brugte nuværende AI-kodningsværktøjer, var 19 pct. langsommere end dem, der arbejdede uden – på trods af at de uafhængigt estimerede, at de var 20 pct. hurtigere. Årsagerne var specifikke: tid brugt på at genprompte, når agenten producerede forkerte resultater, tid brugt på at verificere outputs før sammenlægning og den kognitive overhead ved at skifte mellem at dirigere en agent og følge, hvad agenten havde gjort. En benchmark tester, om en agent kan lukke en veldefineret fejl i isolation. Et randomiseret forsøg tester, om en udvikler arbejder hurtigere hen over en faktisk dag. De måler forskellige ting.

Hvorfor 93 pct. adoption kun gav 10 pct. gennemløbsforbedring

Kodeautonomi præsterer bedst på afgrænsede, veldefinerede opgaver: en reproducerbar fejl med klare input og output, en funktion med en præcis specifikation, en testsuite for et modul med defineret adfærd. Efterhånden som omfanget udvides til opgaver, der kræver implicit arkitekturviden, udokumenterede teamkonventioner eller beslutninger om produktretning, falder pålideligheden – ikke fordi modellerne mangler kapacitet, men fordi den kontekst, disse beslutninger kræver, ikke passer ind i systemet og ikke kan udledes af kodebasens filer alene.

Det praktiske skift ligger i, hvad arbejdet kræver. Udviklere, der arbejder med autonome agenter, bruger mere tid på at skrive specifikationer, der er præcise nok for en agent at eksekvere: detaljerede problembeskrivelser, klare testkontrakter, eksplicitte acceptkriterier. De bruger mere tid på at gennemgå kode, de ikke har skrevet, hvilket kræver en anden form for opmærksomhed end at skrive kode – at lede efter logikfejl, sikkerhedshuller og arkitektonisk drift, som agenten ikke selv vil markere. En undersøgelse fra 2026 af 121.000 udviklere viste, at 93 pct. regelmæssigt brugte AI-kodningsværktøjer; pull request-gennemløbet steg med omkring 10 pct. i samme gruppe. Flaskehalsen flyttede sig fra at skrive kode til at gennemgå den.

Det næste trin under aktiv udvikling er agenter, der selv styrer deres opgavekøer: modtage en projektspecifikation, opdele den i delopgaver, delegere mellem specialiserede modeller og kun dukke op for de beslutninger, der kræver menneskelig dømmekraft. Flere open source-frameworks til multi-agent kodningsorkestrering blev lanceret i 2026. Enterprise-adoption i produktionsmiljøer forbliver begrænset. Gartner forventer, at en betydelig andel af agentiske softwareprojekter påbegyndt i år vil blive afbrudt før 2028, når teams opdager afstanden mellem, hvad en kontrolleret demo viser, og hvad pålidelig implementering i stor skala kræver.

Tags: kunstig intelligens, Programmering, AI coding agents, kodeautonomi, softwareudvikling