Dine systemer har allerede blinde pletter. AI gør dem kun værre.

I 2022, før generative kodningsværktøjer var en del af vores daglige ingeniørarbejde, skrev jeg om min filosofi om valg af værktøjer. Det har holdt længere, end jeg forventede. Dengang argumenterede jeg for at starte med de problemer, du faktisk løste, kende dine svagheder og prioritere, hvordan du bruger værktøjerne i stedet for blot at hoppe på ethvert værktøj, der lyder bedst, og håbe det virker. Kend dig selv og dine mål, så du kan sætte korrekte forventninger til dine værktøjer.

På det tidspunkt tænkte jeg på SaaS-spredning, ikke AI-genereret kode. Men i dag er min filosofi endnu mere presserende og vigtigere at holde fast ved.

Mange af os har læst 2025 DORA report, som fandt ud af, at i modsætning til året før korrelerer AI-adoption nu positivt med leveringsgennemløb. Den underliggende konklusion var, at leveringsinstabilitet fortsatte med at stige, og de testede, om hastighedsgevinsterne dækker dette. Det gør de ikke. Det stemmer overens med vores erfaring. Vores team adopterede agentisk softwareudvikling og oplevede en stigning på 48 % i gennemløb over to kvartaler, efterfulgt af en stigning på 16 % i stabilitetsproblemer. Ti personer er et lille udsnit, men det er også et udsnit, hvorfra jeg kan se det fulde billede, og mønsteret holdt stand.

AI-adoption er egentlig ikke længere et spørgsmål. Du er enten lige begyndt eller er i fuld gang med det. Det, der er anderledes nu, er, at ingeniørledere forventes at adoptere AI og også bevise, at det betaler sig. CEO’en, bestyrelsen og økonomiafdelingen vil alle vide, hvordan de kan optimere deres AI-investering. De spørger, om de værktøjer, du har valgt, løser reelle problemer effektivt.

Mellemrummet har altid været der. AI gjorde det blot bredere.

Som CTO bruger jeg en stor del af min tid på at tale med andre ingeniørledere, herunder kunder, potentielle kunder og kolleger, for at sammenligne resultater og klager om, hvad vi oplever med AI. Efter et tilstrækkeligt antal af disse samtaler er jeg begyndt at se mønstre i AI-adoption og resultater.

Den primære observation er ikke min. DORA har fremhævet den i to år nu: AI forstærker alt, hvad der allerede foregår i organisationen, både styrker og svagheder. Et team med ren arkitektur og sunde review-vaner bliver hurtigere. Et team, der har håndteret en rodet kugle af teknisk gæld nok til at levere kode, opdager nu, at den tekniske gæld vokser til en væsentlig hindring. Det, denne ramme overser, er hvorfor dette overrasker så mange teams. AI skjulte ikke disse svagheder; de systemer, vi har stolet på, frembragte dem aldrig.

Den ticket- og rapporteringsstack, som de fleste ingeniørorganisationer bruger, blev bygget til at besvare spørgsmål, som mennesker har, i menneskelig hastighed, af personer, der omtrent forstod, hvad “færdig” betød for et givet stykke arbejde. Den var aldrig en perfekt registrering. Den var altid en tilnærmelse, udfyldt af nogen, der opsummerede noget mere rodet bagved. Nu tilføjer AI volumen og nye input, der genererer ny aktivitet. Ingen af de systemer (eller værktøjer), der bruges til traditionelle, ikke-AI-udviklingsmetoder, blev nogensinde bygget til dette.

Uanset hvad er vi stadig ansvarlige for de samme mål. Du ejer stadig hastighed, kvalitet, omkostninger og hvordan dit team faktisk klarer sig. Du kan bare ikke længere tage sidste års dashboards for givet.

Der er en rimelig indvending her. DORA’s 2026 ROI report beskriver en J-kurve: et produktivitetsfald lige efter adoption, drevet af indlæringskurven, omkostningerne ved at verificere AI-genereret kode og nedstrømsprocesser, der ikke er indhentet. De kalder det “undervisningsomkostningen” ved transformation, og de advarer ledere om ikke at forveksle det med fiasko. Det er rimeligt. Men undervisningsomkostning og et reelt problem ser identiske ud på et dashboard bygget ud fra tickets. Hvis du ikke kan se, hvilken du befinder dig i, er du ikke tålmodig. Du gætter.

Vi skal vende tilbage til det grundlæggende. Kend dig selv. Kend dit team. Kend hvilke problemer du løser.

Hvordan “kender du dig selv” med AI?

Ud fra mine samtaler har jeg identificeret fem hovedområder, hvor konventionelle systemer, bygget til menneskeskabt, menneskeligt rapporteret arbejde, er blinde. Ignorerer du dem, risikerer du at forstærke dine svagheder, mens du fortsætter med at adoptere AI.

Blind plet 1: Hastighedsteater

Flere commits og flere PR’er kan føles som fremgang, og ofte er det det også. AI øger begge tal automatisk. En Stanford case study viste, at adoption af AI hævede PR-tallet med 14 %. Men det du går glip af, er hvor meget af den aktivitet der er funktionsarbejde, der leveres, versus vedligeholdelse, genarbejde eller omsætning fra en refaktorering, der ikke holdt.

For at håndtere dette, hold øje med fordelingen mellem funktionsarbejde og vedligeholdelse, samt deployment-frekvens og gennemløbstid i forhold til din egen historiske baseline, ikke et branchegennemsnit. Uden den fordeling rapporterer du fremgang, du ikke kan underbygge.

Blind plet 2: Review-gæld

Reviewkapaciteten skalerer ikke automatisk i takt med output. Verifikationsafgiften er ikke en fase, du kommer igennem; den er en del af de faste omkostninger ved agentisk udvikling. En en nylig undersøgelse af ingeniørledere fandt, at 80 % af teamene bruger mindst 10 % af deres tid på review, og cirka én ud af ti bruger mere end 40 %. Under den belastning svinger teamene mellem en voksende backlog og blind godkendelse, og ingen af delene er en reel løsning.

Begrænsningen på udgivelse er ikke længere, hvor hurtigt kode bliver skrevet. Det er hvor hurtigt en person faktisk kan være sikker på, at en ændring er korrekt, hvor hurtigt og præcist fejl kan opdages og håndteres. Hold øje med, hvordan reviewbelastningen faktisk fordeles på dit team; ellers risikerer du at overbelaste dine senioringeniører, forsinke dine udgivelser eller forårsage alvorlige produktionsproblemer.

Blind Plet 3: Skjult Arbejde

Refaktoreringer og arkitekturskift har en tendens til at gemme sig i andre tickets, hvis de overhovedet dukker op i ticketsystemet. AI producerer mere af denne type arbejde, ikke mindre. En agent tøver ikke med at røre ved tolv filer for at rette én fejl, mens et menneske måske stopper op og genovervejer. Arbejde, der springer systemet for registrering over, springer også planlægning over, hvilket betyder, at din kapacitetsmodel er forkert, og alle prognoser bygget ovenpå den er også forkerte.

For at forstå, hvor meget arbejde der faktisk udføres, skal du holde øje med, hvor meget der faktisk ændrer sig i kodebasen og i pull‑request‑historikken. Uden det er din kapacitetsplan bygget på, hvad folk huskede at logge, ikke på hvad de faktisk gjorde.

Blind Plet 4: Kvalitetsdrift

Den samme undersøgelse fandt, at næsten halvdelen af ingeniørlederne har svært ved at opdage sikkerhedsproblemer uge efter uge. Kompleksitet, duplikering og afhængigheder, der ikke helt hører hjemme, opbygges over mange små, individuelt rimelige ændringer. Ingen af dem virker alarmerende alene. I den samme Stanford‑case‑studie faldt kodekvaliteten med 9 % og dens variation mere end tredoblede. Mens gennemsnittet ændrede sig lidt, ændrede spredningen (den del du bemærker) sig meget. Ved AI‑volumen forstærkes de hurtigere, end de fleste review‑processer kan fange dem. Drift viser sig typisk som en on‑call‑alarm, der kan spores tilbage til en afhængighed, ingen husker at have reviewet. Når dette sker, er der en god chance for, at en kunde har bemærket det først.

Hold øje med tendenslinjerne for sikkerhedsfund, afhængigheder samt fejl og genoprettelse – ikke den enkelte commit. Kompleksitet og duplikering, der sniger sig op over flere uger, betyder mere end enhver enkelt ændring, der bliver markeret i review. Uden dette fanger du drift på den måde, de fleste teams stadig gør: efter den allerede har forårsaget en hændelse.

Blind Plet 5: Ubevist Forbrug

Når AI‑adoptionen ikke længere er et debatemne, bliver AI‑forbrug og ROI det spørgsmål, alle fokuserer på. Finans vil vide, hvad der er kapitaliserbart versus operationelt. Ledelsen vil vide, hvad investeringen har resulteret i. De fleste teams træffer stadig beslutninger om værktøjer, licenser og bemanding baseret på intuition, ikke på bevis for sammenhængen mellem penge og leveret arbejde.

Hold øje med, hvor ingeniørindsatsen faktisk flyder i selve kodebasen, kvartal for kvartal — ikke hvor køreplanen siger, den skal flyde. Uden den forbindelse forsvarer du næste års budget med anekdoter, og anekdoter holder ikke til en hård samtale med en CFO.

Start Med Det Du Ikke Kan Se

Finans’ spørgsmål om kapitaliseret forbrug og en on‑call‑side kl. 02.00 ser ud til at være urelaterede, men er de ikke. Begge kan “gætte‑estimeres” ud fra aktivitet. Men begge kan faktisk besvares med beviser fra selve koden.

DORAs svar på alt dette er selve ingeniørsystemet: platformskvalitet, workflow‑klarhed, team‑justering. Det er korrekt, men det er heller ikke første skridt. Du kan ikke rette et system, du ikke kan se. Hvert af de fem områder er noget, du skal kunne observere, før du kan argumentere for at investere i det.

Det første nyttige skridt er ikke et nyt værktøj eller en ny proces. Det er at kende sig selv, ærligt, og afgøre, hvilke af disse fem områder der er blinde pletter, hvor du mangler reelle beviser. De fleste ledere kan straks identificere (og er opmærksomme på) problemer i et af disse områder. Dog er det netop de områder, hvor du har mindst information, som mest sandsynligt vil dukke op og bide dig, når du fortsætter med at adoptere AI.