De tre flaskhalsarna som suddar ut kodvinsterna

Rapporten identifierar ett tydligt mönster: AI-verktyg accelererar skrivandet av kod, men den hastigheten skapar tryckpunkter överallt annars. Nio av tio team rapporterade problem med AI-genererad kod någonstans i sitt arbetsflöde . Problemen uppstår inte slumpmässigt. De koncentreras till tre nedströms aktiviteter som tillsammans absorberar den tid som sparades tidigare i cykeln:

• Manuell kodgranskning (52 %) – granskare bearbetar nu en större volym AI-genererad kod än människoskriven, och volymen växer .
• Säkerhetstestning (51 %) – AI-genererad kod introducerar nya sårbarhetsklasser som inte fanns i den handskrivna motsvarigheten, särskilt kring beroendeinjektion, hårdkodade hemligheter och föråldrade biblioteksrekommendationer .
• Omarbetning av genererad kod (48 %) – nästan hälften av teamen lägger betydande tid på att fixa, refaktorisera eller skriva om AI-utdata innan den kan levereras .

Mönstret har nu fått ett namn: toilförskjutning. Istället för att eliminera arbete flyttar AI det från skapandefasen till verifierings-, testnings- och åtgärdsfaserna . Black Duck formulerar det rakt på sak: "de flesta organisationer producerar AI-genererad kod snabbare än de kan granska, säkra eller styra den" .

Styrning: den verkliga avkastningsmultiplikatorn

Om det finns ett enda fynd från rapporten som ingenjörschefer bör agera på är det detta: styrning är avkastningsmultiplikatorn . Skillnaden mellan team som styr AI-användning och de som inte gör det är inte marginell – det är skillnaden mellan att fånga effektivitetsvinster och att se dem läcka ut genom sidorna.

Black Duck fann att organisationer med heltäckande styrningsramverk rapporterade 90 % stora effektivitetsvinster från AI-kodverktyg. Team utan strukturerad tillsyn? Siffran sjunker till 44 % .

Styrning i detta sammanhang betyder inte byråkrati. Det betyder definierade riktlinjer för vilka verktyg som får användas, hur AI-genererad kod ska granskas, vilka säkerhetskontroller som måste passeras och vem som äger utdata. Det är skillnaden mellan "utvecklare använder vad de vill" och "utvecklare använder godkända verktyg inom en strukturerad, reviderbar pipeline".

Problemet med skugg-AI

Det som komplicerar styrning är framväxten av skugg-AI – utvecklare som använder AI-verktyg mot eller utanför företagets policy. Black Duck fann att 18 % av organisationer rapporterar skugg-AI som en betydande ohanterad risk . När verktyg som Cursor, Windsurf eller Claude Code adopteras på individnivå utan att passera inköp eller säkerhetsgranskning förlorar organisationen insyn i sin attackyta .

Risker i leveranskedjan: vad AI-genererad kod ärver

Implikationerna för leveranskedjan är där styrningsluckor blir konkreta sårbarheter. Black Ducks arbete – inklusive den relaterade 2026 OSSRA-rapporten – lyfter fram tre sammanlänkade risker som är specifika för AI-kodassistenter:

Licenstvätt. AI-assistenter som tränats på öppen källkod kan generera kodsnuttar från upphovsrättsskyddade källor utan att behålla ursprunglig licensinformation . OSSRA-rapporten 2026 fann att två tredjedelar av granskade kodbaser innehåller licenskonflikter – den högsta andelen i rapportens historia . Organisationer kan leverera kod de inte har rätt att använda, utan att veta om det.

Beroendeexplosion. Antalet komponenter med öppen källkod per kodbas ökade med 30 % jämfört med föregående år, och genomsnittliga sårbarheter per kodbas ökade med 107 % . AI-kodassistenter accelererar denna trend eftersom de komponerar lösningar snabbare och från bredare träningsunderlag – vilket innebär att varje AI-genererad funktion kan dra in beroenden som utvecklaren inte uttryckligen valt.

Efterlevnadsgapet. Endast 24 % av organisationer utför heltäckande utvärderingar av immateriella rättigheter, licens, säkerhet och kvalitet för AI-genererad kod . Det innebär att tre fjärdedelar av organisationerna inte tillförlitligt kan svara på frågan: "Vilka juridiska och säkerhetsmässiga skyldigheter har vi just tagit på oss?"

Utvecklarnas förtroende: användningen ökar medan tilltron faller

Black Ducks fynd existerar inte i ett vakuum. Flera oberoende undersökningar som publicerats under samma period förstärker och fördjupar förtroendebilden med detaljerad data:

• Sonars State of Code Developer Survey 2026 (över 1 100 utvecklare) fann att 96 % av utvecklare inte fullt ut litar på den funktionella korrektheten hos AI-genererad kod . Ändå verifierar endast 48 % alltid koden innan den checkas in – vilket betyder att kod som utvecklare själva misstror regelbundet levereras till produktion .
• Stack Overflows utvecklarundersökning 2025 (49 009 respondenter) visade att förtroendet för AI:s noggrannhet sjönk från 40 % till 29 % på ett år. Aktiv misstro steg till 46 %, medan positiv gynnsamhet sjönk från 72 % till 60 % .
• Harness State of AI-Driven Software Releases 2026 (500 ingenjörschefer) fann att 57 % fortfarande kräver människa-i-loopen-granskning för varje rad AI-genererad kod, och 29 % spenderar mer tid på kodgranskning nu än innan de adopterade AI-assistenter .

Konsensusen i dessa undersökningar är anmärkningsvärt konsekvent: utvecklare kan inte arbeta utan AI-verktyg, men de kan inte heller fullt ut lita på dem. Gapet mellan generering och verifiering har blivit den nya flaskhalsen.

Diana Kelley, CISO på Noma Security, fångade kärnspänningen: "Snabbare kod är inte samma sak som säkrare kod" .

Hur styrning faktiskt ser ut

Black Ducks recept är inte abstrakt. Rapporten pekar på en uppsättning konkreta åtgärder som skiljer de 30 % med full styrning från resten:

1. Strukturerade AI-styrningsramverk – inte informella riktlinjer, utan dokumenterade och upprätthållna policyer som täcker verktygsgodkännande, outputgranskning och ansvarsskyldighet .
2. Pipeline-integrerade granskningsgrindar – röra sig bort från manuella överlämningar till säkerhetstestningsköer, vilket 46 % av företagen fortfarande använder, mot automatiserade kvalitets- och säkerhetskontroller som körs vid varje AI-assisterad commit .
3. Kontinuerlig övervakning efter driftsättning – Black Duck noterar att en "enbart shift-left-strategi inte längre är tillräcklig" eftersom risk introduceras, upptäcks och måste hanteras över hela mjukvaruutvecklingslivscykeln .
4. Rationalisering av säkerhetsverktygskedjan – över 71 % av respondenterna rapporterade verktygsspridning som en stor friktionskälla, och konsolidering till färre, bättre integrerade verktyg är en förutsättning för att skala AI säkert .

Slutsatsen

Black Duck-rapporten argumenterar inte mot att använda AI-kodassistenter. Den argumenterar för att använda dem utan motsvarande styrning är självdestruktivt. När 97 % av teamen genererar kod i oöverträffad hastighet men bara 30 % har tillsynsinfrastrukturen för att hantera den, skriver branschen kollektivt ut checkar den inte kan lösa in.

Korrelationen mellan styrning och effektivitetsvinster – 90 % kontra 44 % – gör affärscaset otvetydigt. Organisationer som bygger skyddsräckena först kommer att fånga den produktivitet AI lovar. De som inte gör det kommer att upptäcka, om och om igen, att tid sparad vid tangentbordet spenderas i granskningskön.

De tre flaskhalsarna som suddar ut kodvinsterna

Rapporten identifierar ett tydligt mönster: AI-verktyg accelererar skrivandet av kod, men den hastigheten skapar tryckpunkter överallt annars. Nio av tio team rapporterade problem med AI-genererad kod någonstans i sitt arbetsflöde . Problemen uppstår inte slumpmässigt. De koncentreras till tre nedströms aktiviteter som tillsammans absorberar den tid som sparades tidigare i cykeln:

• Manuell kodgranskning (52 %) – granskare bearbetar nu en större volym AI-genererad kod än människoskriven, och volymen växer .
• Säkerhetstestning (51 %) – AI-genererad kod introducerar nya sårbarhetsklasser som inte fanns i den handskrivna motsvarigheten, särskilt kring beroendeinjektion, hårdkodade hemligheter och föråldrade biblioteksrekommendationer .
• Omarbetning av genererad kod (48 %) – nästan hälften av teamen lägger betydande tid på att fixa, refaktorisera eller skriva om AI-utdata innan den kan levereras .

Mönstret har nu fått ett namn: toilförskjutning. Istället för att eliminera arbete flyttar AI det från skapandefasen till verifierings-, testnings- och åtgärdsfaserna . Black Duck formulerar det rakt på sak: "de flesta organisationer producerar AI-genererad kod snabbare än de kan granska, säkra eller styra den" .

Styrning: den verkliga avkastningsmultiplikatorn

Om det finns ett enda fynd från rapporten som ingenjörschefer bör agera på är det detta: styrning är avkastningsmultiplikatorn . Skillnaden mellan team som styr AI-användning och de som inte gör det är inte marginell – det är skillnaden mellan att fånga effektivitetsvinster och att se dem läcka ut genom sidorna.

Black Duck fann att organisationer med heltäckande styrningsramverk rapporterade 90 % stora effektivitetsvinster från AI-kodverktyg. Team utan strukturerad tillsyn? Siffran sjunker till 44 % .

Styrning i detta sammanhang betyder inte byråkrati. Det betyder definierade riktlinjer för vilka verktyg som får användas, hur AI-genererad kod ska granskas, vilka säkerhetskontroller som måste passeras och vem som äger utdata. Det är skillnaden mellan "utvecklare använder vad de vill" och "utvecklare använder godkända verktyg inom en strukturerad, reviderbar pipeline".

Problemet med skugg-AI

Det som komplicerar styrning är framväxten av skugg-AI – utvecklare som använder AI-verktyg mot eller utanför företagets policy. Black Duck fann att 18 % av organisationer rapporterar skugg-AI som en betydande ohanterad risk . När verktyg som Cursor, Windsurf eller Claude Code adopteras på individnivå utan att passera inköp eller säkerhetsgranskning förlorar organisationen insyn i sin attackyta .

Risker i leveranskedjan: vad AI-genererad kod ärver

Implikationerna för leveranskedjan är där styrningsluckor blir konkreta sårbarheter. Black Ducks arbete – inklusive den relaterade 2026 OSSRA-rapporten – lyfter fram tre sammanlänkade risker som är specifika för AI-kodassistenter:

Licenstvätt. AI-assistenter som tränats på öppen källkod kan generera kodsnuttar från upphovsrättsskyddade källor utan att behålla ursprunglig licensinformation . OSSRA-rapporten 2026 fann att två tredjedelar av granskade kodbaser innehåller licenskonflikter – den högsta andelen i rapportens historia . Organisationer kan leverera kod de inte har rätt att använda, utan att veta om det.

Beroendeexplosion. Antalet komponenter med öppen källkod per kodbas ökade med 30 % jämfört med föregående år, och genomsnittliga sårbarheter per kodbas ökade med 107 % . AI-kodassistenter accelererar denna trend eftersom de komponerar lösningar snabbare och från bredare träningsunderlag – vilket innebär att varje AI-genererad funktion kan dra in beroenden som utvecklaren inte uttryckligen valt.

Efterlevnadsgapet. Endast 24 % av organisationer utför heltäckande utvärderingar av immateriella rättigheter, licens, säkerhet och kvalitet för AI-genererad kod . Det innebär att tre fjärdedelar av organisationerna inte tillförlitligt kan svara på frågan: "Vilka juridiska och säkerhetsmässiga skyldigheter har vi just tagit på oss?"

Utvecklarnas förtroende: användningen ökar medan tilltron faller

Black Ducks fynd existerar inte i ett vakuum. Flera oberoende undersökningar som publicerats under samma period förstärker och fördjupar förtroendebilden med detaljerad data:

• Sonars State of Code Developer Survey 2026 (över 1 100 utvecklare) fann att 96 % av utvecklare inte fullt ut litar på den funktionella korrektheten hos AI-genererad kod . Ändå verifierar endast 48 % alltid koden innan den checkas in – vilket betyder att kod som utvecklare själva misstror regelbundet levereras till produktion .
• Stack Overflows utvecklarundersökning 2025 (49 009 respondenter) visade att förtroendet för AI:s noggrannhet sjönk från 40 % till 29 % på ett år. Aktiv misstro steg till 46 %, medan positiv gynnsamhet sjönk från 72 % till 60 % .
• Harness State of AI-Driven Software Releases 2026 (500 ingenjörschefer) fann att 57 % fortfarande kräver människa-i-loopen-granskning för varje rad AI-genererad kod, och 29 % spenderar mer tid på kodgranskning nu än innan de adopterade AI-assistenter .

Konsensusen i dessa undersökningar är anmärkningsvärt konsekvent: utvecklare kan inte arbeta utan AI-verktyg, men de kan inte heller fullt ut lita på dem. Gapet mellan generering och verifiering har blivit den nya flaskhalsen.

Diana Kelley, CISO på Noma Security, fångade kärnspänningen: "Snabbare kod är inte samma sak som säkrare kod" .

Hur styrning faktiskt ser ut

Black Ducks recept är inte abstrakt. Rapporten pekar på en uppsättning konkreta åtgärder som skiljer de 30 % med full styrning från resten:

1. Strukturerade AI-styrningsramverk – inte informella riktlinjer, utan dokumenterade och upprätthållna policyer som täcker verktygsgodkännande, outputgranskning och ansvarsskyldighet .
2. Pipeline-integrerade granskningsgrindar – röra sig bort från manuella överlämningar till säkerhetstestningsköer, vilket 46 % av företagen fortfarande använder, mot automatiserade kvalitets- och säkerhetskontroller som körs vid varje AI-assisterad commit .
3. Kontinuerlig övervakning efter driftsättning – Black Duck noterar att en "enbart shift-left-strategi inte längre är tillräcklig" eftersom risk introduceras, upptäcks och måste hanteras över hela mjukvaruutvecklingslivscykeln .
4. Rationalisering av säkerhetsverktygskedjan – över 71 % av respondenterna rapporterade verktygsspridning som en stor friktionskälla, och konsolidering till färre, bättre integrerade verktyg är en förutsättning för att skala AI säkert .

Slutsatsen

Black Duck-rapporten argumenterar inte mot att använda AI-kodassistenter. Den argumenterar för att använda dem utan motsvarande styrning är självdestruktivt. När 97 % av teamen genererar kod i oöverträffad hastighet men bara 30 % har tillsynsinfrastrukturen för att hantera den, skriver branschen kollektivt ut checkar den inte kan lösa in.

Korrelationen mellan styrning och effektivitetsvinster – 90 % kontra 44 % – gör affärscaset otvetydigt. Organisationer som bygger skyddsräckena först kommer att fånga den produktivitet AI lovar. De som inte gör det kommer att upptäcka, om och om igen, att tid sparad vid tangentbordet spenderas i granskningskön.