Copilot skrev det, men hvem ejer det? Governance‑gabet som ingeniørteams kan overse

En ingeniør åbner Copilot for at hjælpe med at udforme kode til en kundes hjemmeside. Inden for få sekunder modtager de kode, som tidligere ville have taget betydeligt længere tid at skrive manuelt. For mange webudviklere og virksomheder, der optimerer deres hjemmesider, er det normalt at undre sig: Er den kode pålidelig? Er den sikker? Skal den gennemgås, før den implementeres? Disse spørgsmål falder alle ind under én overordnet forespørgsel: Hvem vil blive holdt ansvarlig for AI‑assisteret kodning? Og, vigtigst af alt, hvem ejer produktivitetsgevinsten?

Hvis AI gør det muligt for et ingeniørteam at udføre mere arbejde på samme tid, kan alle drage større fordel af den økonomiske værdi. Det kan være, at udvikleren sparer tid, arbejdsgiveren får mere værdi ud af de sparede timer, eller at kunden får det, de har betalt for, med ekstra timer til overs. Uanset hvordan den sparede tid gavner, er det, der forbliver i fokus, hvordan arbejdet styres og prissættes.

AI og kodning bliver uundgåelig

AI‑kodningsværktøjer får hurtigt indpas og gør fremskridt i mainstream‑udvikling. Ifølge 2025 Stack Overflow Developer Survey brugte 84 % af respondenterne allerede AI‑værktøjer eller planlagde at bruge dem i deres udviklingsproces.

Selvom implementering af AI i webudvikleres arbejdsprocesser bliver mere almindeligt, er der stadig tøven omkring pålideligheden. Den samme undersøgelse viste, at 46 % ikke havde fuld tillid til AI‑outputtet, og omkring 66 % pegede på AI‑løsninger, der var “næsten rigtige, men ikke helt”, som en kilde til frustration.

AI‑kodningsdebatten, der tager form, handler mere om pålideligheden end om, hvorvidt koden skaber mere værdi, og hvem der er ansvarlig for at sikre, at den gør.

AI bryder forholdet mellem timer og output

Løn for softwareudvikling har altid hvilet på antagelsen om, at ingeniørouput er tæt forbundet med ingeniørinvesteringen. Generativ AI komplicerer nu denne ligning.

Et kontrolleret eksperiment med 95 udviklere viste, at deltagerne med adgang til GitHub Copilot gennemførte en specifik JavaScript HTTP‑serveropgave 55,8 % hurtigere end dem uden adgang.

Dette viser, at AI kan accelerere udviklingen uden nødvendigvis at gå på kompromis med kvaliteten. Men disse tal er kun succesfulde, fordi eksperimentet fulgte en meget specifik programmeringsopgave. Selvom opgaven blev afsluttet hurtigere, betyder det ikke, at Copilot gør en hel ingeniørorganisation 55,8 % mere produktiv.

En anden forskningsundersøgelse illustrerer denne idé. En test med 96 fuldtidssoftwareingeniører fra Google viste, at udviklere, der brugte AI, gennemførte en enterprise‑opgave på omkring 96 minutter, sammenlignet med 114 minutter for dem uden. Forskerne anslog en cirka 21 % reduktion i gennemføringstid. Undersøgelsen undersøgte dog ikke kvaliteten af AI‑koden, og den behandlede ikke spørgsmål om lighed i forhold til afhængigheden af teknologien.

Der er også beviser for, at AI kan bremse kodningstiden. En randomiseret undersøgelse fra METR involverede 16 erfarne open‑source‑udviklere, som arbejdede på 246 reelle problemer i repositorier, de kendte godt. Ved brug af værktøjer, der var tilgængelige i begyndelsen af 2025, herunder Claude Sonnet 3.5 og 3.7 samt Cursor Pro, tog de cirka 19 % længere tid om at fuldføre deres opgaver, selvom mange antog, at disse værktøjer ville spare tid.

Sammen underminerer disse undersøgelser forventningen om, at AI gør udviklere i stand til at arbejde hurtigere. I stedet gør det udviklerens tid og værdi mindre forudsigelig for virksomheder, der leverer webarbejde, og for de kunder, der modtager det.

Prisproblemet, som ingen taler om

Time & Material (T&M) er en almindelig model i webudvikling til køb af software, da den adresserer et tilbagevendende brancheproblem: et udviklende projekt.

Med denne model, i stedet for at kræve, at hver funktion eller opgave defineres inden udviklingen påbegyndes, kan kunder betale for ingeniørtid, efterhånden som projektet skrider frem og ændrer sig.

Dog skaber AI komplikationer i denne gennemprøvede model. Når kompensationen er direkte knyttet til ingeniørtimer, kan mere effektiv udvikling resultere i færre fakturerbare timer for kunderne. Hvis AI leverer de samme resultater på kortere tid, kan teknologien skabe værdi for kunderne, men reduktionen i fakturerbare timer betyder mindre indtægt for leverandørerne.

Løsningen er ikke at opfordre udviklere til at arbejde langsommere. T&M-modellen står nu over for et strukturelt problem med, hvordan priser og incitamenter udformes. At bruge timepriser til at fastlægge værdi kan være begrænsende. En køber kan kende den præcise pris på hver ingeniørtime, men stadig være usikker på den samlede investering, der kræves for at opnå det ønskede resultat.

Efterhånden som AI ændrer ingeniørproduktiviteten, kan spørgsmålet skifte fra:

Hvad koster en udvikler‑time? → Hvad sker der med værdien, når færre udvikler‑timer er påkrævet?

METR‑resultaterne komplicerer dette spørgsmål. Hvis udviklere tror, de kan spare tid, mens de i virkeligheden bruger længere tid, er hverken AI‑adoption eller opfattet produktivitet tilstrækkelig til at demonstrere økonomisk værdi. Derfor har organisationer brug for governance, der kan måle, hvad der faktisk er sket.

Governance‑gabet har fire ejere

Diskussion af governance omkring AI‑assisteret udvikling skal gå ud over politikker, der regulerer, hvilke værktøjer udviklere kan bruge.

Der er mindst fire typer af ejerskab, som ingeniørorganisationer bør definere.

1. Hvem ejer koden?

AI kan generere en implementering, men det kan ikke blive en undskyldning for ansvarsfri udvikling. Der skal stadig være nogen, der er ansvarlig for at gennemgå, teste og godkende koden, indtil den når produktionsstadiet.

2. Hvem ejer risikoen?

Hurtigere kode er kun værdifuld, hvis den ikke forårsager problemer andre steder. En empirisk undersøgelse af AI‑genereret kode identificerede sikkerhedssvagheder i 29,5 % af de undersøgte Python‑uddrag og 24,2 % af JavaScript‑uddragene. Forskningen identificerede også svagheder på tværs af 43 kategorier i Common Weakness Enumeration.

Undersøgelsen fandt dog, at indføring af statisk‑analyseadvarsler i Copilot Chat kunne løse op til 55,5 % af de identificerede sikkerhedsproblemer. Forskningen viser, hvordan AI kan skabe og løse kodningsproblemer, men organisationer har brug for processer til at bestemme, hvordan man validerer outputtet.

NIST’s SP 800-218A afspejler dette princip ved at udvide deres Secure Software Development Framework med bedste praksis, der adresserer generativ AI og dual‑use foundation‑modeller.

3. Hvem ejer produktivitetsgevinsten?

Kommercielle aftaler fra starten er afgørende for at fastlægge, hvem der skal modtage effektivitetgevinsterne. AI kan hjælpe kunder med at bruge mindre, gøre teams i stand til at levere mere software eller ikke give nogen økonomisk fordel ved projektets afslutning.

Det, der forbliver det samme, er behovet for gennemsigtige processer og levering af kvalitet, som er aftalt arbejde.

4. Hvem ejer prioriteringen?

AI kan gøre generering af funktioner billigere og hurtigere, men den kan ikke beslutte, om de funktioner er nødvendige.

Faktisk kan øget udviklingskapacitet gøre prioritering endnu vigtigere. Når teams kan bygge og eksperimentere hurtigere, skal nogen stadig afgøre, hvilke resultater der retfærdiggør det tilgængelige budget, og hvilke idéer der bør opgives.

AI‑governance bliver et finansielt spørgsmål

Disse spørgsmål gør AI‑governance stadig mere relevant. Forestil dig to udviklingspartnere, der opkræver lignende timepriser.

Den ene har integreret AI i en stærk ingeniørproces og opnår det nødvendige resultat betydeligt hurtigere, mens den anden tager længere tid. At sammenligne deres timepriser alene giver køberen kun begrænset information om de processer, de vil udføre.

Købere vil skulle evaluere:

• Den samlede forventede investering
• Ansvar for overskridelser
• Kvalitetskontrol af AI‑genereret arbejde
• Hvordan effektivitetgevinster deles

T&M kan forblive nyttig for begge parter, hvis de bevidst accepterer usikkerhed i tjenesterne. Fast‑prisaftaler kan også fungere, når krav og leverancer er stabile.

Men AI gør også alternative strukturer værd at undersøge. En tilgang er at fastsætte en maksimal økonomisk grænse, mens omfanget holdes fleksibelt. Derefter kan funktioner prioriteres efter forretningsværdi inden for den model.

Hvis ingeniørarbejdet bliver mere effektivt, kan gevinsterne omsættes til ekstra produktkapacitet i stedet for ekstra fakturerbare timer. Kommercielle incitamenter bør fremme det samme resultat som ingeniørincitamenter og skabe mere brugbar software så effektivt som muligt.

Den samme AI-samtale

Ingeniørledere skal forstå, hvordan kommercielle incitamenter påvirker leverancen. Finans- og indkøbsteams har brug for tilstrækkelig indsigt i AI‑assisteret ingeniørarbejde for at vurdere, om den påståede effektivitet leverer målbar værdi.

Det betyder, at moden AI‑governance ikke kan stoppe ved godkendte modellister, sikkerhedskontroller, datapolitikker eller krav til kodegennemgang. Den skal adressere ansvarlighed, finansiel risiko, prioritering og ejerskab af produktivitetsgevinster.

Men der er et andet ejerskabsspørgsmål, som kan have en langt større indvirkning på teknologibudgetterne: Hvem ejer den værdi, der skabes eller tabes, når AI ændrer, hvor hurtigt software bygges?

De organisationer, der fastlægger, om hurtigere ingeniørarbejde faktisk producerer bedre produkter, styrer investeringerne og opnår målbare forretningsresultater, vil være dem, der kan holde sig foran konkurrenterne.

Hvis dit udviklingsteam adopterede AI i morgen, ville din nuværende governance‑ og kommercielle model så overhovedet kunne fortælle dig, om leverancen blev mere værdifuld?