Copilot skrev det, men vem äger det? Styrningsgapet som ingenjörsteam kan förbise

En ingenjör öppnar Copilot för att hjälpa till att skriva kod för en kunds webbplats. På några sekunder får de kod som tidigare skulle ha tagit betydligt längre tid att skriva manuellt. För många webbutvecklare och företag som optimerar sina webbplatser är det vanligt att undra: är den koden pålitlig? Är den säker? Bör den granskas innan den implementeras?  Dessa frågor faller alla under en gemensam fråga: Vem kommer att hållas ansvarig för AI‑assisterad kodning? Och, viktigast av allt, vem äger produktivitetsvinsten?

Om AI gör det möjligt för ett ingenjörsteam att slutföra mer arbete på samma tid, kan alla dra nytta av det ekonomiska värdet. Det kan vara att utvecklaren sparar tid, arbetsgivaren får mer värde från sparade timmar, eller att kunden får det de betalat för med timmar över. Oavsett hur den sparade tiden gynnar, är det som återstår i fokus hur arbetet styrs och prissätts.

AI och kodning blir oundvikligt

AI‑kodningsverktyg får snabbt fäste och gör framsteg inom mainstream‑utveckling. Enligt den 2025 Stack Overflow Developer Survey, uppgav 84 % av svararna att de använde eller planerade att använda AI‑verktyg i sin utvecklingsprocess.

Även om införandet av AI i webbutvecklares arbetsflöden blir vanligare finns det fortfarande tvekan kring dess pålitlighet. Samma undersökning visade att 46 % saknade fullt förtroende för AI‑resultatens noggrannhet, och ungefär 66 % pekade på AI‑lösningar som var “nästan rätt, men inte helt” som en källa till frustration.

AI‑kodningsdebatten som tar form handlar mer om dess pålitlighet än om huruvida koden skapar mer värde och vem som är ansvarig för att säkerställa det.

AI bryter förhållandet mellan timmar och leverans

Ersättning för mjukvaruutveckling har alltid grundat på antagandet att ingenjörsresultat är nära kopplat till ingenjörsinsats. Generativ AI komplicerar nu den ekvationen.

Ett kontrollerat experiment med 95 utvecklare fann att deltagare med tillgång till GitHub Copilot slutförde en specifik JavaScript‑HTTP‑serveruppgift 55.8% snabbare än de utan tillgång.

Detta visar att AI kan påskynda utveckling, potentiellt utan att offra kvalitet. Men dessa siffror är bara giltiga eftersom experimentet följde en mycket specifik programmeringsuppgift. Även om uppgiften slutfördes snabbare betyder det inte att Copilot gör en hel ingenjörsorganisation 55.8% mer produktiv.

En annan forskningsstudie exemplifierar detta. En studie med 96 heltidsanställda Google‑programvaruingenjörer fann att utvecklare som använde AI slutförde en företagsklassad uppgift på ungefär 96 minutes, jämfört med 114 minutes för dem utan. Forskarens justerade uppskattning indikerade ungefär en 21% reduction in completion time. Studien undersökte dock inte kvaliteten på AI‑koden, och tog inte upp frågor om rättvisa i förhållande till beroendet av tekniken.

Det finns också bevis på att AI kan bromsa kodningstiden. En randomiserad studie av METR involverade 16 erfarna open‑source‑utvecklare som arbetade med 246 verkliga problem i repositorier de kände väl till. Med verktyg som fanns i början av 2025, inklusive Claude Sonnet 3.5 och 3.7 samt Cursor Pro, tog de ungefär 19% längre tid att slutföra sina uppgifter, trots att många antog att dessa verktyg skulle spara tid.

Tillsammans undergräver dessa studier förväntningarna att AI gör utvecklare snabbare. Istället gör det utvecklartiden och värdet mindre förutsägbart för företag som levererar webbarbete och för de kunder som får det.

Prissättningsproblemet som ingen talar om

Tid & material (T&M) är en vanlig modell inom webbutveckling för inköp av mjukvara, eftersom den hanterar ett återkommande branschproblem: ett utvecklande projekt.

Med denna modell, istället för att kräva att varje funktion eller uppgift definieras innan utvecklingen påbörjas, kan kunder betala för ingenjörstid i takt med att projektet utvecklas och förändras.

Dock skapar AI störningar i den beprövade modellen. När ersättningen är direkt kopplad till ingenjörstimmar kan en mer effektiv utveckling leda till färre fakturerbara timmar för kunderna. Om AI levererar samma resultat på kortare tid kan tekniken skapa värde för kunderna, men minskningen av fakturerbara timmar innebär mindre intäkter för leverantörerna.

Lösningen är inte att uppmuntra utvecklare att arbeta långsammare. T&M‑modellen står nu inför ett strukturellt problem med hur prissättning och incitament utformas. Att använda timpriser för att bestämma värde kan vara begränsande. En köpare kan veta exakt vad varje ingenjörstimme kostar men ändå vara osäker på den totala investering som krävs för att uppnå önskat resultat.

När AI förändrar ingenjörsproduktiviteten kan frågan skifta från:

“Vad kostar en utvecklartimme?” → “Vad händer med värdet när färre utvecklartimmar krävs?”

METR‑resultaten komplicerar denna fråga. Om utvecklare tror att de kan spara tid när de i verkligheten tar längre tid, är varken AI‑adoption eller upplevd produktivitet tillräcklig för att visa finansiellt värde. Därför behöver organisationer styrning som kan mäta vad som faktiskt hände.

Styrningsgapet har fyra ägare

Att diskutera styrning kring AI‑assisterad utveckling måste gå bortom policyer som reglerar vilka verktyg utvecklare får använda.

Det finns minst fyra typer av ägandeskap som ingenjörsorganisationer bör definiera.

1. Vem äger koden?

AI kan generera en implementation, men det kan inte bli ett ursäkt för ansvarsfri utveckling. Någon måste fortfarande vara ansvarig för att granska, testa och godkänna koden tills den når produktionsstadiet.

2. Vem äger risken?

Snabbare kod är bara värdefull om den inte orsakar problem någon annanstans. En empirisk studie av AI‑genererad kod identifierade säkerhetsbrister i 29.5% av de granskade Python‑snuttarna och 24.2% av JavaScript‑snuttarna. Forskningen identifierade också svagheter som spände över 43 kategorier i Common Weakness Enumeration.

Studien fann dock att återkoppling av statisk‑analysvarningar till Copilot Chat kunde åtgärda upp till 55.5% av de identifierade säkerhetsproblemen. Forskningen visar hur AI kan skapa och lösa kodningsproblem, men organisationer behöver processer för att avgöra hur deras resultat ska valideras.

NIST:s SP 800-218A återspeglar denna princip genom att utöka sitt Secure Software Development Framework med bästa praxis som hanterar generativ AI och dual‑use‑grundmodeller.

3. Vem äger produktivitetsvinsten?

Kommersiella avtal från början är avgörande för att bestämma vem som ska få effektivitetsvinsterna. AI kan hjälpa kunder att spendera mindre, möjliggöra att team levererar mer mjukvara, eller inte ge någon finansiell fördel vid projektets slut.

Det som förblir detsamma är behovet av transparenta processer och leverans av kvalitet, överenskommen arbetsinsats.

4. Vem äger prioriteringen?

AI kan göra generering av funktioner billigare och snabbare, men det kan inte avgöra om dessa funktioner är nödvändiga.

Faktum är att ökad utvecklingskapacitet kan göra prioritering ännu viktigare. När team kan bygga och experimentera snabbare, måste någon fortfarande avgöra vilka resultat som motiverar den tillgängliga budgeten och vilka idéer som bör överges.

AI‑styrning blir en finansiell fråga

Dessa frågor gör AI‑styrning allt mer relevant. Föreställ dig två utvecklingspartner som tar liknande timpriser.

Den ena har integrerat AI i en stark ingenjörsprocess och uppnår det erforderliga resultatet avsevärt snabbare, medan den andra tar längre tid. Att bara jämföra deras timpriser ger köparen lite information om de processer de kommer att utföra.

Köpare kommer behöva utvärdera:

• Totala förväntade investering
• Ansvar för överskridanden
• Kvalitetskontroller kring AI‑genererat arbete
• Hur effektivitetsvinster delas

T&M kan förbli användbart för båda parter om de medvetet accepterar osäkerhet i tjänsterna. Fastprisavtal kan också fungera när krav och leveranser är stabila.

Men AI gör också alternativa strukturer värda att undersöka. Ett tillvägagångssätt är att fastställa en maximal finansiell gräns samtidigt som omfattningen hålls flexibel. Därefter kan funktioner prioriteras efter affärsvärde inom den modellen.

Om ingenjörsarbete blir mer effektivt kan vinsterna omvandlas till ytterligare produktkapacitet snarare än ytterligare fakturerbar tid. Kommersiella incitament bör uppmuntra samma resultat som ingenjörsincitament, och skapa mer användbar mjukvara så effektivt som möjligt.

Samma AI‑konversation

Ingenjörsledare måste förstå hur kommersiella incitament påverkar leveransen. Finans- och inköpsteam behöver tillräcklig insyn i AI‑assisterad ingenjörskonst för att bedöma om påstådd effektivitet levererar mätbart värde.

Det innebär att mogen AI‑styrning inte kan stanna vid godkända modellistor, säkerhetskontroller, datapolicyer eller kodgranskningskrav. Den måste ta itu med ansvar, finansiell risk, prioritering och ägandeskap av produktivitetsvinster.

Men det finns en andra ägandefråga som kan ha en mycket större inverkan på teknikbudgetar: Vem äger det värde som skapas eller förloras när AI förändrar hur snabbt mjukvara byggs?

De organisationer som avgör om snabbare ingenjörsarbete faktiskt producerar bättre produkter, styr investeringar och uppnår mätbara affärsresultat kommer att vara de som kan ligga steget före konkurrenterna.

Om ditt utvecklingsteam skulle anta AI imorgon, skulle din nuvarande styrnings- och affärsmodell ens kunna säga om leveransen blivit mer värdefull?