Copilot skrev det, men hvem eier det? Styringsgapet ingeniørteam kan overse

En ingeniør åpner Copilot for å hjelpe med å skrive kode for en kundes nettsted. Innen sekunder får de kode som tidligere ville ha tatt betydelig lengre tid å skrive manuelt. For mange webutviklere og bedrifter som optimaliserer sine nettsteder er det vanlig å lure: Er den koden pålitelig? Er den sikker? Bør den gjennomgås før implementering?  Disse spørsmålene faller alle inn under én overordnet problemstilling: Hvem skal holdes ansvarlig for AI‑assistert koding? Og, viktigst av alt, hvem eier produktivitetsgevinsten?

Hvis AI gjør det mulig for et ingeniørteam å fullføre mer arbeid på samme tid, kan alle dra nytte av den økonomiske verdien. Dette kan være utvikleren som sparer tid, arbeidsgiveren som får mer verdi fra sparede timer, eller kunden som får det de betalte for med ekstra tid til overs. Uansett hvordan den sparte tiden gagner, er det som er i fokus hvordan arbeidet styres og prises.

AI og koding blir uunngåelig

AI‑kodingsverktøy får raskt fotfeste og gjør seg bemerket i mainstream‑utvikling. Ifølge 2025 Stack Overflow Developer Survey, 84 % av respondentene brukte eller planla å bruke AI‑verktøy i utviklingsprosessen.

Selv om implementering av AI i webutvikleres arbeidsflyt blir mer vanlig, er det fortsatt usikkerhet rundt påliteligheten. Den samme undersøkelsen viste at 46 % ikke hadde full tillit til nøyaktigheten av AI‑resultatene, og omtrent 66 % nevnte AI‑løsninger som var «nesten riktige, men ikke helt» som en kilde til frustrasjon.

Debatten om AI‑koding som tar form handler mer om påliteligheten enn om hvorvidt koden skaper mer verdi og hvem som er ansvarlig for å sikre at den gjør det.

AI bryter forholdet mellom timer og leveranse

Kompensasjon for programvareutvikling har alltid vært basert på antakelsen om at ingeniørresultater var tett knyttet til innsatsen. Generativ AI kompliserer nå denne ligningen.

Et kontrollert eksperiment med 95 utviklere fant at deltakere med tilgang til GitHub Copilot fullførte en spesifikk JavaScript‑HTTP‑server‑oppgave 55.8% raskere enn de uten tilgang.

Dette viser at AI kan akselerere utvikling, potensielt uten å gå på bekostning av kvaliteten. Men tallene er kun relevante fordi eksperimentet fulgte en svært spesifikk programmeringsoppgave. Selv om oppgaven ble fullført raskere, betyr det ikke at Copilot gjør en hel ingeniørorganisasjon 55,8 % mer produktiv.

En annen forskningsstudie illustrerer dette. En studie med 96 heltids Google‑programvareingeniører viste at utviklere som brukte AI fullførte en oppgave på bedriftsnivå på omtrent 96 minutter, sammenlignet med 114 minutter for de uten AI. Forskerne anslo at dette tilsvarer omtrent en 21 % reduksjon i gjennomføringstid. Studien undersøkte imidlertid ikke kvaliteten på AI‑koden, og tok ikke opp spørsmål om likhet knyttet til avhengigheten av teknologien.

Det finnes også bevis på at AI kan bremse kodetiden. En randomisert studie fra METR involverte 16 erfarne åpen‑kilde‑utviklere som arbeidet med 246 reelle problemer i repositorier de kjente godt. Ved å bruke verktøy som var tilgjengelige tidlig i 2025, inkludert Claude Sonnet 3.5 og 3.7, samt Cursor Pro, brukte de omtrent 19 % lengre tid på å fullføre oppgavene sine, selv om mange antok at disse verktøyene ville spare tid.

Sammen undergraver disse studiene forventningene om at AI gjør utviklere raskere. I stedet gjør den utviklerens tid og verdi mindre forutsigbare for virksomheter som leverer webarbeid og for kundene som mottar det.

Prisproblemet ingen snakker om

Tid‑og‑materiale (T&M) er en vanlig modell i webutvikling for kjøp av programvare, da den adresserer et tilbakevendende bransjeproblem: et utviklende prosjekt.

Med denne modellen, i stedet for å kreve at hver funksjon eller oppgave defineres før utviklingen starter, kan kundene betale for ingeniørtid etter hvert som prosjektet utvikler seg og endres.

Imidlertid skaper AI hindringer i denne velprøvde modellen. Når kompensasjon er direkte knyttet til ingeniørtimer, kan mer effektiv utvikling føre til færre fakturerbare timer for kundene. Hvis AI leverer samme resultat på kortere tid, kan teknologien skape verdi for kundene, men reduksjonen i fakturerbare timer betyr mindre inntekt for leverandørene.

Løsningen er ikke å oppmuntre utviklere til å jobbe saktere. T&M‑modellen står nå overfor et strukturelt problem i hvordan prisfastsettelse og insentiver er utformet. Å bruke timelønn for å bestemme verdi kan være begrensende. En kjøper kan vite nøyaktig hva hver ingeniørtime koster, men fortsatt være usikker på den totale investeringen som kreves for å oppnå ønsket resultat.

Etter hvert som AI endrer ingeniørproduktiviteten, kan spørsmålet skifte fra:

«Hva koster en utviklertime?» → «Hva skjer med verdien når færre utviklertimer kreves?»

METR‑funnene kompliserer dette spørsmålet. Hvis utviklere tror de kan spare tid når de i realiteten bruker lengre tid, er verken AI‑adopsjon eller oppfattet produktivitet tilstrekkelig for å demonstrere økonomisk verdi. Derfor trenger organisasjoner styring som kan måle hva som faktisk skjedde.

Styringsgapet har fire eiere

Diskusjon om styring rundt AI‑assistert utvikling må gå utover retningslinjer som regulerer hvilke verktøy utviklere kan bruke.

Det finnes minst fire typer eierskap som ingeniørorganisasjoner bør definere.

1. Hvem eier koden?

AI kan generere en implementering, men det kan ikke bli en unnskyldning for utvikling uten ansvar. Noen må fortsatt være ansvarlig for å gjennomgå, teste og godkjenne koden frem til den når produksjonsstadiet.

2. Hvem eier risikoen?

Raskere kode er kun verdifull hvis den ikke skaper problemer andre steder. En empirisk studie av AI‑generert kode identifiserte sikkerhets svakheter i 29,5 % av de undersøkte Python‑utdragene og 24,2 % av JavaScript‑utdragene. Forskningen identifiserte også svakheter som dekket 43 kategorier i Common Weakness Enumeration.

Studien fant imidlertid at å mate statisk analyse‑advarsler tilbake til Copilot Chat kunne løse opptil 55,5 % av de identifiserte sikkerhetsproblemene. Forskningen viser hvordan AI kan skape og løse kodeproblemer, men organisasjoner trenger prosesser for å bestemme hvordan de skal validere resultatet.

NISTs SP 800‑218A reflekterer dette prinsippet ved å utvide sitt Secure Software Development Framework med beste praksiser som tar for seg generativ AI og dual‑use‑grunnmodeller.

3. Hvem eier produktivitetsgevinsten?

Kommercielle avtaler fra starten av er avgjørende for å fastslå hvem som skal motta effektivitetsgevinsten. AI kan hjelpe kunder med å bruke mindre, gjøre team i stand til å levere mer programvare, eller ikke gi noen økonomisk fordel ved prosjektets slutt.

Det som forblir det samme er behovet for transparente prosesser og leveranse av kvalitet, avtalt arbeid.

4. Hvem eier prioriteringen?

AI kan gjøre generering av funksjoner billigere og raskere, men den kan ikke bestemme om disse funksjonene er nødvendige.

Faktisk kan økt utviklingskapasitet gjøre prioritering enda viktigere. Når team kan bygge og eksperimentere raskere, må noen fortsatt avgjøre hvilke resultater som rettferdiggjør det tilgjengelige budsjettet, og hvilke ideer som bør forkastes.

AI‑styring blir et finansspørsmål

Disse spørsmålene gjør AI‑styring stadig mer relevant. Tenk deg to utviklingspartnere som tar lignende timelønner.

Den ene har integrert AI i en solid ingeniørprosess og oppnår det nødvendige resultatet betydelig raskere, mens den andre bruker lengre tid. Å sammenligne kun timelønnen gir kjøperen lite informasjon om prosessene de vil utføre.

Kjøpere vil måtte vurdere:

• Total forventet investering
• Ansvar for overskridelser
• Kvalitetskontroller rundt AI‑generert arbeid
• Hvordan effektivitetsgevinster deles

T&M kan fortsatt være nyttig for begge parter dersom de bevisst aksepterer usikkerhet i tjenestene. Fastprismodeller kan også fungere når krav og leveranser er stabile.

Men AI gjør også alternative strukturer verdt å undersøke. En tilnærming er å etablere en maksimal økonomisk grense samtidig som omfanget holdes fleksibelt. Deretter kan funksjoner prioriteres etter forretningsverdi innen den modellen.

Hvis ingeniørarbeidet blir mer effektivt, kan gevinster omsettes til ekstra produktkapasitet i stedet for ekstra fakturerbare timer. Kommersielle insentiver bør oppmuntre til samme resultat som ingeniøri​nsentiver, og skape mer nyttig programvare så effektivt som mulig.

Den samme AI‑samtalen

Ingeniørledere må forstå hvordan kommersielle insentiver påvirker leveransen. Finans‑ og innkjøpsteam trenger tilstrekkelig innsikt i AI‑assistert ingeniørarbeid for å vurdere om påstått effektivitet leverer målbar verdi.

Det betyr at moden AI‑styring ikke kan stoppe ved godkjente modellister, sikkerhetskontroller, datapolitikker eller krav til kodegjennomgang. Den må ta tak i ansvarlighet, økonomisk risiko, prioritering og eierskap til produktivitetsgevinster.

Men det finnes et annet eierskapsspørsmål som kan ha langt større innvirkning på teknologibudsjetter: Hvem eier verdien som skapes eller går tapt når AI endrer hvor raskt programvare bygges?

Organisasjonene som fastslår om raskere ingeniørarbeid faktisk produserer bedre produkter, styrer investeringer og oppnår målbare forretningsresultater, vil være de som kan holde seg foran konkurrentene.

Hvis utviklingsteamet ditt adopterte AI i morgen, ville ditt nåværende styrings- og forretningsmodell i det hele tatt kunne fortelle deg om leveransen ble mer verdifull?