Erfarne utviklere følte seg raskere med KI mens de jobbet målbart saktere — det egentlige funnet, og hvorfor det ikke er en dom over KI-koding

Erfarne utviklere følte seg raskere med KI mens de jobbet målbart saktere — det egentlige funnet, og hvorfor det ikke er en dom over KI-koding

Spør en erfaren programmerer om en KI-kodeassistent gjør arbeidet raskere, og du får som regel et tall til svar: Den sparer meg tjue, tretti prosent. Spør en økonom eller en maskinlæringsforsker, og tallet blir høyere. Tidlig i 2025 gjorde et team ved METR det langsomme og kostbare arbeidet og undersøkte saken. De tok seksten rutinerte utviklere av åpen kildekode, ga dem 246 reelle oppgaver fra store kodebaser de kjente godt, og lot dem — ved myntkast, oppgave for oppgave — enten bruke KI-verktøy eller la være. Deretter tok de tiden på arbeidet.

Utviklerne hadde anslått at KI ville redusere tiden per oppgave med rundt 24%. Det motsatte skjedde: Oppgavene som ble gjort med KI, tok 19% lengre tid. Og her er delen det er verdt å dvele ved — etterpå trodde de samme utviklerne fortsatt at KI hadde gjort dem rundt 20% raskere. De var langsommere og følte seg raskere, og avstanden mellom disse to tallene er det mest interessante ved studien.

Dette er et reelt, grundig målt resultat. Men det er også seksten utviklere, i kodearkiver de kjenner ut og inn, med verktøy fra tidlig i 2025 — og det er ikke det kategoriske utsagnet «KI gjør utviklere langsommere». Senere data fra det samme teamet peker allerede i motsatt retning.

Hva forfatterne gjorde

• Gjennomførte en randomisert kontrollert studie (METR: Joel Becker, Nate Rush, Beth Barnes, David Rein). Seksten erfarne utviklere av åpen kildekode jobbet hver for seg med et stort kodearkiv som de regelmessig bidrar til og kjenner godt — i gjennomsnitt hadde de jobbet fem år med de konkrete prosjektene.
• Brukte 246 reelle oppgaver — feilrettinger, funksjoner og refaktoreringer hentet fra prosjektenes egne sakssystemer. Hver oppgave ble tilfeldig tildelt «KI tillatt» eller «KI ikke tillatt».
• «KI tillatt» innebar verktøy fra tidlig i 2025: Cursor Pro med Claude 3.5/3.7 Sonnet. Hovedmålet var den faktiske tiden det tok å fullføre hver oppgave. I tillegg samlet teamet inn prognoser (fra utviklerne på forhånd) og anslag (fra dem etterpå), samt forutsigelser fra eksperter på økonomi og maskinlæring.

Hva de fant

• Med KI tok oppgavene 19% lengre tid. Ikke kortere — lengre. Konfidensintervallet på 95% går fra omtrent +2% til +39%, så retningen er sikker selv om den nøyaktige størrelsen ikke er det.
• Alle hadde forutsagt det motsatte. Utviklerne anslo en tidsgevinst på 24%, maskinlæringsekspertene rundt 38% og økonomene rundt 39%. Alle tre gruppene ventet at KI ville spare mye tid; stoppeklokken viste at det i stedet kostet tid.
• Oppfatningsgapet. Etter å ha gjort arbeidet og endt opp med å bruke lengre tid, anslo utviklerne fortsatt at KI hadde gjort dem rundt 20% raskere — et gap på omtrent 40 prosentpoeng mellom det de følte, og det klokken registrerte.
• Mulige årsaker, vurdert snarere enn bevist. Forfatterne trekker frem faktorer som kan forklare nedgangen: Disse utviklerne kjenner sine egne kodebaser inngående, så en assistent har mindre å tilføre; modne prosjekter har høye kvalitetskrav som ofte er underforståtte; kodearkivene er store og fulle av kontekst en modell ikke har; og det går reell tid med til å skrive prompter og deretter gjennomgå og rette opp KI-genererte resultater. De presenterer dette som spor, ikke konklusjoner.

Hva dette ikke viser

• Det viser ikke at KI ikke gjør de fleste utviklere raskere. Forfatterne sier det direkte: Seksten eksperter som arbeider med kode de kan utenat, er ikke gjennomsnittsutvikleren med gjennomsnittsoppgaven.
• Det viser ikke at KI er ubrukelig, eller at den gjør folk langsommere i andre situasjoner — nykommere i en kodebase, arbeid fra bunnen av, ukjente språk eller helt andre fagområder.
• Det forutsetter ikke at verktøyene står stille. Dette er Cursor og Claude 3.5/3.7 Sonnet fra tidlig i 2025; forfatterne er tydelige på at bedre verktøy, eller bedre måter å bruke disse på, kan endre resultatet selv i nøyaktig den samme situasjonen.
• Det er et preprint (lagt ut i juli 2025, ennå ikke fagfellevurdert), og forfatterne påpeker at de ikke helt kan utelukke artefakter ved eksperimentet — selv om funnet sto seg i analysene deres.
• Det gir ikke grunnlag for den beroligende tolkningen at utviklerne må ha oppnådd en annen gevinst — lært mer, vært gladere eller skrevet bedre kode. Det ene som ble målt her, den opplevde tidsgevinsten, er nettopp det dataene motsier.

Hvor sterke er bevisene

• Forsøksopplegget er uvanlig ærlig. Randomisert, reelle oppgaver, reelle kodearkiver, faktisk tidtaking — et stort skritt fremover fra egenrapporteringene og resultatlistene fra standardiserte tester som de fleste påstander om KI-koding bygger på. Tidsøkningen på 19% besto forfatternes robusthetskontroller.
• Det mest overførbare funnet er oppfatningsgapet. Ekspertenes intuisjon om sin egen tidsgevinst med KI tok feil med rundt 40 prosentpoeng, i optimistisk retning. Det er en advarsel om enhver egenrapportert produktivitetsgevinst fra KI — inkludert tallene fra denne studien.
• Det er et øyeblikksbilde, ikke en trend. METRs egen oppfølgingsstudie fra februar 2026, med den samme typen utviklere og nyere verktøy, peker mot en tidsgevinst — svært grovt −18% for tilbakevendende utviklere og −4% for nye — men forfatterne beskriver det som svake bevis, fordreid av hvem som var villige til å delta (utviklere avslo i økende grad å jobbe uten KI, betalingssatsen falt, og utvalget av oppgaver ble skjevt). Den ærlige tolkningen er at bildet er i bevegelse, og at selv bevegelsen rapporteres uten en tommel på vektskålen.

Hvorfor det er viktig

Det meste av diskusjonen om KI og programmering bygger på demonstrasjoner og magefølelse: et elegant skjermopptak, en skråsikker påstand, et avvisende himlende blikk. Det som er sjeldent, og som gjør dette verdt å lese, er at noen gjennomførte det kjedelige eksperimentet — randomiser, ta tiden på reelt arbeid, og spør deretter folk hvordan det gikk. Svaret er ubehagelig for begge leirer. Det punkterer fortellingen om at KI alltid gir erfarne utviklere turbofart på vanskelig, velkjent kode. Og det punkterer den ryddige motsetningen — «KI gjør utviklere langsommere, bevist» — fordi det samme teamets nyere data allerede heller i motsatt retning. Den mest varige lærdommen er også den minste og mest menneskelige: De som gjorde arbeidet, følte seg raskere mens de målbart var langsommere. «Det føles raskere» er ikke bevis på at det er det. Mål det.

Kort oppsummert

I en randomisert kontrollert studie lot METR seksten erfarne utviklere av åpen kildekode fullføre 246 reelle oppgaver i kodebaser de kjente godt, med KI-verktøy fra tidlig i 2025 (Cursor Pro pluss Claude 3.5/3.7 Sonnet) tillatt for en tilfeldig valgt halvpart. Utviklerne ventet at KI ville redusere tiden per oppgave med rundt 24%; i stedet økte den tiden med 19% — og etterpå trodde de fortsatt at KI hadde gjort dem rundt 20% raskere. Dette oppfatningsgapet er den skarpe, robuste kjernen i studien. Men det gjelder seksten utviklere, én snever situasjon og et fast øyeblikksbilde fra tidlig i 2025; forfatterne er tydelige på at det ikke viser at KI ikke hjelper de fleste utviklere, og deres egen oppfølging fra 2026 peker allerede mot en tidsgevinst, med sine egne forbehold. En grundig måling det er verdt å ta på alvor — ikke en dom over KI-koding.