Erfarne udviklere følte sig hurtigere med AI, mens de arbejdede målbart langsommere — det egentlige resultat, og hvorfor det ikke er en dom over AI-kodning

Erfarne udviklere følte sig hurtigere med AI, mens de arbejdede målbart langsommere — det egentlige resultat, og hvorfor det ikke er en dom over AI-kodning

Spørg en erfaren programmør, om en AI-kodeassistent får arbejdet til at gå hurtigere, og du vil som regel få et tal til svar: Den sparer mig tyve, tredive procent. Spørg en økonom eller en maskinlæringsforsker, og tallet bliver større. I begyndelsen af 2025 gjorde et team hos METR det langsomme og dyre arbejde og undersøgte sagen. De tog seksten rutinerede open source-udviklere, gav dem 246 virkelige opgaver fra store kodebaser, de kendte godt, og lod dem — ved møntkast, opgave for opgave — enten bruge AI-værktøjer eller lade være. Derefter tog de tid på arbejdet.

Udviklerne havde forudsagt, at AI ville reducere tiden pr. opgave med omkring 24%. Det modsatte skete: Opgaverne udført med AI tog 19% længere tid. Og her er den del, det er værd at dvæle ved — bagefter troede de samme udviklere stadig, at AI havde gjort dem omkring 20% hurtigere. De var langsommere og følte sig hurtigere, og afstanden mellem de to tal er det mest interessante ved undersøgelsen.

Det er et reelt og omhyggeligt målt resultat. Men det er også seksten udviklere, i kodearkiver, de kender ud og ind, med værktøjerne fra begyndelsen af 2025 — og det er ikke det kategoriske udsagn ”AI gør udviklere langsommere”. Senere data fra det samme team peger allerede i den anden retning.

Hvad forfatterne gjorde

• Gennemførte et randomiseret kontrolleret forsøg (METR: Joel Becker, Nate Rush, Beth Barnes, David Rein). Seksten erfarne open source-udviklere arbejdede hver især på et stort kodearkiv, som de regelmæssigt bidrager til og kender godt — i gennemsnit havde de arbejdet fem år på de konkrete projekter.
• Brugte 246 virkelige opgaver — fejlrettelser, funktioner og refaktoreringer hentet fra projekternes egne opgavestyringssystemer. Hver opgave blev tilfældigt tildelt ”AI tilladt” eller ”AI ikke tilladt”.
• ”AI tilladt” betød værktøjer fra begyndelsen af 2025: Cursor Pro med Claude 3.5/3.7 Sonnet. Det primære mål var den faktiske tid, det tog at færdiggøre hver opgave. Derudover indsamlede teamet prognoser (fra udviklerne på forhånd) og skøn (fra dem bagefter) samt forudsigelser fra eksperter i økonomi og maskinlæring.

Hvad de fandt

• Med AI tog opgaverne 19% længere tid. Ikke kortere — længere. Konfidensintervallet på 95% går fra omtrent +2% til +39%, så retningen er sikker, selv om den præcise størrelse ikke er det.
• Alle havde forudsagt det modsatte. Udviklerne forudsagde en tidsgevinst på 24%, maskinlæringseksperter omkring 38% og økonomer omkring 39%. Alle tre grupper forventede, at AI ville spare en masse tid; stopuret viste, at det i stedet kostede tid.
• Opfattelseskløften. Efter at have udført arbejdet og være endt med at bruge længere tid vurderede udviklerne stadig, at AI havde gjort dem omkring 20% hurtigere — en forskel på omkring 40 procentpoint mellem det, de oplevede, og det, uret registrerede.
• Mulige årsager, afvejet snarere end bevist. Forfatterne fremhæver faktorer, der kan forklare nedgangen: Disse udviklere kender deres egne kodebaser indgående, så en assistent har mindre at bidrage med; modne projekter har høje kvalitetskrav, som ofte er underforståede; kodearkiverne er store og fulde af kontekst, en model ikke har; og der går reel tid med at formulere prompts og derefter gennemgå og rette AI-genererede resultater. De præsenterer dette som spor, ikke konklusioner.

Hvad dette ikke viser

• Det viser ikke, at AI ikke formår at gøre de fleste udviklere hurtigere. Forfatterne siger det direkte: Seksten eksperter, der arbejder med kode, de kan udenad, er ikke gennemsnitsudvikleren med gennemsnitsopgaven.
• Det viser ikke, at AI er ubrugelig, eller at den gør folk langsommere i andre situationer — nytilkomne til en kodebase, arbejde fra bunden, ukendte sprog eller helt andre fagområder.
• Det fastfryser ikke værktøjerne. Dette er Cursor og Claude 3.5/3.7 Sonnet fra begyndelsen af 2025; forfatterne er tydelige om, at bedre værktøjer eller bedre måder at bruge disse på kan ændre resultatet selv i præcis den samme situation.
• Det er et preprint (offentliggjort i juli 2025, endnu ikke fagfællebedømt), og forfatterne påpeger, at de ikke helt kan udelukke artefakter ved forsøget — selv om resultatet holdt i deres analyser.
• Det giver ikke belæg for den beroligende fortolkning, at udviklerne må have opnået en anden gevinst — lært mere, været gladere eller skrevet bedre kode. Den ene ting, der blev målt her, den oplevede tidsgevinst, er netop det, dataene modsiger.

Hvor stærke er belæggene

• Forsøgsdesignet er usædvanligt ærligt. Randomiseret, virkelige opgaver, virkelige kodearkiver, faktisk tidtagning — et stort skridt frem i forhold til den selvrapportering og de ranglister over benchmarkresultater, som de fleste påstande om AI-kodning bygger på. Tidsforøgelsen på 19% bestod forfatternes robusthedskontroller.
• Det mest overførbare resultat er opfattelseskløften. Eksperternes intuition om deres egen tidsgevinst med AI tog fejl med omkring 40 procentpoint i den optimistiske retning. Det er en advarsel om enhver selvrapporteret produktivitetsgevinst fra AI — inklusive denne undersøgelses egne tal.
• Det er et øjebliksbillede, ikke en trend. METR’s egen opfølgning fra februar 2026, med den samme type udviklere og nyere værktøjer, peger mod en tidsgevinst — meget groft −18% for tilbagevendende udviklere og −4% for nye — men forfatterne betegner det som svage belæg, fordrejet af, hvem der var villige til at deltage (udviklere afslog i stigende grad at arbejde uden AI, betalingssatsen faldt, og udvælgelsen af opgaver blev skæv). Den ærlige fortolkning er, at billedet bevæger sig, og at selv bevægelsen rapporteres uden en finger på vægtskålen.

Hvorfor det er vigtigt

Det meste af diskussionen om AI og programmering bygger på demonstrationer og mavefornemmelser: en elegant skærmoptagelse, en skråsikker påstand, et afvisende rul med øjnene. Det sjældne, og det, der gør dette værd at læse, er, at nogen gennemførte det kedelige eksperiment — randomiser, tag tid på virkeligt arbejde, og spørg så folk, hvordan det gik. Svaret er ubehageligt for begge lejre. Det punkterer fortællingen om, at AI altid sætter turbo på erfarne udviklere, når de arbejder med svær, velkendt kode. Og det punkterer den enkle modsætning — ”AI gør udviklere langsommere, bevist” — fordi det samme teams nyere data allerede hælder i den anden retning. Den mest holdbare lære er også den mindste og mest menneskelige: De mennesker, der udførte arbejdet, følte sig hurtigere, mens de målbart var langsommere. ”Det føles hurtigere” er ikke belæg for, at det er det. Mål det.

Kort fortalt

I et randomiseret kontrolleret forsøg lod METR seksten erfarne open source-udviklere færdiggøre 246 virkelige opgaver i kodebaser, de kendte godt, med AI-værktøjer fra begyndelsen af 2025 (Cursor Pro plus Claude 3.5/3.7 Sonnet) tilladt for en tilfældigt valgt halvdel. Udviklerne forventede, at AI ville reducere tiden pr. opgave med omkring 24%; i stedet øgede den tiden med 19% — og bagefter troede de stadig, at AI havde gjort dem omkring 20% hurtigere. Denne opfattelseskløft er undersøgelsens skarpe og robuste kerne. Men det gælder seksten udviklere, én snæver situation og et fast øjebliksbillede fra begyndelsen af 2025; forfatterne er tydelige om, at det ikke viser, at AI ikke hjælper de fleste udviklere, og deres egen opfølgning fra 2026 peger allerede mod en tidsgevinst med sine egne forbehold. En omhyggelig måling, der er værd at tage alvorligt — ikke en dom over AI-kodning.