Dina system har redan blindspots. AI gör dem bara värre.

År 2022, innan generativa kodverktyg var en del av vårt dagliga ingenjörsarbete, skrev jag om min filosofi kring verktygsval. Det har hållit bättre än jag förväntade mig. Då argumenterade jag för att börja med de problem du faktiskt löste, känna till dina svagheter och prioritera hur du använder verktygen snarare än att bara hoppa på vilket verktyg som helst som låter bäst och hoppas att det fungerar. Känn dig själv och dina mål, så du kan ställa rätt förväntningar på dina verktyg.

Vid den tiden tänkte jag på SaaS-utbredning, inte AI-genererad kod. Men idag är min filosofi ännu mer brådskande och ännu viktigare att hålla fast vid.

Många av oss har läst 2025 DORA-rapporten, som fann att, till skillnad från föregående år, AI‑adoption nu korrelerar positivt med leveransgenomströmning. Undersökningen bakom den visade att leveransinstabilitet fortsatte öka, och de testade om hastighetsvinsterna kompenserade för den. Det gör de inte. Det stämmer med vår erfarenhet. Vårt team antog agentisk mjukvaruutveckling och såg en 48 % ökning i genomströmning över två kvartal, följt av en 16 % ökning i stabilitetsproblem. Tio personer är ett litet urval, men det är också ett urval där jag kan se hela bilden, och mönstret höll i sig.

AI‑adoption är egentligen inte längre en fråga. Du är antingen precis i början eller mitt i det. Vad som är annorlunda nu är att ingenjörsledare förväntas anta AI och även bevisa att det ger avkastning. VD:n, styrelsen och finansavdelningen vill alla veta hur de kan optimera sin AI‑investering. De frågar om de verktyg du valt löser riktiga problem på ett effektivt sätt.

Klyftan har alltid funnits. AI gjorde den bara bredare.

Som CTO tillbringar jag en stor del av min tid med att prata med andra ingenjörsledare, inklusive kunder, potentiella kunder och kollegor, för att jämföra framgångar och klagomål om vad vi upplever med AI. Efter tillräckligt många av dessa samtal har jag börjat se mönster i AI‑adoption och resultat.

Den huvudsakliga observationen är inte min. DORA har drivit detta i två år nu: AI förstärker allt som redan händer i organisationen, både styrkor och svagheter. Ett team med ren arkitektur och sunda granskningsvanor blir snabbare. Ett team som har tämjts en svår teknisk skuld tillräckligt för att leverera kod upptäcker nu att den tekniska skulden växer till ett stort hinder. Vad den ramen missar är varför detta överraskar så många team. AI gömde inte dessa svagheter; de system vi förlitat oss på avslöjade dem aldrig.

Det ärende‑ och rapporteringssystem som de flesta ingenjörsorganisationer använder byggdes för att besvara frågor som människor har, i mänsklig hastighet, av personer som ungefär förstod vad “klart” innebar för ett givet arbetsstycke. Det var aldrig en perfekt journal. Det var alltid en approximation, fylld i av någon som sammanfattade något rörigare under ytan. Nu lägger AI till volym och nya indata som genererar ny aktivitet. Inga av de system (eller verktyg) som används för traditionella, icke‑AI‑metoder för utveckling byggdes någonsin för det.

Oavsett detta är vi fortfarande ansvariga för samma mål. Du ansvarar fortfarande för hastighet, kvalitet, kostnader och hur ditt team faktiskt presterar. Du kan bara inte längre lita på förra årets instrumentpanel på förtroende.

Det finns ett rimligt invändning här. DORA:s 2026 ROI‑rapport beskriver en J‑kurva: ett produktivitetsdip direkt efter adoption, drivet av inlärningskurvan, kostnaden för att verifiera AI‑genererad kod och efterföljande processer som inte har hunnit ikapp. De kallar det “utbildningskostnaden” för transformationen, och varnar ledare för att inte missta den för misslyckande. Rättvist. Men utbildningskostnad och ett verkligt problem ser identiska ut på en instrumentpanel byggd från ärenden. Om du inte kan avgöra vilken du befinner dig i, är du inte tålmodig. Du gissar.

Vi måste återgå till grunderna. Känn dig själv. Känn ditt team. Känn vilka problem du löser.

Hur kan du “Känna dig själv” med AI?

Från mina samtal har jag identifierat fem huvudområden där konventionella system, byggda för mänskligt genererat, mänskligt rapporterat arbete, är blinda. Ignorera dem och du riskerar att förstärka dina svagheter när du fortsätter att anta AI.

Blind spot 1: Hastighetsteater

Fler commit och fler PR:er kan kännas som framsteg, och ofta är det så. AI ökar båda räknarna automatiskt. En Stanford-fallstudie visade att antagandet av AI ökade PR‑antalet med 14 %. Men det du missar är hur stor del av den aktiviteten som är funktionsarbete som levereras jämfört med underhåll, omarbetning eller omsvängning från en refaktorering som inte höll.

För att hantera detta, håll koll på fördelningen mellan funktionsarbete och underhåll, samt på distributionsfrekvens och ledtid mot din egen historiska baslinje, inte ett branschgenomsnitt. Utan den fördelningen rapporterar du framsteg som du egentligen inte kan styrka.

Blind spot 2: Granskningsskuld

Granskapaciteten ökar inte automatiskt i takt med leveransen. Verifieringsskatten är inte en fas du kommer förbi; den är en del av de löpande kostnaderna för agentisk utveckling. A en nyligen genomförd undersökning av ingenjörsledare visade att 80 % av teamen spenderar minst 10 % av sin tid på granskning, och ungefär en av tio spenderar mer än 40 %. Under den belastningen pendlar teamen mellan en växande backlog och slentrianmässig godkännande, och ingen av dem är ett riktigt svar.

Begränsningen för leverans handlar inte längre om hur snabbt koden skrivs. Det handlar om hur snabbt en människa faktiskt kan vara säker på att en förändring är korrekt, om hur snabbt och exakt fel kan upptäckas och åtgärdas. Följ hur granskningsbelastningen faktiskt fördelas över ditt team; annars riskerar du att överbelasta dina seniora ingenjörer, fördröja dina releaser eller orsaka allvarliga produktionsproblem.

Blind Spot 3: Dolt arbete

Refaktoriseringar och arkitekturskiften har en tendens att gömma sig i andra ärenden, om de alls dyker upp i ärendesystemet. AI producerar mer av den här typen av arbete, inte mindre. En agent tvekar inte att röra tolv filer för att fixa ett fel, medan en människa kanske pausar och omprövar. Arbete som hoppar över systemet för registrering hoppar också över planeringen, vilket betyder att din kapacitetsmodell är felaktig, och varje prognos byggd på den är också felaktig. 

För att förstå hur mycket arbete som faktiskt utförs måste du följa hur mycket som faktiskt förändras i kodbasen och i pull‑request‑historiken. Utan det är din kapacitetsplan byggd på vad folk kom ihåg att logga, inte på vad de faktiskt gjorde. 

Blind Spot 4: Kvalitetsdrift

Samma undersökning visade att nästan hälften av ingenjörsledarna har svårt att upptäcka säkerhetsproblem vecka för vecka. Komplexitet, duplicering och beroenden som inte riktigt hör hemma byggs upp över en mängd små, individuellt rimliga förändringar. Ingen av dem ser alarmerande ut på egen hand. I samma Stanford‑fallstudie föll kodkvaliteten med 9 % och dess varians mer än tredubblades. Medan genomsnittet rörde sig lite, rörde sig spridningen (den del du märker) mycket. Vid AI‑volym sammansätts de snabbare än de flesta granskningsprocesser hinner fånga dem. Drift tenderar att visa sig som ett on‑call‑larm spårat tillbaka till ett beroende som ingen minns att ha granskat. När detta händer finns det en rimlig chans att en kund har lagt märke till det först.

Följ trendlinjerna för säkerhetsfynd, beroenden samt fel och återhämtning – inte den enskilda committen. Komplexitet och duplicering som kryper upp under flera veckor betyder mer än någon enskild förändring som flaggas i granskning. Utan det fångar du drift på samma sätt som de flesta team fortfarande gör: efter att den redan har orsakat en incident. 

Blind Spot 5: Obevisad investering

När AI‑adoptionen slutar vara en debatt blir AI‑utgifter och ROI frågan alla fokuserar på. Finans vill veta vad som är kapitaliserbart kontra operativt. Ledning vill veta vad investeringen resulterade i. De flesta team fattar fortfarande beslut om verktyg, licenser och personal baserat på intuition, inte på bevis för sambandet mellan pengar och levererat arbete.

Följ var ingenjörsinsatsen faktiskt flyter i själva kodbasen, kvartal för kvartal – inte där färdplanen säger att den ska flyta. Utan den länken försvarar du nästa års budget med anekdoter, och anekdoter håller inte i en hård konversation med en CFO.

Börja med det du inte kan se

Finansfrågan om kapitaliserade utgifter och en on‑call‑sida klockan 02.00 på morgonen verkar orelaterade, men gör det inte. Båda kan “gissas” från aktivitet. Men båda är faktiskt svarbara, med bevis, från koden själv.

DORAs svar på allt detta är själva ingenjörssystemet: plattforms­kvalitet, arbetsflödes­klarhet, team‑alignment. Det stämmer, och det är också inte steg ett. Du kan inte fixa ett system du inte kan se. Var och en av dessa fem områden är något du måste kunna observera innan du kan argumentera för att investera i det.

Det första användbara steget är inte ett nytt verktyg eller en ny process. Det är att känna sig själv, ärligt, och avgöra vilka av dessa fem områden som är blinda fläckar där du saknar verkliga bevis. De flesta ledare kan omedelbart identifiera (och uppmärksamma) problem i ett av dessa områden. Men det är de områden där du har minst information som mest sannolikt kommer att dyka upp och bita dig när du fortsätter att adoptera AI.