300 millioner arbeidshendelser viser: AI-agentene skriver mer kode, ikke mer programvare

Ny forskning bygget på data fra over 700 000 ansatte i mer enn 700 programvarefirmaer finner 30 prosent flere kodelinjer etter innføring av AI-agenter – men ingen statistisk signifikant økning i antall løste programvarefunksjoner.

Illustrasjon: Sort tråd spoles maskinelt ut i lange baner over et lyst bord, med mange løse ender som henger uferdige over kanten – bare én ende er ferdig knyttet med en rød knute.
Illustrasjon

300 millioner arbeidshendelser viser: AI-agentene skriver mer kode, ikke mer programvare

Ny forskning bygget på data fra over 700 000 ansatte i mer enn 700 programvarefirmaer finner 30 prosent flere kodelinjer etter innføring av AI-agenter – men ingen statistisk signifikant økning i antall løste programvarefunksjoner.

Når firmaer innfører AI-kodingsagenter, skriver de ansatte målbart mer kode – 30 prosent flere kodelinjer, 20 prosent flere commits og 23 prosent flere pull requests i gjennomsnitt. Likevel løses det ikke flere av oppgavene som faktisk teller: Løsningsraten for Issues og Epics sporet i verktøy som Jira endrer seg ikke statistisk signifikant etter at AI-verktøyene ble innført.

Det er kjernefunnet i ny forskning fra Harvard University, presentert av forskerne Fiona Chen og James Stratton og rapportert av Ars Technica i oktober 2026. Studien er blant de første som måler effekten av AI-agenter på faktisk programvarelevering på bedriftsnivå, ikke bare på kodevolum – og den peker mot en ubehagelig mulighet: at gevinstene fra automatisert kodegenerering spises opp et annet sted i utviklingsprosessen.

Hva studien bygger på

Chen og Stratton brukte aggregerte analysedata fra Jellyfish, et selskap som måler den detaljerte produksjonen til ingeniørteamer. Datagrunnlaget omfatter 300 millioner individuelle «work events» – for eksempel commits og pull requests – og data fra issue-håndteringsprogramvare, fordelt på over 700 000 ansatte ved over 700 relevante programvarefirmaer, fra 2021 til og med mars 2026.

Det som gjør datasettet interessant, er at det kobler to kilder som sjelden ses sammen: detaljert aktivitet i versjonskontroll og utviklingsverktøy på den ene siden, og sporing av arbeidsoppgaver i systemer som Jira på den andre. Det gir mulighet til å stille et spørsmål de fleste tidligere målinger har skipt ut: Blir det faktisk levert mer programvare når det skrives mer kode?

Svaret i dette materialet er altså nei – i hvert fall ikke når programvare måles som løste Issues og Epics, altså helhetlige programvarefunksjoner. Forskerne fant heller ingen «compositional shift»: Oppgavenes størrelse eller kompleksitet endret seg ikke på tvers av AI-innføringen. Det betyr at mønsteret ikke enkelt kan forklares med at teamene bare tar seg større biter om gangen, eller at de løser mange flere små oppgaver og færre store.

Hvordan tallene er beregnet

En åpenbar innvending mot denne typen studier er utvalgsskjevhet: Firmaer som tar i bruk AI-agenter kan være av en annen type enn de som ikke gjør det, eller de kan være i en spesiell vekstfase. Chen og Stratton møter dette med en difference-in-differences-tilnærming, ifølge Ars Technicas gjennomgang av metodikken.

Forskerne identifiserte først tidspunktet da de ulike organisasjonene innførte AI-assistenter kontra AI-agenter. Det gjorde de ikke ved hjelp av firmaenes egne uttalelser, men gjennom direkte måling av AI-bruk og analyse av GitHub-aktivitet. Deretter utførte de regresjonsanalyser av sentrale variabler før og etter innføringen, på ulike tidspunkter i ulike organisasjoner – og sammenlignet endringen i firmaer som innførte verktøyene med de som ikke hadde gjort det ennå.

Metoden fjerner ikke alle usikkerheter, men den er en standard måte å trekke kausale slutninger fra observasjonsdata på, og den er langt mer robust enn enkle sammenligninger av produksjon før og etter.

Hvorfor mer kode ikke blir mer programvare

Studien dokumenterer et gap: opp i volumet av kodeproduksjon, flatt i levert funksjonalitet. Hvorfor gapet oppstår, er et tolkningsspørsmål.

Det japanske AI Times-nyhetsbrevet (10. oktober 2026, skrevet av 江守義樹 i ALL WEB CONSULTING) tilbyr en tolkning av funnet: Gevinstene absorberes av menneskelig gjennomgangskapasitet. Hvis kodegenerering blir billigere og raskere, men hver pull request fortsatt må gjennom menneskelig review, er det gjennomgangen – ikke generasjonen – som setter taket på hvor mye som faktisk blir ferdigstilt. «Selv om kostnadene går ned [i de tidligere leddene], vil gjennomstrømningen ikke øke med mindre også gjennomgangskapasiteten øker», skriver AI Times i sin analyse av den Ars Technica-rapporterte forskningen.

Det er verdt å understreke avgrensningen: «Gjennomgang som flaskehals» er kommentatorens tolkning, ikke en konklusjon Chen og Stratton selv trekker i det tilgjengelige kildematerialet. Ars Technicas tekst bemerker at betydelig review-innsats er nødvendig, men den spesifikke mekanismen – at gevinstene «absorberes» – kommer fra AI Times. Studien fastslår at gapet eksisterer; mekanismen bak er foreløpig åpen.

Likevel er tolkningen plausibel nok til at den har praktiske konsekvenser hvis den stemmer. Da følger det at firmaer som måler effektiviteten av AI-adopsjon gjennom generasjonsvolum eller API-kostnader, måler feil ting. AI Times foreslår i stedet måleparametere som review wait time (ventetid før en pull request blir gjennomgått) og lead time to merge (tiden fra kodeinnsending til den er merget inn). Det er parametere som fanger opp hvor i prosessen arbeidet faktisk stanser – og som ville avslørt en gjennomgangsflaskehals direkte, i stedet for å antyde den indirekte via manglende funksjonsleveranse.

Hva en bedrift kan ta med seg

For organisasjoner som allerede har tatt i bruk AI-agenter, eller vurderer det, peker studien på tre konkrete ting:

For det første: Kodevolum er en svak indikator på verdi. En 30 prosent økning i kodelinjer uten tilsvarende økning i løste Epics betyr at volummålinger kan gi en falsk følelse av fremgang – eller, verre, brukes som begrunnelse for investeringer som ikke lønner seg.

For det andre: Hvis gjennomgang virkelig er der gevinsten forsvinner, er gjennomgangskapasitet en investeringsbeslutning på linje med selve AI-lisensene. Flere eller raskere review-runder, bedre automatisert testing og klarere merge-kriterier kan være forutsetningen for at agentgevinsten materialiserer seg i levert programvare.

For det tredje: Dataene dekker perioden frem til mars 2026, altså en tidlig fase av agentadopsjon. Hvordan verktøyene og arbeidsprosessene utvikler seg videre – for eksempel om AI får en større rolle også i review – kan endre bildet betydelig.

Åpne spørsmål

Det er verdt å lese studiens tall med en viss akademisk ydmykhet. Det underliggende papiret av Chen og Stratton er ikke tilgjengelig i dette kildematerialet, og om det er fagfellevurdert eller hvor det eventuelt er publisert, er ukjent. Alle tall kommer via Ars Technicas rapportering av forskningen, og AI Times oppgir selv at dets egne tall er uverifiserte kildeopplysninger – nyhetsbrevet kunne ikke få tilgang til primærkildene direkte.

Det gjenstår også spørsmål studien ikke svarer på: Hvor mye av den ekstra koden er brukbar? Blir den liggende som uløste pull requests, eller blir den merget inn som kode som ikke flytter noen Jira-oppgave? Og hvordan ser det ut over tid – gjenoppretter gjennomgangskapasiteten seg når organisasjonene tilpasser seg, eller er gapet strukturelt?

Men som en av de første storskala-målingene på bedriftsnivå av AI-agentenes effekt på faktisk programvarelevering er hovedbudskapet likevel tydelig – med den avgrensning at tolkningen av mekanismen ikke er forskernes egen: Hvis genereringen av kode ikke lenger er flaskehalsen, må firmaene finne ut av hva som er det – gjennomgang, kravklarhet eller noe helt annet – og måle seg frem til svaret.

Få de viktigste AI-nyhetene i innboksen

Nyheter, analyser og verktøy samlet for deg.