97 % av utviklerteam bruker KI-kodingsassistenter – kun 30 % har styring på plass

KI-drevne kodingsassistenter har på under to år gått fra å være et eksperiment til å bli en selvfølge i bransjen. Black Ducks rapport The State of AI-Powered Software Development (2026) setter et oppsiktsvekkende tall på skiftet: 97 prosent av alle programvareteam bruker nå KI-kodingsverktøy aktivt . Men bak den imponerende adopsjonsraten skjuler det seg et ubehagelig faktum – infrastrukturen for å gjennomgå, sikre og styre all denne koden har overhodet ikke hengt med.

Bare 30 prosent av organisasjonene har et helhetlig styringsregime for KI-tilsyn . For de resterende 70 prosentene produserer KI-assistentene kode i et tempo som eksisterende arbeidsflyter ikke klarer å absorbere. Resultatet er det Black Duck kaller et «voksende styringsunderskudd» – og det tærer stille på selve produktivitetsgevinstene verktøyene skulle levere .

De tre flaskehalsene som spiser opp tidsbesparelsen

Rapporten identifiserer et tydelig mønster: KI-verktøy fremskynder skrivingen av kode, men hastigheten skaper trykkpunkter overalt ellers. Ni av ti team rapporterte problemer med KI-generert kode et eller annet sted i arbeidsflyten . Problemene fordeler seg ikke tilfeldig, men konsentrerer seg i tre nedstrømsaktiviteter:

• Manuell kodegjennomgang (52 %) – reviewerne behandler nå et større volum KI-generert kode enn menneskeskrevet kode, og volumet bare vokser .
• Sikkerhetstesting (51 %) – KI-generert kode introduserer nye sårbarhetsklasser som ikke fantes i den håndskrevne varianten, spesielt rundt avhengighetsinjeksjon, hardkodede hemmeligheter og utdaterte bibliotekanbefalinger .
• Omarbeiding av generert kode (48 %) – nesten halvparten av teamene oppgir at de bruker betydelig tid på å fikse, refaktorere eller skrive om KI-generert kode før den kan sendes ut .

Dette mønsteret har fått et navn: toil shift. I stedet for å eliminere arbeid, flytter KI-assistentene det fra kodingsfasen til verifikasjon, testing og feilretting . Black Ducks konklusjon er brutal: «de fleste organisasjoner produserer KI-generert kode raskere enn de kan gjennomgå, sikre eller styre den» .

Styring: Den virkelige avkastningsmultiplikatoren

Er det én innsikt fra rapporten som teknologiledere bør merke seg, er det denne: governance er avkastningsmultiplikatoren . Forskjellen på team som styrer KI-bruken og de som ikke gjør det, er ikke marginal. Det er forskjellen på å høste effektivitetsgevinster og å se dem renne ut i sanden.

Black Duck fant at organisasjoner med fullverdige styringsrammeverk opplevde 90 prosent store effektivitetsgevinster fra KI-kodingsverktøyene. For team uten strukturert tilsyn falt andelen til 44 prosent .

Governance betyr i denne konteksten ikke tungrodde byråkratiske prosesser. Det betyr å ha definerte retningslinjer for hvilke verktøy som skal brukes, hvordan KI-generert kode skal gjennomgås, hvilke sikkerhetsgrinder som skal passeres, og hvem som eier sluttproduktet. Forskjellen er «utviklere bruker det de vil» mot «utviklere bruker godkjente verktøy i en strukturert, reviderbar CI/CD-pipeline».

Skygge-KI som ulmer i kulissene

Styringsutfordringen kompliseres ytterligere av fremveksten av såkalt Shadow AI – utviklere som bruker KI-verktøy i strid med eller på siden av selskapets retningslinjer. Black Ducks funn viser at 18 prosent av organisasjonene opplever skygge-KI som en betydelig uhåndtert risiko . Når verktøy som Cursor, Windsurf eller Claude Code adopteres på individnivå utenom innkjøpsprosesser og sikkerhetsvurderinger, mister organisasjonen total oversikt over angrepsflaten sin .

Risiko i leverandørkjeden: Hva KI-generert kode arver

Implikasjonene for leverandørkjeden er konkrete og alvorlige. Black Ducks arbeid – inkludert den relaterte 2026 OSSRA-rapporten – avdekker tre sammenvevde risikofaktorer som er særegne for KI-kodingsassistenter:

Lisensvasking («license laundering»). KI-assistenter som er trent på åpen kildekode-depoter, kan generere kodebiter fra copyleft-kilder uten å bevare den opprinnelige lisensinformasjonen . 2026-rapporten fant at to tredjedeler av de reviderte kodebasene inneholder lisenskonflikter – den høyeste andelen i rapportens historie . Organisasjoner risikerer å sende ut kode de ikke har rett til å bruke, uten å vite det.

Avhengighetseksplosjon. Antall åpen kildekode-komponenter per kodebase steg 30 prosent fra år til år, og gjennomsnittlig antall sårbarheter per kodebase eksploderte med 107 prosent . KI-assistenter forsterker denne trenden fordi de setter sammen løsninger raskere og fra et bredere treningskorpus – noe som betyr at hver KI-generert funksjon kan trekke inn avhengigheter utvikleren ikke eksplisitt har valgt.

Compliance-gapet. Kun 24 prosent av organisasjonene utfører omfattende evalueringer av KI-generert kode med tanke på immaterielle rettigheter (IPR), lisenser, sikkerhet og kvalitet . Det betyr at tre av fire organisasjoner ikke kan gi et pålitelig svar på spørsmålet: «Hvilke juridiske og sikkerhetsmessige forpliktelser har vi akkurat påtatt oss?»

Utviklertillit: Adopsjonen øker mens tilliten faller

Black Ducks funn står ikke alene. Flere uavhengige undersøkelser publisert omtrent samtidig, forsterker tillitsutfordringen med detaljerte data:

• Sonars 2026 State of Code Developer Survey (over 1 100 utviklere) viser at 96 prosent av utviklerne ikke stoler fullt ut på den funksjonelle nøyaktigheten i KI-generert kode . Likevel er det bare 48 prosent som alltid verifiserer den før commit .
• Stack Overflows 2025 Developer Survey (49 009 respondenter) viser at tilliten til KI-nøyaktighet falt fra 40 til 29 prosent på ett eneste år. Aktiv mistillit steg til 46 prosent, mens andelen med positiv holdning falt fra 72 til 60 prosent .
• Harness' State of AI-Driven Software Releases 2026 (500 teknologiledere) fant at 57 prosent fortsatt krever «human-in-the-loop»-gjennomgang for hver eneste linje med KI-generert kode, og at 29 prosent bruker mer tid på kodegjennomgang nå enn før de tok i bruk KI-assistenter .

Konsensus på tvers av disse undersøkelsene er bemerkelsesverdig konsistent: utviklere kan ikke jobbe uten KI-verktøy, men de kan heller ikke stole fullt ut på dem. Gapet mellom generering og verifikasjon har blitt den nye flaskehalsen.

Diana Kelley, CISO i Noma Security, fanget kjernen i spenningen: «Raskere kode er ikke det samme som tryggere kode» .

Hvordan styring ser ut i praksis

Black Ducks oppskrift er ikke abstrakt. Rapporten peker på et sett konkrete tiltak som skiller de 30 prosentene med full governance fra resten:

1. Strukturerte KI-styringsrammeverk – ikke uformelle retningslinjer, men dokumenterte og håndhevde policyer for verktøygodkjenning, kontroll av KI-generert kode og ansvarliggjøring .
2. Pipeline-integrerte grinder for review – bort fra manuelle overleveringer til sikkerhetstestkøen (som 46 % av selskapene fortsatt bruker), og over til automatiserte kvalitets- og sikkerhetssjekker som kjører ved hver eneste KI-assisterte commit .
3. Kontinuerlig overvåking etter produksjonssetting – Black Duck påpeker at en «shift-left only»-strategi ikke lenger er tilstrekkelig, fordi risiko introduseres, oppdages og må håndteres gjennom hele livssyklusen for programvareutvikling .
4. Rydding i sikkerhetsverktøykassen – over 71 prosent av respondentene rapporterte verktøyfloke («tool sprawl») som en hovedkilde til friksjon, og konsolidering på færre, bedre integrerte verktøy er en forutsetning for å skalere KI trygt .

Oppsummert

Black Duck-rapporten argumenterer ikke mot bruk av KI-kodingsassistenter. Den argumenterer for at bruk uten tilsvarende styring er selvødeleggende. Når 97 prosent av teamene genererer kode i en hittil usett hastighet, men bare 30 prosent har kontrollinfrastrukturen til å håndtere den, skriver bransjen kollektivt ut sjekker den ikke kan innfri.

Sammenhengen mellom styring og effektivitetsgevinster – 90 mot 44 prosent – gjør businesscaset entydig. Organisasjonene som bygger rekkverkene først, vil være de som faktisk realiserer produktivitetsløftet KI representerer. De som ikke gjør det, vil gang på gang oppdage at tiden som spares ved tastaturet, fordufter i køen for manuell review og testing.