När AI skriver och levererar koden arbetar erfarna utvecklare 19% långsammare

Mjukvaruagenter som Devin, Claude Code och GitHub Copilot Workspace tar numera emot en uppgiftsbeskrivning, läser en kodbas, skriver kod som löser uppgiften, kör tester tills de går igenom och öppnar en pull request – utan att en utvecklare skriver en enda rad. Devin, byggd av Cognition AI, gör detta i isolerade molnmiljöer. I sin produktionsanvändarbas blir 67 % av de pull requests som den öppnar autonomt sammanfogade. Claude Code läser ett helt arkiv, planerar ändringar över flera filer, kör testsviten och itererar utan instruktioner mellan varje steg. Dessa verktyg används i produktion, inte i forskningsförhandsvisningar.

Det som skiljer dem från tidigare kodgenereringsverktyg är återkopplingsslingan. En förslagsmotor genererar text och stannar; en autonom agent genererar kod, kör den, läser vad som kommer tillbaka och försöker igen. Den underliggande strukturen är densamma över verktygen: en stor språkmodell läser kontext – kodbas, ärendebeskrivning, fellogg – genererar en plan, utför den genom verktyg som shellkommandon, filredigeringar och git-operationer, läser resultatet och reviderar. Slingan fortsätter tills agenten lyckas eller förbrukar sin resursbudget.

Slingan som ersatte redigeraren

Autonomigraden bland tillgängliga verktyg spänner över tre nivåer. I den assisterade änden föreslår GitHub Copilot de närmaste raderna medan en utvecklare skriver. En nivå upp skriver flerfilredigerare som Cursor om över en kodbas på utvecklarens anvisning och gör de ändringar utvecklaren specificerar. I den autonoma änden arbetar Devin och jämförbara system oberoende under längre perioder, fattar sekventiella beslut om vad som ska läsas, ändras och testas, och dyker bara upp för godkännanden som systemet inte kan hantera på egen hand.

Utvärderingsramverket som mäter framsteg över dessa verktyg är SWE-bench, skapat av forskare vid Princeton och Stanford. Det testar agenter på verkliga buggrapporter från öppen källkods-Python-arkiv – Django, Flask, scikit-learn – och mäter hur stor andel en agent kan stänga korrekt. Det nuvarande högsta publicerade resultatet på den kurerade Verified-delmängden, 96 %, tillhör Claude Opus 5. Den siffran representerar verklig förmåga: att diagnostisera en verklig programvarubugg, skriva en fix och verifiera att den klarar projektets egna tester.

Vad benchmarken döljer

Resultatet på 96 % kommer med en viktig asterisk. SWE-bench Verified hämtar från 500 noggrant utvalda uppgifter. När forskare tillämpade en kontamineringsresistent variant – SWE-bench Pro, utformad med problem som inte kunde ha förekommit i någon modells träningsdata – sjönk en tidigare modell som hade över 80 % på Verified till under 50 % på Pro. En del benchmarkprestanda speglar förtrogenhet med utvärderingssetet, inte generaliserad problemlösningsförmåga. Gapet är en känd forskningsutmaning, inte en kritik av något specifikt verktyg.

En separat studie fann något som är svårare att bortförklara. METR, en AI-säkerhetsforskningsorganisation, genomförde en randomiserad kontrollerad studie med erfarna utvecklare av öppen källkod som arbetade på sina egna arkiv. Utvecklare som använde nuvarande AI-kodningsverktyg var 19 % långsammare än de som arbetade utan dem – trots att de oberoende uppskattade att de var 20 % snabbare. Orsakerna var specifika: tid som lades på att upprepa instruktioner när agenten producerade felaktiga resultat, tid på att verifiera utdata innan sammanfogning, och den kognitiva belastningen av att växla mellan att dirigera en agent och att följa vad agenten hade gjort. En benchmark testar om en agent kan stänga en välspecificerad bugg i isolering. En randomiserad studie testar om en utvecklare arbetar snabbare under en verklig dag. De mäter olika saker.

Varför 93 % användning gav bara 10 % genomströmningsökning

Kodautonomi fungerar bäst på avgränsade, välspecificerade uppgifter: en reproducerbar bugg med tydliga indata och utdata, en funktion med en precis specifikation, en testsvit för en modul med definierat beteende. När omfattningen utökas till uppgifter som kräver implicit arkitekturkunskap, odokumenterade teamkonventioner eller beslut om produktriktning, sjunker tillförlitligheten – inte för att modellerna saknar förmåga utan för att den kontext som dessa beslut kräver inte får plats i systemet och inte kan härledas enbart från kodbasens filer.

Den praktiska förändringen ligger i vad arbetet kräver. Utvecklare som arbetar med autonoma agenter lägger mer tid på att skriva specifikationer som är tillräckligt precisa för att en agent ska kunna utföra dem: detaljerade ärendebeskrivningar, tydliga testkontrakt, explicita acceptanskriterier. De lägger mer tid på att granska kod de inte har skrivit, vilket kräver en annan typ av uppmärksamhet än att skriva kod – att leta efter logiska fel, säkerhetsluckor och arkitektonisk drift som agenten inte själv kommer att flagga. En enkät från 2026 bland 121 000 utvecklare visade att 93 % använder AI-kodningsverktyg regelbundet; pull request-genomströmningen ökade med ungefär 10 % inom samma grupp. Flaskhalsen flyttades från att skriva kod till att granska den.

Nästa steg under aktiv utveckling är agenter som hanterar sina egna uppgiftsköer: tar emot en projektspecifikation, bryter ner den i deluppgifter, delegerar mellan specialiserade modeller och lyfter bara fram de beslut som kräver mänskligt omdöme. Flera ramverk med öppen källkod för multiagent-kodningsorkestrering släpptes under 2026. Företagsanvändning i produktionsmiljöer är fortfarande begränsad. Gartner förutspår att en betydande andel av agentiska mjukvaruprojekt som påbörjas i år kommer att avbrytas före 2028, när team upptäcker avståndet mellan vad en kontrollerad demo visar och vad tillförlitlig drift i skala kräver.

Taggar: artificiell intelligens, Programmering, AI coding agents, kodautonomi, mjukvaruutveckling