Waarom AI in agile software delivery faalt: voorbeelden en oplossingen voor engineering managers

Veel CTO’s verwachten veel van het gebruik van AI in agile softwaredelivery: meer snelheid, meer automatisering, meer output. Dat klopt vaak op korte termijn. En toch slagen veel teams en CTO’s er niet in aan te tonen hoe deze lokale versnelling zich vertaalt naar klantwaarde en toegevoegde waarde voor het bedrijf.

Het probleem is dat bedrijven in het AI-enthousiasme de verkeerde dingen optimaliseren: meer tokens in plaats van meer klantwaarde, meer code in plaats van meer vertrouwen, meer agents in plaats van betere deliveriesystemen.

Dit artikel sluit bewust aan op onze twee andere bijdragen:

• AI in agile softwareontwikkeling: stand van zaken 2026 .
• Gids voor CTO’s en engineering managers voor AI-gestuurde softwareontwikkeling .

Hier gaat het om de brug daartussen: waarom faalt AI in agile softwaredelivery in de praktijk? De voorbeelden zullen concreet laten zien wat managers kunnen doen en welke oplossingen echt standhouden.

Waarom AI in agile software delivery zo vaak op het verkeerde doel optimaliseert

Zodra AI als productiviteitshefboom wordt geïntroduceerd, gebeurt er in veel bedrijven iets heel voorspelbaars: het meetbare wordt het doel. Dat weerspiegelt zich in de nieuwe trend tokenmaxxing. Pragmatic Engineer over de trend tokenmaxxing

Daarmee wordt bedoeld dat bedrijven of teams een hoog tokenverbruik impliciet of expliciet behandelen als een teken van goed AI-gebruik. Dat is bedrijfseconomisch en organisatorisch gevaarlijk. Want tokens zijn hooguit een inputmaatstaf, maar geen waardemaatstaf.

Het patroon is oud. Vroeger werden “Lines of Code” als metriek overschat, vandaag dus tokenverbruik of dashboards voor AI-gebruik. In beide gevallen geldt een variant van Goodhart’s Law: zodra een metriek een doel wordt, verliest ze haar waarde als metriek. Martin Fowler over Lines of Code als metriekprobleem, Wikipedia over Goodhart’s Law

Voor AI in agile softwaredelivery betekent dat: wie kortetermijnactiviteit maximaliseert, krijgt vaak meer AI-activiteit. Maar niet automatisch betere agile softwaredelivery.

De onderzoeksresultaten hierover zijn ontnuchterend: op individueel niveau zie je al duidelijke productiviteitseffecten, maar op team- en organisatieniveau zijn er aanzienlijk minder betrouwbare verbeteringen. De details daarover hebben we hier samengevat: Naar de stand van zaken in 2026 over AI in agile softwareontwikkeling

Vier typische voorbeelden van hoe AI faalt in agile softwaredelivery

De eerste vorm van falen is banaal: teams produceren aanzienlijk meer wijzigingen, maar begrijpen een steeds kleiner deel daarvan echt.

Voor managers ziet dat er in het begin vaak goed uit:

• meer pull requests
• snellere eerste implementaties
• meer story’s “klaar”

De rekening komt later:

• reviews worden oppervlakkiger
• ownership verwatert
• incident-analyse duurt langer
• refactorings worden vermeden omdat niemand meer zeker weet wat waar kapot zou kunnen gaan

Kent Beck beschrijft in zijn artikel “Trust Factory” dat praktijken zoals tests, reviews, refactoring en incrementele levering vooral vertrouwen opbouwen. Precies dat vertrouwen verdwijnt wanneer AI sneller produceert dan het team kan begrijpen, controleren en verantwoorden. Kent Beck in Trust Factory over vertrouwen in engineering

Addy Osmani beschrijft een vergelijkbaar risico als Comprehension Debt: wanneer teams steeds meer code opleveren die ze niet meer actief doorgronden, groeit met elke wijziging de afstand tussen systeem en begrip. Addy Osmani over Comprehension Debt

Dat sluit ook aan bij bredere bevindingen uit de praktijk: volgens een in 2026 samengevat Sonar-onderzoek vertrouwen de meeste ontwikkelaars de functionele correctheid van door AI gegenereerde code niet volledig, en ervaart een aanzienlijk deel het reviewen ervan zelfs als tijdrovender dan het controleren van door mensen geschreven wijzigingen. Het probleem is dus niet alleen slechte kwaliteit, maar extra verificatie- en begripsinspanning. ITPro over het Sonar-onderzoek naar verification debt

De tweede mislukking is voor leidinggevenden nog duurder: AI verlaagt de kosten van produceren, maar niet automatisch de kosten van fouten.

Als teams eisen slecht hebben gesneden, onvoldoende gevalideerd of alleen intern hebben afgestemd, versnelt AI simpelweg het verkeerde werk. Kelsey Hightower vat dat in zijn LinkedIn-post heel direct samen: “Productivity doesn’t matter if you’re working on the wrong thing.” LinkedIn-post van Kelsey Hightower over verkeerde productiviteit

Precies in die richting redeneert ook Andrew Ng in een veel geciteerd gesprek uit 2025: AI heeft coderen sterk versneld, maar daardoor verschuift het echte knelpunt. Niet de uitvoering is nu het hoofdprobleem, maar de productvraag:

Wat moeten we eigenlijk bouwen, en hoe snel leren we van echte gebruikersfeedback?

Bron: Business-Insider-gesprek met Andrew Ng over het knelpunt in productmanagement

Dat is de reden waarom AI in agile software delivery alleen succesvol kan zijn met echte klantnabijheid. Als de weg van prompt naar code sneller wordt, maar de weg van code naar klantfeedback langzaam blijft, nemen alleen output en wijzigingsvolume toe.

Ook onderzoek uit agile productontwikkeling laat precies dit patroon op een ander niveau zien: in een industry-case study over Agile Epics beschrijven onderzoekers dat slecht gedefinieerde eisen leiden tot churn, vertragingen, kwaliteitsproblemen en onnodige kosten. AI kan zulke knelpunten niet magisch oplossen. Ze kan ze hoogstens sneller zichtbaar maken. ArXiv-studie over Agile Epics en eisenkwaliteit

Daarom is het beslissende tegenwicht tegen blind AI-gebruik niet minder AI, maar betere agile delivery. Wie de overkoepelende hefbomen daarvoor zoekt, vindt ze hier: Gids voor de toekomst van AI-ondersteunde agile softwareontwikkeling

Veel toekomstbeelden over AI in agile software delivery ogen aantrekkelijk omdat ze verantwoordelijkheid elegant onzichtbaar maken: de ene agent analyseert gebruikersfeedback, de volgende schrijft requirements, de volgende implementeert, de volgende test en de volgende deployed.

Technisch is daarvan veel mogelijk. Organisatorisch wordt het al snel diffuus.

Juist bij agentische softwareontwikkeling moet daarom de oude managementvraag strenger worden gesteld: Wie beslist? Wie controleert? Wie draagt de consequenties? IBM formuleert het kernprobleem in een leeswaardig overzicht over AI decision-making: verantwoordelijkheid blijft bij de mens, juist wanneer systemen beslissingen voorbereiden of versnellen. IBM over verantwoordelijkheid bij AI decision-making

Ook het AI Agile Manifesto zet hier het juiste contrapunt: meer machine-intelligentie zonder menselijk beoordelingsvermogen is geen vooruitgang, maar een verkeerde weg. AI Agile Manifesto in het origineel

Daarom is het niet genoeg om alleen over toolmogelijkheden te praten. Zodra agents eisen interpreteren, wijzigingen doorvoeren of zelfs productie-nabije acties uitlokken, moet verantwoordelijkheid organisatorisch duidelijker en zichtbaarder worden.

De vierde mislukking wordt vaak pas met vertraging zichtbaar: individuele ontwikkelaars of teams lijken extreem productief, terwijl de hele organisatie stroever wordt.

Dat gebeurt wanneer iedereen lokaal met AI optimaliseert, maar bijna niemand het totale systeem versterkt:

• Architectuurprincipes worden inconsistent toegepast
• dezelfde problemen worden parallel meerdere keren opgelost
• review- en testsystemen worden overbelast
• delivery-pipelines worden een knelpunt
• incidentlast en nazorg nemen toe

Birgitta Böckeler beschrijft in haar InfoQ-gesprek over Harness Engineering waarom meer autonomie altijd ook meer risico’s met zich meebrengt en door geschikte feedforward- en feedbackmechanismen moet worden begrensd. InfoQ-podcast met Birgitta Böckeler over Harness Engineering

Dat dit geen theoretisch risico is, blijkt uit meerdere openbaar geworden gevallen. Amazon verscherpte volgens berichten in 2026 zijn interne guardrails na ernstige incidentreeksen, waarbij ook agentische of AI-nabije systemen als medefactor werden genoemd. De les daaruit was veelzeggend: meer gedocumenteerde wijzigingen, meer goedkeuringen, meer “controlled friction” in kritieke systemen. Met andere woorden: niet elke lokale versnelling verbetert het totale systeem. Soms maakt ze alleen de zwakke plekken sneller zichtbaar. Business-Insider-bericht over Amazons verscherpte AI-guardrails

Een tweede, andere vorm van dezelfde entropie zie je bij AI-ondersteund zogenoemd Vibe Coding. Axios berichtte in 2026, onder verwijzing naar beveiligingsonderzoekers, over honderdduizenden openbaar toegankelijke artefacten, waaronder duizenden met gevoelige bedrijfsgegevens. Hier faalt niet primair één enkele prompt, maar het totale systeem van standaarden, toegangen, defaults, security-bewustzijn en governance. Axios-bericht over Vibe Coding en openbaar toegankelijke artefacten

Kort gezegd: hoe autonomer de AI, hoe belangrijker het organisatorische en technische kader waarin ze werkt.

Waarom kortetermijnproductiviteit en tokenmaxxing de verkeerde AI-strategie zijn

Sommige leidinggevenden reageren op de nieuwe hefboomwerking van AI met een simpele conclusie: dan moeten we gewoon zo snel mogelijk zoveel mogelijk AI-gebruik afdwingen.

Dat is precies de verkeerde managementreactie.

Waarom?

Omdat “short term productivity” in deze context meestal alleen het volgende betekent:

• meer gegenereerde code
• meer AI-sessies
• meer tokenverbruik
• meer lokaal opgeloste taken

Maar dat alles zegt nog bijna niets over de vragen die voor AI in agile software delivery daadwerkelijk doorslaggevend zijn:

• Werd het juiste probleem opgelost?
• Begrijpt het team de wijziging?
• Kan de wijziging veilig worden uitgerold?
• Is het systeem na de wijziging beter of fragieler?
• Leert de organisatie sneller of alleen hectischer?

Juist daarom is Tokenmaxxing zo’n goed waarschuwingssignaal. Het laat zien wat er gebeurt als bedrijven AI-gebruik als een doel op zich behandelen. Dan maximaliseren medewerkers precies dat wat zichtbaar wordt beloond, zelfs als daardoor kosten, entropie en blind vliegen toenemen. Pragmatic Engineer over de trend Tokenmaxxing

Jez Humble heeft dit managementprobleem al lang vóór de huidige AI-golf scherp beschreven: als managers zich direct op productiviteit richten, worden langetermijnverbeteringen vaak juist niet doorgevoerd. Voor AI in agile software delivery geldt dat in versterkte mate. Jez Humble over focus op productiviteit en uitblijvende langetermijnverbeteringen

Wat in plaats daarvan werkt: vier robuuste oplossingen voor AI in agile software delivery

1. Verantwoordelijkheid expliciet bij de mens houden

AI mag versnellen, voorstellen en ontlasten. Maar het mag geen excuus worden voor het vervagen van de verantwoordelijkheid voor besluitvorming en kwaliteit.

In de praktijk betekent dit:

• duidelijke owners voor architectuur, security en productrelevante beslissingen
• geen succesmetrieken die louter AI-activiteit belonen
• expliciete review- en vrijgaveregels voor door AI gegenereerde wijzigingen

2. Een engineering-harness bouwen in plaats van alleen AI-tools

Veel teams investeren eerst in modellen en pas als laatste in de voorwaarden waaronder deze modellen veilig kunnen werken. Precies dat moet worden omgedraaid.

Tot een belastbaar harness voor AI in agile software delivery behoren bijvoorbeeld:

• goede specificaties
• kleine, controleerbare werkpakketten
• automatische tests
• statische analyse
• gecontroleerde sandboxes
• duidelijke architectuurcontexten
• snelle feedback uit CI, delivery en productie

Als je over deze gedachte wilt nadenken, zijn ook OpenSpec en het GitHub Spec Kit nuttige referenties over specificatiegestuurd werken met AI: OpenSpec voor specificatiegestuurde productontwikkeling, GitHub Spec Kit voor spec-driven ontwikkeling

3. Klantfeedback sneller maken dan codeproductie

AI is alleen een duurzame delivery-hefboom als de leercycli mee worden versneld. Anders produceer je alleen maar sneller langs de werkelijkheid heen.

Concreet betekent dit:

• kleinere releases
• meer experimenten met echte feedbackloops met klanten
• consistentere analyse van gegevens over featuregebruik
• snellere evaluatie van support- en gebruikerssignalen

Wie alleen de codingsnelheid verhoogt, maar niet de feedbacksnelheid en -kwaliteit, bouwt geen AI-native organisatie, maar alleen een snellere “Feature Factory”, zoals John Cutler het beschrijft. Zie: 12 Signs You’re Working in a Feature Factory

4. Retrospectives en leercycli serieus nemen

Wanneer AI in agile software delivery faalt, zijn de oorzaken vaak systemisch. Dan helpt het weinig om alleen individuele prompts of tools te optimaliseren.

Teams hebben routines nodig waarin ze terugkerende patronen zichtbaar maken en systematisch oplossen:

• Waar verliezen we het overzicht?
• Waar ontstaat een review-stroomversnelling?
• Waar genereert AI meer herstelwerk dan nut?
• Waar optimaliseren we lokale snelheid ten koste van het totale systeem?

Juist daarom blijven retrospectives relevant. Niet als een ritueel uit het Scrum-verleden, maar als mechanisme voor organisatorisch leren in een omgeving met een hogere veranderfrequentie.

Conclusie: AI in agile software delivery faalt zelden door te weinig AI

De eigenlijke ironie is: veel organisaties falen met AI niet omdat ze te voorzichtig zijn, maar omdat ze te kortzichtig sturen.

Ze verwarren kortetermijnproductiviteit met duurzame waardcreatie en verbetering van het delivery-systeem. Ze verwarren tokenverbruik met waardcreatie. Ze verwarren autonome codegeneratie met organisatorische volwassenheid.

De betere leidraad is daarom niet: “Hoe krijgen we onze teams zover dat ze nog meer AI gebruiken?”

Maar eerder:

• Onder welke voorwaarden verbetert AI onze delivery werkelijk?
• Waar veroorzaakt AI op dit moment nieuwe flessenhalzen in de waardeketen?
• Waar legt AI systemische tekortkomingen bloot die we moeten verbeteren?
• Welke organisatorische vaardigheden moeten we versterken, zodat versnelling niet omslaat in entropie?

Als je daarvoor eerst het nuchtere bewijs wilt zien, lees dan hier verder: Stand van zaken van de studies over AI in agile softwareontwikkeling .

Als je direct naar managementhefbomen zoekt, ga hier verder: Handleiding voor CTO’s en engineering managers over AI in agile softwareontwikkeling .

FAQ over AI in agile software delivery

Waarom levert AI mijn team meer output op, maar geen betere delivery?

Omdat meer output niet automatisch betere delivery betekent. Als reviews, tests en feedback niet kunnen volgen, neemt vooral de complexiteit toe.

Wat betekent Tokenmaxxing in AI-ondersteunde softwareontwikkeling?

Tokenmaxxing betekent AI-gebruik of tokenverbruik tot doel maken. Dat meet activiteit, maar geen waarde.

Wat zouden engineering managers moeten doen in plaats van alleen AI-productiviteit op te pushen?

Ze moeten verantwoordelijkheid, tests, reviews en feedbackloops versterken. Pas dat maakt AI op de lange termijn nuttig.

Hebben teams met veel AI-ondersteuning überhaupt nog agile rituelen nodig?

Ja, maar met een andere focus. Minder statusbeheer, meer feedback, leren en continue verbetering.

Hoe meet ik als Engineering Manager of AI in softwareontwikkeling echt iets oplevert?

Meet doorlooptijd, review-inspanning, foutpercentage en klantwaarde. Pure output is niet genoeg.

Waarom wordt mijn team met AI sneller, maar worden de resultaten niet beter?

Omdat meer code niet automatisch betere resultaten oplevert. Zonder degelijke reviews, tests en feedback neemt alleen de entropie toe.

Welke KPI's moet ik echt tracken voor AI in softwareontwikkeling?

Track doorlooptijd, defect rate, rework, deployment-veiligheid en de tijd tot klantenfeedback. Tokens alleen zeggen te weinig.

Hoe voorkom ik dat AI-gegenereerde code mijn team later afremt?

Houd wijzigingen klein, test ze zorgvuldig en sta op duidelijke review. AI mag snelheid brengen, maar geen begrip vervangen.