Hvorfor AI i agil softwarelevering fejler: Eksempler og løsninger til Engineering Managers

Mange CTO’er forventer sig meget af brugen af AI i agil softwarelevering: Mere hastighed, mere automatisering, mere output. Det er ofte sandt på kort sigt. Og alligevel fejler mange teams og CTO’er i at bevise, hvordan denne lokale acceleration oversættes til kundeværdi og merværdi for forretningen.

Problemet er, at virksomheder i deres AI-entusiasme optimerer de forkerte ting: Flere tokens i stedet for mere kundeværdi, mere kode i stedet for mere tillid, flere agenter i stedet for bedre leveringssystemer.

Denne artikel bygger bevidst videre på vores to andre indlæg:

• AI i agil softwareudvikling: Status på forskningen 2026 .
• Guide til CTO’er og Engineering Managers om AI-understøttet softwareudvikling .

Her handler det om broen derimellem: Hvorfor fejler AI i agil softwarelevering i praksis? Eksemplerne vil konkret vise, hvad ledere kan gøre, og hvilke løsninger der virkelig holder.

Hvorfor AI i agil softwarelevering så ofte optimerer mod det forkerte mål

Så snart AI introduceres som en produktivitetshævstang, sker der noget meget forudsigeligt i mange virksomheder: Det målbare bliver målet. Dette afspejles i den nye trend Tokenmaxxing. Pragmatic Engineer om trenden Tokenmaxxing

Hermed menes, at virksomheder eller teams implicit eller eksplicit behandler et højt tokenforbrug som et tegn på god AI-brug. Det er både forretningsmæssigt og organisatorisk farligt. For tokens er i højden et input-mål, men ikke et mål for værdi.

Mønsteret er gammelt. Tidligere blev “Lines of Code” overvurderet som metrik, i dag er det så tokenforbrug eller dashboards til AI-brug. I begge tilfælde gælder en variant af Goodhart’s Law: Så snart en metrik bliver målet, mister den sin værdi som metrik. Martin Fowler om Lines of Code som metrikproblem, Wikipedia om Goodhart’s Law

For AI i agil softwarelevering betyder det: Den, der maksimerer kortsigtet aktivitet, får ofte mere AI-aktivitet. Men ikke automatisk bedre agil softwarelevering.

Forskningen på området er nøgtern: På individuelt niveau ser man allerede tydelige produktivitetseffekter, men på team- og organisationsniveau er der derimod betydeligt færre holdbare forbedringer. Detaljerne om dette har vi opsummeret her: Om studielandskabet 2026 vedrørende AI i agil softwareudvikling

Fire typiske eksempler på, hvordan AI fejler i agil softwarelevering

Det første nederlag er banalt: Teams producerer betydeligt flere ændringer, men forstår en faldende andel af dem rigtigt.

For ledere ser det ofte godt ud i starten:

• flere Pull Requests
• hurtigere første implementeringer
• flere stories “færdige”

Regningen kommer senere:

• Reviews bliver mere overfladiske
• Ejerskab udvandes
• Incident-analyse tager længere tid
• Refactorings undgås, fordi ingen længere er sikre på, hvad der kan gå i stykker hvor

Kent Beck beskriver i sin artikel “Trust Factory”, at praksisser som test, reviews, refactoring og inkrementel levering primært opbygger tillid. Netop denne tillid forsvinder, når AI producerer hurtigere, end teamet kan forstå, kontrollere og tage ansvar for. Kent Beck i Trust Factory om tillid i engineering

Addy Osmani beskriver en lignende risiko som Comprehension Debt: Når teams leverer mere og mere kode, som de ikke længere aktivt gennemtrænger, vokser afstanden mellem system og forståelse for hver ændring. Addy Osmani om Comprehension Debt

Dette stemmer også overens med bredere erfaringer fra praksis: Ifølge en Sonar-undersøgelse opsummeret i 2026 stoler de fleste udviklere ikke fuldt ud på den funktionelle korrekthed af AI-genereret kode, og en betydelig del oplever endda review af denne som mere krævende end at kontrollere menneskeskabte ændringer. Problemet er altså ikke kun dårlig kvalitet, men yderligere verifikations- og forståelsesomkostninger. ITPro om Sonar-undersøgelsen vedrørende Verification Debt

Det andet fejltrin er endnu dyrere for ledere: AI sænker omkostningerne ved at producere, men ikke automatisk omkostningerne ved at tage fejl.

Når teams krav er dårligt skåret til, utilstrækkeligt valideret eller kun internt afstemt, fremskynder AI bare det forkerte arbejde. Kelsey Hightower får det sagt meget direkte i sit LinkedIn-opslag: “Productivity doesn’t matter if you’re working on the wrong thing.” LinkedIn-opslag af Kelsey Hightower om falsk produktivitet

Andrew Ng argumenterer også i samme retning i en meget citeret samtale fra 2025: AI har accelereret coding markant, men dermed flytter den egentlige flaskehals sig. Ikke implementeringen er nu hovedproblemet, men produktspørgsmålet:

Hvad burde vi overhovedet bygge, og hvor hurtigt lærer vi af reel brugerfeedback?

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

Det er grunden til, at AI i agil softwareleverance kun kan lykkes med reel kundetæthed. Når vejen fra prompt til kode bliver hurtigere, men vejen fra kode til kunde-feedback forbliver langsom, stiger kun output og mængden af ændringer.

Også forskning i agil produktudvikling peger på præcis dette mønster på et andet niveau: I et industry case study om Agile Epics beskriver forskere, at dårligt definerede krav fører til churn, forsinkelser, kvalitetsproblemer og unødvendige omkostninger. AI kan ikke magisk opløse sådanne flaskehalse. Den kan højst materialisere dem hurtigere. ArXiv-studie om Agile Epics og kravkvalitet

Derfor er den afgørende modpol til blind AI-anvendelse ikke mindre AI, men bedre agil levering. Den, der leder efter de overordnede greb til det, finder dem her: Vejledning til fremtiden for AI-understøttet agil softwareudvikling

Mange fremtidsbilleder af AI i agil softwareleverance virker attraktive, fordi de gør ansvar elegant usynligt: En agent analyserer brugerfeedback, den næste skriver requirements, den næste implementerer, den næste tester, og den næste deployer.

Teknisk er en del af det muligt. Organisatorisk bliver det hurtigt diffust.

Netop i agentisk softwareudvikling må det gamle ledelsesspørgsmål derfor stilles endnu skarpere: Hvem beslutter? Hvem kontrollerer? Hvem bærer konsekvenserne? IBM formulerer kernespørgsmålet i en læseværdig oversigt over AI decision-making: Ansvar forbliver hos mennesket, især når systemer forbereder eller fremskynder beslutninger. IBM om ansvar ved AI decision-making

Også AI Agile Manifesto sætter her den rigtige kontrast: Mere maskinel intelligens uden menneskelig dømmekraft er ikke fremskridt, men en fejlslutning. AI Agile Manifesto i original

Derfor er det ikke nok kun at tale om værktøjsfunktioner. Så snart agenter fortolker krav, gennemfører ændringer eller endda udløser produktionsnære handlinger, må ansvar gøres organisatorisk klarere og mere synligt.

Det fjerde fejltrin bliver ofte først synligt med forsinkelse: Enkelte udviklere eller teams fremstår ekstremt produktive, mens hele organisationen bliver mere træg.

Det sker, når alle lokalt optimerer med AI, men næsten ingen styrker det samlede system:

• Arkitekturprincipper anvendes inkonsistent
• de samme problemer løses flere gange parallelt
• review- og testsystemer bliver overkørt
• delivery-pipelines bliver til flaskehalse
• incidentbelastning og efterarbejde stiger

Birgitta Böckeler beskriver i sin InfoQ-samtale om Harness Engineering, hvorfor større autonomi altid også medfører større risici og må begrænses gennem passende feedforward- og feedback-mekanismer. InfoQ-podcast med Birgitta Böckeler om Harness Engineering

At det ikke er en teoretisk risiko, viser flere offentligt kendte tilfælde. Amazon skærpede ifølge rapporter i 2026 sine interne guardrails efter alvorlige serier af incidents, hvor også agentiske eller AI-nære systemer blev nævnt som medvirkende faktor. Læringen var sigende: Flere dokumenterede ændringer, flere godkendelser, mere “controlled friction” i kritiske systemer. Med andre ord: Ikke enhver lokal acceleration forbedrer helhedssystemet. Nogle gange gør den blot dets svagheder hurtigere synlige. Business-Insider-rapport om Amazons skærpede AI-guardrails

En anden, anderledes form af den samme entropi ser man ved AI-understøttet såkaldt Vibe Coding. Axios rapporterede i 2026 med henvisning til sikkerhedsforskere om hundredtusinder af offentligt tilgængelige artefakter, herunder tusindvis med følsomme virksomhedsdata. Her fejler ikke primært en enkelt prompt, men hele systemet bestående af standarder, adgang, defaults, sikkerhedsforståelse og governance. Axios-rapport om Vibe Coding og offentligt tilgængelige artefakter

Kort sagt: Jo mere autonom AI’en er, desto vigtigere er den organisatoriske og tekniske ramme, den arbejder i.

Hvorfor kortsigtet produktivitet og tokenmaxxing er den forkerte AI-strategi

Nogle ledere reagerer på AI’s nye løftestangseffekt med en enkel slutning: Så må vi bare tvinge så meget AI-anvendelse igennem så hurtigt som muligt.

Det er præcis den forkerte ledelsesreaktion.

Hvorfor?

Fordi “kortsigtet produktivitet” i denne kontekst som regel kun betyder følgende:

• mere genereret kode
• flere AI-sessioner
• mere tokenforbrug
• flere opgaver løst lokalt

Men alt det siger stadig næsten intet om de spørgsmål, der for AI i agil softwareleverance faktisk er afgørende:

• Blev det rigtige problem løst?
• Forstår teamet ændringen?
• Kan ændringen rulles sikkert ud?
• Er systemet efter ændringen bedre eller mere skrøbeligt?
• Lærer organisationen hurtigere eller bare mere hektisk?

Netop derfor er Tokenmaxxing et så godt advarselssignal. Det viser, hvad der sker, når virksomheder behandler brugen af AI som et mål i sig selv. Så maksimerer medarbejdere præcis det, der belønnes synligt, selv hvis det øger omkostninger, entropi og blindflyvning. Pragmatic Engineer om tendensen Tokenmaxxing

Jez Humble har længe før den aktuelle AI-bølge beskrevet dette ledelsesproblem helt præcist: Når ledere fokuserer direkte på produktivitet, bliver langsigtede forbedringer ofte netop ikke gennemført. For AI i agil software delivery gælder det i skærpet grad. Jez Humble om fokus på produktivitet og manglende langsigtede forbedringer

Hvad der i stedet virker: Fire robuste løsninger for AI i agil software delivery

1. Behold ansvaret eksplicit hos mennesker

AI må gerne accelerere, foreslå og aflaste. Men den må ikke blive en undskyldning for, at beslutnings- og kvalitetsansvaret udviskes.

Praktisk betyder det:

• klare ejere for arkitektur, sikkerhed og produktrelevante beslutninger
• ingen succeskriterier, der bare belønner AI-aktivitet
• eksplicitte review- og godkendelsesregler for AI-genererede ændringer

2. Opbyg et engineering-harness i stedet for kun AI-værktøjer

Mange teams investerer først i modeller og sidst i de betingelser, hvorunder disse modeller kan arbejde sikkert. Det skal vendes om.

Et robust harness for AI i agil softwareleverance omfatter for eksempel:

• gode specifikationer
• små, verificerbare arbejdspakker
• automatiske tests
• statisk analyse
• kontrollerede sandkasser
• klare arkitekturkontekster
• hurtig feedback fra CI, levering og produktion

Hvis du er interesseret i den tanke, er OpenSpec og GitHub Spec Kit også nyttige referencer til emnet specifikationsdrevet arbejde med AI: OpenSpec til specifikationsdrevet produktudvikling, GitHub Spec Kit til spec-driven udvikling

3. Gør kundefeedback hurtigere end kodeproduktion

AI er kun en bæredygtig leverance-løftestang, hvis læringscyklusserne også accelereres. Ellers producerer man bare hurtigere ved siden af virkeligheden.

Det betyder konkret:

• mindre releases
• flere eksperimenter med ægte feedbacksløjfer med kunder
• mere konsekvent analyse af data om featurebrug
• hurtigere analyse af support- og brugersignaler

Den, der kun øger coding-hastigheden, men ikke feedback-hastigheden og -kvaliteten, bygger ikke en AI-native organisation, men blot en hurtigere “Feature Factory”, som John Cutler beskriver det. Se: 12 Signs You’re Working in a Feature Factory

4. Tag retrospektiver og læringssløjfer alvorligt

Når AI fejler i agil softwareleverance, er årsagerne ofte systemiske. Så hjælper det kun lidt at optimere enkelte prompts eller værktøjer.

Teams har brug for rutiner, hvor de synliggør tilbagevendende mønstre og løser dem systematisk:

• Hvor mister vi forståelsen?
• Hvor vokser review-efterslæbet?
• Hvor skaber AI mere genarbejde end værdi?
• Hvor optimerer vi lokal hastighed på bekostning af hele systemet?

Netop derfor forbliver retrospektiver relevante. Ikke som et ritual fra Scrum-fortiden, men som en mekanisme til organisatorisk læring i et miljø med højere ændringsfrekvens.

Konklusion: AI i agil softwareleverance fejler sjældent på for lidt AI

Den egentlige ironi er: Mange organisationer fejler ikke med AI, fordi de er for forsigtige, men fordi de styrer for kortsigtet.

De forveksler kortsigtet produktivitet med bæredygtig værdiskabelse og forbedring af leverancesystemet. De forveksler tokenforbrug med værdiskabelse. De forveksler autonom kodegenerering med organisatorisk modenhed.

Det bedre styringsspørgsmål er derfor ikke: “Hvordan får vi vores teams til at bruge endnu mere AI?”

Men snarere:

• Under hvilke betingelser forbedrer AI virkelig vores leverance?
• Hvor skaber AI lige nu nye flaskehalse i værdikæden?
• Hvor afslører AI systemiske mangler, som vi må udbedre?
• Hvilke organisatoriske evner skal vi styrke, så acceleration ikke tipper over i entropi?

Hvis du først vil have den nøgterne evidens for det, så læs videre her: undersøgelsesgrundlag om KI i agil softwareudvikling .

Hvis du leder direkte efter ledelsesgreb, så gå videre her: Guide for CTO’er og Engineering Managers til AI i agil softwareudvikling .

FAQ om KI i agil softwareleverance

Hvorfor giver AI mit team mere output, men ikke bedre delivery?

Fordi mere output ikke automatisk betyder bedre delivery. Hvis reviews, tests og feedback ikke følger med, stiger især kompleksiteten.

Hvad betyder Tokenmaxxing i AI-understøttet softwareudvikling?

Tokenmaxxing betyder at gøre brug af AI eller tokenforbrug til målet. Det måler aktivitet, men ikke værdi.

Hvad bør Engineering Managers gøre i stedet for bare at presse AI-produktivitet?

De bør styrke ansvar, tests, reviews og feedbacksløjfer. Først det gør AI brugbar på lang sigt.

Har teams med meget AI-understøttelse overhovedet stadig brug for agile ritualer?

Ja, men med et andet fokus. Mindre statuspleje, mere feedback, læring og løbende forbedring.

Hvordan måler jeg som Engineering Manager, om KI i softwareudvikling virkelig giver noget?

Mål lead time, review-indsats, fejlrate og kundeværdi. Ren output er ikke nok.

Hvorfor bliver mit team hurtigere med KI, men resultaterne ikke bedre?

Fordi mere kode ikke automatisk giver bedre resultater. Uden ordentlige reviews, tests og feedback stiger kun entropien.

Hvilke KPI'er bør jeg virkelig tracke for KI i softwareudvikling?

Track gennemløbstid, defect rate, rework, deploymentsikkerhed og tid til kundefeedback. Tokens alene siger for lidt.

Hvordan undgår jeg, at KI-genereret kode bremser mit team senere?

Hold ændringer små, test dem grundigt, og kræv tydelig review. KI må gerne give tempo, men ikke erstatte forståelse.