Systemene dine har allerede blindsoner. KI gjør dem bare verre.

I 2022, før generative kodingsverktøy ble en del av vårt daglige ingeniørarbeid, skrev jeg om min filosofi om verktøyvalg. Det har holdt bedre enn jeg forventet. Den gangen argumenterte jeg for å starte med problemene du faktisk løser, kjenne dine svakheter, og prioritere hvordan du bruker verktøyene i stedet for bare å hoppe på hvilket som helst verktøy som høres best ut og håpe det fungerer. Kjenn deg selv, og dine mål, så du kan sette riktige forventninger til verktøyene dine.

På den tiden tenkte jeg på SaaS-spredning, ikke KI-generert kode. Men i dag er filosofien min enda mer presserende, og viktigere å holde fast ved.

Mange av oss har lest 2025 DORA report, som fant at, i motsetning til året før, KI-adopsjon nå korrelerer positivt med leveringsgjennomstrømning. Funnene under den var at leveringsinstabilitet fortsatte å øke, og de testet om hastighetsgevinsten kompenserer for dette. Det gjør de ikke. Det stemmer med vår erfaring. Teamet vårt tok i bruk agentisk programvareutvikling og så en 48 % økning i gjennomstrømning over to kvartaler, etterfulgt av en 16 % økning i stabilitetsproblemer. Ti personer er et lite utvalg, men det er også et utvalg hvor jeg kan se helhetsbildet, og mønsteret holdt. 

KI-adopsjon er egentlig ikke et spørsmål lenger. Du er enten i startfasen eller midt i det. Det som er annerledes nå er at ingeniørledere forventes å ta i bruk KI og også bevise at det lønner seg. Administrerende direktør, styret og økonomiavdelingen vil alle vite hvordan de kan optimalisere KI-investeringen sin. De spør om verktøyene du har valgt løser reelle problemer effektivt. 

Gapet var alltid der. KI gjorde det bare bredere.

Som CTO bruker jeg en god del av tiden min på å snakke med andre ingeniørledere, inkludert kunder, potensielle kunder og kolleger, for å sammenligne prestasjoner og klager om hva vi opplever med KI. Etter nok slike samtaler har jeg begynt å se mønstre i KI-adopsjon og resultater.

Hovedobservasjonen er ikke min. DORA har ledet med dette i to år nå: KI forsterker alt som allerede skjer i organisasjonen, både styrker og svakheter. Et team med ren arkitektur og sunne gjennomgangsvaner blir raskere. Et team som har temmet en kronglete masse teknisk gjeld akkurat nok til å levere kode, oppdager nå at teknisk gjeld vokser til en stor hindring. Det som dette perspektivet overser, er hvorfor dette overrasker så mange team. KI skjulte ikke disse svakhetene; systemene vi har stolte på avdekket dem aldri.

Ticket- og rapporteringsstabelen som de fleste ingeniørorganisasjoner bruker, ble bygget for å svare på spørsmål som mennesker har, i menneskelig hastighet, av personer som omtrent forsto hva «ferdig» betydde for et gitt arbeid. Den var aldri en perfekt journal. Den var alltid en tilnærming, fylt inn av noen som oppsummerte noe mer rotete under. Nå legger KI til volum, og legger til nye innspill som genererer ny aktivitet. Ingen av systemene (eller verktøyene) som brukes for tradisjonelle, ikke‑KI‑metoder for utvikling, ble noen gang bygget for dette. 

Uansett er vi fortsatt ansvarlige for de samme målene. Du eier fortsatt hastighet, kvalitet, kostnader, og hvordan teamet ditt faktisk presterer. Du kan ikke lenger ta fjorårets dashbord på tro.

Det er en rimelig innvending her. DORA’s 2026 ROI report beskriver en J-kurve: et produktivitetsfall rett etter adopsjon, drevet av læringskurven, kostnaden ved å verifisere KI-generert kode, og nedstrømsprosesser som ikke har tatt igjen. De kaller det «undervisningskostnaden» ved transformasjon, og advarer ledere mot å forveksle den med feil. Rimelig nok. Men undervisningskostnad og et reelt problem ser identisk ut på et dashbord bygget fra tickets. Hvis du ikke kan se hvilken du er i, er du ikke tålmodig. Du gjetter.

Vi må gå tilbake til det grunnleggende. Kjenn deg selv. Kjenn teamet ditt. Kjenn hvilke problemer du løser. 

Hvordan «Kjenn deg selv» med KI?

Fra samtalene mine har jeg identifisert fem hovedområder hvor konvensjonelle systemer, bygget for menneskegenerert, menneskelig rapportert arbeid, er blinde. Ignorerer du dem, risikerer du å forsterke svakhetene dine mens du fortsetter å ta i bruk KI.

Blindspot 1: Hastighetsteater

Flere commits og flere PR-er kan føles som fremgang, og ofte er det det. KI øker begge tallene automatisk. En Stanford case study viste at adopsjon av KI økte PR-antallet med 14 %. Men det du går glipp av, er hvor mye av den aktiviteten som er funksjonsarbeid som leveres versus vedlikehold, omarbeiding eller rotasjon fra en refaktorering som ikke holdt.

For å håndtere dette, følg oppdelingen mellom funksjonsarbeid og vedlikehold, og følg distribusjonsfrekvens og ledetid mot din egen historiske referanse, ikke et bransjegjennomsnitt. Uten den oppdelingen rapporterer du fremgang du ikke faktisk kan underbygge.

Blindspot 2: Gjennomgangsgjeld

Gjennomgangskapasiteten skalerer ikke automatisk sammen med produksjonen. Verifiseringsavgiften er ikke en fase du kommer deg gjennom; den er en del av de faste kostnadene ved agentisk utvikling. En En nylig undersøkelse av ingeniørledere fant 80 % av teamene at de bruker minst 10 % av tiden på gjennomgang, og omtrent én av ti bruker mer enn 40 %. Under den belastningen veksler teamene mellom en voksende etterslep og blind godkjenning, og ingen av delene er en reell løsning.

Begrensningen på leveranser er ikke lenger hvor raskt kode blir skrevet. Det er hvor raskt et menneske faktisk kan være sikker på at en endring er korrekt, hvor raskt og nøyaktig feil kan oppdages og håndteres. Følg med på hvordan gjennomgangsbelastningen faktisk fordeles på teamet ditt; ellers risikerer du å overbelaste senioringeniørene, forsinke utgivelsene, eller forårsake store produksjonsproblemer.

Blind Spot 3: Skjult arbeid

Refaktoreringer og arkitekturskift har en tendens til å skjule seg i andre tickets, hvis de i det hele tatt dukker opp i ticketsystemet. KI produserer mer av denne typen arbeid, ikke mindre. En agent nøler ikke med å berøre tolv filer for å fikse en feil, mens et menneske kanskje stopper opp og revurderer. Arbeid som hopper over registreringssystemet hopper også over planlegging, noe som betyr at kapasitetsmodellen din er feil, og alle prognoser bygget på den er også feil.

For å forstå hvor mye arbeid som faktisk blir gjort, må du følge med på hvor mye som faktisk endres i kodebasen og i pull request-historikken. Uten det er kapasitetsplanen din bygget på det folk husket å logge, ikke på det de faktisk gjorde.

Blind Spot 4: Kvalitetsdrift

Den samme undersøkelsen fant at nesten halvparten av ingeniørledere sliter med å oppdage sikkerhetsproblemer uke for uke. Kompleksitet, duplisering og avhengigheter som ikke helt hører hjemme bygger seg opp over mange små, hver for seg rimelige endringer. Ingen av dem virker alarmerende alene. I den samme Stanford‑studien falt kodekvaliteten med 9 % og variansen mer enn tredoblet. Mens gjennomsnittet endret seg litt, økte spredningen (det du legger merke til) betydelig. Ved AI‑volum forsterkes de raskere enn de fleste gjennomgangsprosesser klarer å fange dem. Driften viser seg ofte som en varsel i beredskap som spores tilbake til en avhengighet ingen husker å ha gjennomgått. Når dette skjer, er det en god sjanse for at en kunde har lagt merke til det først.

Følg med på trendlinjene for sikkerhetsfunn, avhengigheter og feil og gjenoppretting – ikke på den enkelte commit. Kompleksitet og duplisering som bygger seg opp over flere uker er viktigere enn enhver enkelt endring som blir flagget i gjennomgangen. Uten dette oppdager du drift på samme måte som de fleste team fortsatt gjør: etter at den allerede har forårsaket en hendelse.

Blind Spot 5: Ubevist forbruk

Når AI‑adopsjon slutter å være en debatt, blir AI‑forbruk og avkastning på investeringen (ROI) spørsmålet alle fokuserer på. Økonomi vil vite hva som er kapitaliserbart versus operasjonelt. Ledelsen vil vite hva investeringen har resultert i. De fleste team tar fortsatt beslutninger om verktøy, lisenser og bemanning basert på intuisjon, ikke på bevis for sammenhengen mellom penger og levert arbeid.

Følg med på hvor ingeniørinnsatsen faktisk flyter i selve kodebasen, kvartal for kvartal – ikke hvor veikartet sier den skal flyte. Uten den koblingen forsvarer du neste års budsjett med anekdoter, og anekdoter holder ikke i en hard samtale med en økonomidirektør (CFO).

Start med det du ikke kan se

Finansspørsmålet om kapitalisert forbruk og en beredskapsside kl. 02.00 ser urelatert ut, men er det ikke. Begge kan «gjettes» ut fra aktivitet. Men begge kan faktisk besvares, med bevis, fra selve koden.

DORAs svar på alt dette er selve ingeniørsystemet: plattformkvalitet, arbeidsflytklarhet, teamjustering. Det er riktig, men det er heller ikke første steg. Du kan ikke fikse et system du ikke kan se. Hvert av disse fem områdene er noe du må kunne observere før du kan argumentere for å investere i det.

Det første nyttige steget er ikke et nytt verktøy eller en ny prosess. Det er å kjenne seg selv, ærlig, og å fastslå hvilke av disse fem områdene som er blindsoner hvor du mangler reelle bevis. De fleste ledere kan umiddelbart identifisere (og er oppmerksomme på) problemer i ett av disse områdene. Imidlertid er det områdene du har minst informasjon om som mest sannsynlig vil dukke opp og bite deg når du fortsetter å adoptere KI.