Hvorfor AI i smidig programvareleveranse feiler: Eksempler og løsninger for Engineering Managers

Mange CTO-er forventer mye av bruken av KI i smidig programvareleveranse: Mer hastighet, mer automatisering, mer output. Dette stemmer ofte på kort sikt. Likevel mislykkes mange team og CTO-er med å bevise hvordan denne lokale akselerasjonen oversettes til kundeverdi og merverdi for virksomheten.

Problemet er at selskaper, i sin KI-entusiasme, optimaliserer feil ting: Flere tokens i stedet for mer kundeverdi, mer kode i stedet for mer tillit, flere agenter i stedet for bedre leveransesystemer.

Denne artikkelen bygger bevisst videre på våre to andre innlegg:

• AI i smidig programvareutvikling: Forskningsstatus 2026 .
• Veiledning for CTO-er og Engineering Managers for AI-støttet programvareutvikling .

Her handler det om broen imellom: Hvorfor mislykkes KI i smidig programvareleveranse i praksis? Eksemplene vil vise konkret hva ledere kan gjøre og hvilke løsninger som faktisk holder mål.

Hvorfor AI i smidig programvareleveranse så ofte optimaliserer for feil mål

Så snart KI introduseres som en produktivitetsvektstang, skjer det noe veldig forutsigbart i mange selskaper: Det målbare blir målet. Dette gjenspeiles i den nye trenden Tokenmaxxing. Pragmatic Engineer om trenden Tokenmaxxing

Med dette menes at selskaper eller team implisitt eller eksplisitt behandler et høyt tokenforbruk som et tegn på god KI-bruk. Dette er farlig både bedriftsøkonomisk og organisatorisk. For tokens er i høyden et mål på innsats, men ikke et mål på verdi.

Mønsteret er gammelt. Tidligere ble “Lines of Code” overvurdert som metrikk, i dag er det tokenforbruk eller dashbord for KI-bruk. I begge tilfeller gjelder en variant av Goodharts lov: Når en metrikk blir et mål, mister den sin verdi som metrikk. Martin Fowler om Lines of Code som metrikkproblem, Wikipedia om Goodharts lov

For KI i smidig programvareleveranse betyr dette: De som maksimerer kortsiktig aktivitet, får ofte mer KI-aktivitet. Men ikke automatisk bedre smidig programvareleveranse.

Forskningsstatusen på dette er nøktern: På individnivå ser man allerede tydelige produktivitetseffekter, men på team- og organisasjonsnivå er det derimot betydelig færre pålitelige forbedringer. Detaljene om dette har vi oppsummert her: Om studielandskapet i 2026 for KI i smidig programvareutvikling

Fire typiske eksempler på hvordan KI mislykkes i smidig programvareleveranse

Det første nederlaget er banalt: Team produserer betydelig flere endringer, men forstår en synkende andel av dem på ordentlig.

For ledere ser dette ofte bra ut i starten:

• flere Pull Requests
• raskere første implementeringer
• flere stories “ferdig”

Regningen kommer senere:

• Anmeldelser blir mer overfladiske
• Eierskap vannes ut
• Incident-analyse tar lengre tid
• Refaktoreringer unngås fordi ingen lenger er sikre på hva som kan gå i stykker hvor

Kent Beck beskriver i sin artikkel “Trust Factory” at praksiser som tester, reviews, refaktorering og inkrementell leveranse først og fremst bygger tillit. Nettopp denne tilliten bryter sammen når KI produserer raskere enn teamet kan forstå, kontrollere og ta ansvar for. Kent Beck i Trust Factory om tillit i engineering

Addy Osmani beskriver en lignende risiko som Comprehension Debt: Når team leverer stadig mer kode som de ikke lenger aktivt gjennomskuer, øker avstanden mellom system og forståelse for hver endring. Addy Osmani om Comprehension Debt

Dette samsvarer også med bredere funn fra praksis: Ifølge en Sonar-undersøkelse oppsummert i 2026, stoler de fleste utviklere ikke fullt ut på den funksjonelle korrektheten til KI-generert kode, og en betydelig andel opplever til og med at review av denne er mer krevende enn å kontrollere endringer skrevet av mennesker. Problemet er altså ikke bare dårlig kvalitet, men ekstra arbeid med verifisering og forståelse. ITPro om Sonar-undersøkelsen om Verification Debt

Det andre mislykket er enda dyrere for ledere: KI reduserer kostnaden ved å produsere, men ikke automatisk kostnaden ved å ta feil.

Når team har dårlig skåret krav, utilstrekkelig validert dem eller bare koordinert dem internt, gjør KI bare det feilaktige arbeidet raskere. Kelsey Hightower setter det veldig direkte i LinkedIn-innlegget sitt: “Productivity doesn’t matter if you’re working on the wrong thing.” LinkedIn-innlegg av Kelsey Hightower om feil produktivitet

Akkurat i denne retningen argumenterer også Andrew Ng i en mye sitert samtale fra 2025: KI hadde gjort koding betydelig raskere, men dermed flytter også den egentlige flaskehalsen seg. Ikke implementeringen er nå hovedproblemet, men produktspørsmålet:

Hva bør vi egentlig bygge, og hvor raskt lærer vi av ekte brukertilbakemelding?

Kilde: Business Insider-samtale med Andrew Ng om flaskehalsen i produktledelse

Dette er grunnen til at KI i agil programvareleveranse bare kan lykkes med reell nærhet til kundene. Når veien fra prompt til kode blir raskere, men veien fra kode til kundetilbakemelding forblir langsom, øker bare output og endringsvolum.

Også forskning fra smidig produktarbeid viser akkurat dette mønsteret på et annet nivå: I en industricasestudie om Agile Epics beskriver forskere at dårlig definerte krav fører til churn, forsinkelser, kvalitetsproblemer og unødvendige kostnader. KI kan ikke magisk løse slike flaskehalser. Den kan høyst materialisere dem raskere. ArXiv-studie om Agile Epics og kravkvalitet

Derfor er det avgjørende motstykket til blind KI-bruk ikke mindre KI, men bedre agil leveranse. Den som leter etter de overordnede grepene for dette, finner dem her: veiviser til fremtiden for KI-støttet smidig programvareutvikling

Mange fremtidsbilder av KI i smidig programvareleveranse virker attraktive fordi de gjør ansvar elegant usynlig: Én agent analyserer tilbakemeldinger fra brukere, den neste skriver krav, den neste implementerer, den neste tester og den neste deployer.

Teknisk er en del av dette mulig. Organisatorisk blir det raskt diffust.

Særlig ved agentisk programvareutvikling må derfor det gamle ledelsesspørsmålet stilles skarpere: Hvem bestemmer? Hvem kontrollerer? Hvem bærer konsekvensene? IBM formulerer grunnproblemet i en lesverdig oversikt over AI decision-making: Ansvar ligger hos mennesket, særlig når systemer forbereder eller fremskynder beslutninger. IBM om ansvar i AI decision-making

Også AI Agile Manifesto setter her den riktige motvekten: Mer maskinell intelligens uten menneskelig dømmekraft er ikke framgang, men en feil retning. AI Agile Manifesto i original

Derfor er det ikke nok å bare snakke om verktøyevner. Så snart agenter tolker krav, gjennomfører endringer eller til og med utløser produksjonsnære handlinger, må ansvar bli tydeligere og mer synlig organisatorisk.

Det fjerde mislykket blir ofte først synlig med forsinkelse: Enkelte utviklere eller team virker ekstremt produktive, mens hele organisasjonen blir tregere.

Det skjer når alle optimaliserer lokalt med KI, men nesten ingen styrker helheten:

• Arkitekturprinsipper blir anvendt inkonsekvent
• de samme problemene blir løst flere ganger parallelt
• Review- og testsystemer blir overkjørt
• Leveransepipelines blir til flaskehalser
• Incident-belastning og etterarbeid øker

Birgitta Böckeler beskriver i sin InfoQ-samtale om Harness Engineering hvorfor høyere autonomi alltid også innebærer høyere risiko og må begrenses gjennom egnede feedforward- og feedback-mekanismer. InfoQ-podcast med Birgitta Böckeler om Harness Engineering

At dette ikke er en teoretisk risiko, viser flere saker som har blitt kjent offentlig. Ifølge rapporter strammet Amazon i 2026 inn sine interne guardrails etter alvorlige incident-serier, der også agentiske eller KI-nære systemer ble nevnt som medvirkende faktorer. Lærdommen var talende: Flere dokumenterte endringer, flere godkjenninger, mer “controlled friction” i kritiske systemer. Med andre ord: Ikke hver lokal akselerasjon forbedrer helhetssystemet. Noen ganger gjør den bare svakhetene mer synlige, raskere. Business-Insider-rapport om Amazons innstrammede KI-guardrails

En annen, annen form for den samme entropien ser man ved KI-støttet såkalt Vibe Coding. Axios rapporterte i 2026, med henvisning til sikkerhetsforskere, om hundretusenvis av offentlig tilgjengelige artefakter, deriblant tusenvis med sensitive bedriftsdata. Her er det ikke først og fremst en enkelt prompt som feiler, men helhetssystemet av standarder, tilganger, defaults, sikkerhetsforståelse og governance. Axios-rapport om Vibe Coding og offentlig tilgjengelige artefakter

Kort sagt: Jo mer autonom KI-en er, desto viktigere er den organisatoriske og tekniske rammen den arbeider innenfor.

Hvorfor kortsiktig produktivitet og tokenmaxxing er den feil KI-strategien

Noen ledere reagerer på KI sin nye innflytelse med en enkel konklusjon: Da må vi bare tvinge fram så mye KI-bruk som mulig, så raskt som mulig.

Det er akkurat den feilaktige lederreaksjonen.

Hvorfor?

Fordi “short term productivity” i denne konteksten som regel bare betyr følgende:

• mer generert kode
• flere AI-økter
• mer tokenforbruk
• flere oppgaver løst lokalt

Men alt dette sier fortsatt nesten ingenting om de spørsmålene som faktisk er avgjørende for KI i smidig programvareleveranse:

• Ble det riktige problemet løst?
• Forstår teamet endringen?
• Kan endringen rulles ut på en trygg måte?
• Er systemet bedre eller mer skjørt etter endringen?
• Lærer organisasjonen raskere, eller bare mer hektisk?

Akkurat derfor er Tokenmaxxing et så godt varselsignal. Det viser hva som skjer når bedrifter behandler KI-bruk som et mål i seg selv. Da maksimerer ansatte akkurat det som blir synlig belønnet, selv om det øker kostnader, entropi og blinde flekker. Pragmatic Engineer om trenden Tokenmaxxing

Jez Humble beskrev dette lederproblemet tydelig lenge før den nåværende KI-bølgen: Når ledere fokuserer direkte på produktivitet, blir langsiktige forbedringer ofte nettopp ikke gjort. For KI i smidig software delivery gjelder dette forsterket. Jez Humble om produktivitetsfokus og manglende langsiktige forbedringer

Det som derimot fungerer: Fire robuste løsninger for KI i smidig software delivery

1. Hold ansvaret eksplisitt hos mennesket

KI kan bidra til å fremskynde, foreslå og avlaste. Men den må ikke bli en unnskyldning for at ansvaret for beslutninger og kvalitet blir uklart.

Praktisk betyr det:

• tydelige eiere for arkitektur, sikkerhet og produktrelevante beslutninger
• ingen suksessmetrikker som bare belønner AI-aktivitet
• eksplisitte gjennomgangs- og godkjenningsregler for KI-genererte endringer

2. Bygg en engineering-harness, ikke bare KI-verktøy

Mange team investerer først i modeller og sist i betingelsene som gjør at disse modellene kan arbeide trygt. Nettopp det må snus på hodet.

Et robust harness for KI i smidig programvareleveranse omfatter for eksempel:

• gode spesifikasjoner
• små, verifiserbare arbeidspakker
• automatiske tester
• statisk analyse
• kontrollerte sandkasser
• tydelige arkitekturkontekster
• rask tilbakemelding fra CI, leveranse og produksjon

Hvis du synes denne tanken er interessant, er også OpenSpec og GitHub Spec Kit nyttige referanser til spesifikasjonsdrevet arbeid med KI: OpenSpec for spesifikasjonsdrevet produktutvikling, GitHub Spec Kit for spec-driven utvikling

3. Gjør kundetilbakemeldinger raskere enn kodeproduksjon

KI er bare en bærekraftig leveransehebel hvis læringssyklusene også går raskere. Ellers produserer man bare raskere forbi virkeligheten.

Det betyr konkret:

• mindre releaser
• flere eksperimenter med ekte tilbakemeldingssløyfer med kunder
• mer konsekvent analyse av data om funksjonsbruk
• raskere evaluering av støtte- og brukersignaler

Den som bare øker kodingshastigheten, men ikke tilbakemeldingshastigheten og -kvaliteten, bygger ikke en AI-native organisasjon, men bare en raskere “Feature Factory”, slik John Cutler beskriver det. Se: 12 tegn på at du jobber i en Feature Factory

4. Ta retrospektiver og læringssløyfer på alvor

Når KI i smidig programvareleveranse mislykkes, er årsakene ofte systemiske. Da hjelper det lite å bare optimalisere enkeltstående prompts eller verktøy.

Team trenger rutiner der de synliggjør tilbakevendende mønstre og løser dem systematisk:

• Hvor mister vi forståelse?
• Hvor vokser review-køen?
• Hvor skaper KI mer etterarbeid enn nytte?
• Hvor optimaliserer vi lokal hastighet på bekostning av hele systemet?

Nettopp derfor forblir retrospektiver relevante. Ikke som et ritual fra Scrum-fortiden, men som en mekanisme for organisatorisk læring i et miljø med høyere endringsfrekvens.

Konklusjon: KI i smidig programvareleveranse feiler sjelden på grunn av for lite KI

Den egentlige ironien er: Mange organisasjoner mislykkes med KI ikke fordi de er for forsiktige, men fordi de styrer for kortsiktig.

De forveksler kortsiktig produktivitet med bærekraftig verdiskaping og forbedring av leveringssystemet. De forveksler tokenforbruk med verdiskaping. De forveksler autonom kodegenerering med organisatorisk modenhet.

Det bedre styringsspørsmålet er derfor ikke: “Hvordan får vi teamene våre til å bruke enda mer KI?”

Men heller:

• Under hvilke betingelser forbedrer KI faktisk leveransen vår?
• Hvor skaper KI akkurat nå nye flaskehalser i verdikjeden?
• Hvor avdekker KI systemiske mangler som vi må rette opp?
• Hvilke organisatoriske evner må vi styrke, slik at akselerasjon ikke tipper over i entropi?

Hvis du først vil ha den nøkterne evidensen for dette, les videre her: studier om KI i smidig programvareutvikling .

Hvis du leter direkte etter ledergrep, gå videre her: Veiledning for CTO-er og engineering-ledere om KI i smidig programvareutvikling .

FAQ om KI i smidig software delivery

Hvorfor gir KI teamet mitt mer output, men ikke bedre delivery?

Fordi mer output ikke automatisk betyr bedre delivery. Hvis reviews, tester og tilbakemeldinger ikke holder tritt, øker først og fremst kompleksiteten.

Hva betyr Tokenmaxxing i KI-støttet programvareutvikling?

Tokenmaxxing betyr å gjøre KI-bruk eller tokenforbruk til målet. Det måler aktivitet, men ikke verdi.

Hva bør engineering-ledere gjøre, i stedet for bare å pushe KI-produktivitet?

De bør styrke ansvar, tester, reviews og tilbakemeldingssløyfer. Først da blir KI nyttig på lang sikt.

Trenger team med mye KI-støtte i det hele tatt fortsatt agile ritualer?

Ja, men med et annet fokus. Mindre statusrapportering, mer tilbakemelding, læring og kontinuerlig forbedring.

Hvordan måler jeg som engineering manager om KI virkelig gir noe i programvareutvikling?

Mål lead time, review-innsats, feilrate og kundeverdi. Ren output er ikke nok.

Hvorfor blir teamet mitt raskere med KI, men resultatene ikke bedre?

Fordi mer kode ikke automatisk gir bedre resultater. Uten grundige reviews, tester og tilbakemeldinger øker bare entropien.

Hvilke KPI-er bør jeg egentlig følge med på for KI i programvareutvikling?

Følg med på gjennomløpstid, defektrate, rework, deploy-sikkerhet og tid til kundetilbakemelding. Tokens alene sier for lite.

Hvordan hindrer jeg at KI-generert kode bremser teamet mitt senere?

Hold endringene små, test dem skikkelig og krev tydelig review. KI kan gi fart, men ikke erstatte forståelse.