Når AI skriver og leverer koden, jobber erfarne utviklere 19% langsommere

Programvareagenter som Devin, Claude Code og GitHub Copilot Workspace tar nå en oppgavebeskrivelse, leser en kodebase, skriver kode som løser oppgaven, kjører tester til de består, og åpner en pull request – uten at en utvikler skriver en eneste linje. Devin, bygget av Cognition AI, gjør dette i isolerte sky-miljøer. På tvers av den produserende brukerbasen blir 67 prosent av pull requestene den åpner autonomt slått sammen. Claude Code leser et helt repositorium, planlegger endringer på tvers av flere filer, kjører testsuiten, og itererer uten instruksjon mellom hvert steg. Disse verktøyene er i produksjon, ikke i forskningsforhåndsvisninger.

Det som skiller dem fra tidligere kodegenereringsverktøy er tilbakemeldingssløyfen. En forslagsmotor genererer tekst og stopper; en autonom agent genererer kode, kjører den, leser hva som kommer tilbake, og prøver igjen. Den underliggende stillasen er den samme på tvers av verktøyene: en stor språkmodell leser kontekst – kodebase, oppgavebeskrivelse, feillogg – genererer en plan, utfører den gjennom verktøy som skallkommandoer, filredigeringer og git-operasjoner, leser resultatet, og reviderer. Sløyfen fortsetter inntil agenten lykkes eller bruker opp sitt ressursbudsjett.

Sløyfen som erstattet editoren

Spekteret av autonomi på tvers av tilgjengelige verktøy spenner over tre nivåer. På den assisterte enden foreslår GitHub Copilot de neste linjene mens en utvikler skriver. Ett nivå opp skriver flerfilredigerere som Cursor om på tvers av en kodebase etter en utviklers anvisning, og gjør endringene utvikleren spesifiserer. På den autonome enden opererer Devin og tilsvarende systemer uavhengig over lengre perioder, tar sekvensielle beslutninger om hva som skal leses, endres og testes, og dukker kun opp for godkjenninger systemet ikke kan håndtere alene.

Evalueringsrammeverket som måler fremgang på tvers av disse verktøyene er SWE-bench, skapt av forskere ved Princeton og Stanford. Det tester agenter på reelle feilrapporter fra åpen kildekode Python-repositorier – Django, Flask, scikit-learn – og måler hvor stor andel en agent kan lukke korrekt. Den høyeste publiserte poengsummen på den kuraterte Verified-delmengden, 96 prosent, tilhører Claude Opus 5. Det tallet representerer reell kapasitet: evnen til å diagnostisere en reell programvarefeil, skrive en rettelse, og verifisere at den består prosjektets egne tester.

Hva benchmarken skjuler

96-prosent-scoren kommer med en viktig fotnote. SWE-bench Verified er hentet fra 500 nøye utvalgte oppgaver. Da forskere brukte en kontaminasjonsresistent variant – SWE-bench Pro, designet med problemer som ikke kunne ha dukket opp i noen modells treningsdata – falt en tidligere modell som scoret over 80 prosent på Verified til under 50 prosent på Pro. Noe av benchmark-ytelsen reflekterer kjennskap til evalueringssettet, ikke generalisert problemløsningsevne. Gapet er en kjent forskningsutfordring, ikke en kritikk av noe spesifikt verktøy.

En separat studie fant noe vanskeligere å forklare bort. METR, en AI-sikkerhetsforskningsorganisasjon, gjennomførte en randomisert kontrollert studie med erfarne åpen kildekode-utviklere som jobbet på sine egne repositorier. Utviklere som brukte nåværende AI-kodeverktøy var 19 prosent saktere enn de som jobbet uten – til tross for at de uavhengig anslås at de var 20 prosent raskere. Årsakene var spesifikke: tid brukt på å gi nye instruksjoner når agenten produserte feil resultater, tid brukt på å verifisere utdata før sammenslåing, og den kognitive overbelastningen ved å veksle mellom å styre en agent og å følge hva agenten hadde gjort. En benchmark tester om en agent kan lukke en velspesifisert feil i isolasjon. En randomisert studie tester om en utvikler jobber raskere gjennom en faktisk dag. De måler forskjellige ting.

Hvorfor 93 prosent adopsjon bare ga 10 prosent gjennomstrømningsøkning

Kodeautonomi fungerer best på avgrensede, velspesifiserte oppgaver: en reproduserbar feil med klare innganger og utganger, en funksjon med en presis spesifikasjon, en testsuite for en modul med definert oppførsel. Etter hvert som omfanget utvides til oppgaver som krever implisitt arkitekturkunnskap, udokumenterte teamkonvensjoner eller beslutninger om produktretning, faller påliteligheten – ikke fordi modellene mangler kapasitet, men fordi konteksten disse beslutningene krever ikke får plass i systemet og ikke kan utledes fra kodebasefilene alene.

Det praktiske skiftet ligger i hva arbeidet krever. Utviklere som jobber med autonome agenter bruker mer tid på å skrive spesifikasjoner presise nok til at en agent kan utføre dem: detaljerte oppgavebeskrivelser, klare testkontrakter, eksplisitte akseptkriterier. De bruker mer tid på å gjennomgå kode de ikke har skrevet, noe som krever en annen type oppmerksomhet enn å skrive kode – å lete etter logiske feil, sikkerhetshull og arkitektonisk drift som agenten ikke selv vil flagge. En undersøkelse fra 2026 av 121 000 utviklere fant at 93 prosent bruker AI-kodeverktøy regelmessig; pull request-gjennomstrømningen økte med omtrent 10 prosent i samme gruppe. Flaskehalsen flyttet seg fra å skrive kode til å gjennomgå den.

Det neste stadiet under aktiv utvikling er agenter som administrerer sine egne oppgavekøer: motta en prosjektspesifikasjon, bryte den ned i deloppgaver, delegere mellom spesialiserte modeller, og kun overflatebeslutninger som krever menneskelig dømmekraft. Flere åpen kildekode-rammeverk for fleragent-kodeorkestrering ble lansert i 2026. Bedriftsadopsjon i produksjonsmiljøer er fortsatt begrenset. Gartner anslår at en betydelig andel av agentiske programvareprosjekter som startes i år, vil bli avviklet før 2028, når team oppdager avstanden mellom hva en kontrollert demo viser og hva pålitelig distribusjon i stor skala krever.

Tagger: kunstig intelligens, Programmering, AI coding agents, kodeautonomi, programvareutvikling