Voorbij het groene dashboard: waarom traditionele DevOps-KPI's falen in het tijdperk van AI

By Mirko Peters · 2026-08-13

Welkom terug bij de blogversie van onze lopende podcastserie. Als je tegenwoordig een executive dashboard in de techsector opent, zie je bijna zeker een zee van groene indicatoren. De deploymentfrequentie stijgt tot ongekende hoogten, pull requests worden sneller samengevoegd dan ooit, en AI-assistenten spuwen in enkele seconden duizenden regels code uit. Voor het management lijkt het alsof softwa

Automatically translated with AI from the original post. Read the English original

Welkom terug bij de blogversie van onze lopende podcastserie. Als je tegenwoordig een executive dashboard in de techsector opent, zie je bijna zeker een zee van groene indicatoren. De deploymentfrequentie stijgt tot ongekende hoogten, pull requests worden sneller samengevoegd dan ooit, en AI-assistenten spuwen in enkele seconden duizenden regels code uit. Voor het management lijkt het alsof softwarelevering een gouden tijdperk van ongekende efficiëntie is binnengegaan. Maar als je praat met de engineers die echt in de loopgraven zitten, hoor je een heel ander verhaal. Ze verdrinken in technische schuld, worstelen met eindeloze reviewrijen en ervaren een ongekend niveau van burn-out. Hoe kan een dashboard er zo groen uitzien terwijl de engineeringrealiteit zo rood aanvoelt?

Deze paradox is precies wat we uitpluizen in onze laatste aflevering. Als je er nog niet naar hebt geluisterd, bekijk dan zeker The Productivity Illusion: Why AI is Breaking Your Engineering KPIs. In deze post bouwen we verder op die gesprekken en duiken we diep in waarom onze traditionele manieren om engineeringprestaties te meten fundamenteel vastlopen in het tijdperk van generatieve kunstmatige intelligentie.

Waarom traditionele DevOps-KPI's falen in het tijdperk van AI

Al meer dan tien jaar vertrouwt de DevOps-beweging op een vaste set kernstatistieken om succes te meten. We kijken naar deploymentfrequentie, doorlooptijd van wijzigingen, faalpercentages bij wijzigingen en gemiddelde hersteltijd. Deze statistieken leerden ons hoe we monolieten opdeelden, onze pipelines automatiseerden en klanten snel en iteratief waarde konden leveren. Ze waren ontworpen voor een wereld waarin mensen elke afzonderlijke regel code schreven en elke variabele, functie en architectuurbeslissing zorgvuldig afwogen.

Vandaag is die fundamentele aanname volledig aan diggelen. AI heeft de vergelijking fundamenteel veranderd. Het primaire knelpunt in softwareontwikkeling is niet langer het fysieke typen van code in een editor. Toch zijn onze traditionele KPI's nog steeds sterk gericht op het meten van outputsnelheid. Wanneer je een AI-codeerassistent in je ontwikkelomgeving aansluit, kun je je commitfrequentie en het aantal pull requests direct laten stijgen. Dat betekent echter niet dat je je pad naar zakelijke waarde succesvol hebt versneld. Je hebt simpelweg de snelheid verhoogd waarmee code je systeem binnenkomt. Traditionele DevOps-KPI's meten activiteit, niet begrip of gezondheid, waardoor het management met een gevaarlijk valse zekerheid achterblijft.

Wanneer meer code meer problemen oplevert

Een van de meest opvallende ironieën van het AI-gedreven ontwikkeltijdperk is dat meer code vrijwel altijd meer problemen betekent. Vroeger was code schrijven een langzaam, weloverwogen proces. Omdat ontwikkelaars elke regel fysiek moesten schrijven, was code van nature beperkt door menselijke typesnelheid en cognitieve capaciteit. Nu kan een ontwikkelaar een LLM vragen om in minder dan twee minuten een volledige microservice of een complexe datapipeline te genereren.

De adder onder het gras? Mensen moeten nog steeds elk stukje ervan reviewen, verifiëren en onderhouden. Wanneer een ontwikkelaar een enorme, door AI gegenereerde pull request indient met vijfhonderd regels complexe logica die hij of zij niet zelf heeft geschreven, kruipt het reviewproces traag vooruit. Senior engineers worden overspoeld en vormen het knelpunt. Productie-incidenten nemen toe omdat subtiele architectuurfouten of beveiligingskwetsbaarheden zijn ontsnapt aan uitgeputte reviewers. In plaats van engineeringwerk weg te nemen, heeft AI de last simpelweg verder stroomafwaarts verschoven, naar de onderdelen van de softwarelevenscyclus die het meest door menselijke beperkingen worden begrensd: validatie, governance en langetermijnonderhoud.

De cognitieve belastingcrisis: code begrijpen versus code schrijven

Om echt te begrijpen waarom onze statistieken falen, moeten we kijken naar cognitieve belasting. Softwareontwikkeling is nooit een typwerk geweest; het is fundamenteel een werk van lezen en probleemoplossen. Programmeurs besteden het overgrote deel van hun tijd aan het lezen van bestaande code om de context te begrijpen voordat ze ook maar één nieuwe regel schrijven.

AI heeft de inspanning om code te schrijven drastisch verlaagd, maar de inspanning om die code te begrijpen juist exponentieel verhoogd. Ontwikkelaars brengen hun dagen nu door als codereviewers voor een onzichtbare junior ontwikkelaar die nooit slaapt. Ze moeten springen tussen onbekende logische structuren, ingewikkelde abstracties ontwarren die door taalmodellen zijn gegenereerd en uitzoeken hoe ze code moeten debuggen die zonder enige architectuurcontext of documentatie is opgeleverd. Deze constante contextwisseling put het cognitieve vermogen uit. Engineers zijn uitgeput, niet omdat ze geweldige dingen bouwen, maar omdat al hun mentale energie opgaat aan het ontcijferen van door machines gegenereerde implementaties.

De giftige KPI-valkuil: activiteit optimaliseren in plaats van resultaten

Goodhart's Law stelt dat wanneer een maatstaf een doel wordt, die maatstaf niet langer goed is. Veel engineeringorganisaties trappen vandaag in deze valkuil. Leidinggevenden stellen doelen op basis van metrics die makkelijk te volgen zijn, zoals het aantal commits, het percentage AI-adoptie of de ruwe deploymentfrequentie, in de hoop de productiviteit te verhogen.

In plaats daarvan creëren ze een giftige KPI-valkuil. Teams beseffen snel dat ze, als leidinggevenden hoge doorvoer van pull requests belonen, AI kunnen gebruiken om eindeloze stromen code met weinig waarde te genereren. De cijfers op het managementdashboard gaan omhoog, maar onder de oppervlakte schieten de rework rates omhoog, keldert de codekwaliteit en stapelt de technische schuld zich op. Organisaties raken verstrikt in het furieus optimaliseren van activiteit in plaats van zinvolle resultaten op te leveren. Ze bewegen zich steeds sneller richting een afgrond en vieren onderweg elke mijlpaal, omdat de snelheidsmeter er prachtig uitziet.

Van activiteit naar flow: engineeringmetrics opnieuw definiëren

Als ruwe activiteitsmetrics zoals deploymentfrequentie en aantallen commits niet langer betrouwbaar zijn, hoe moeten we dan de gezondheid van engineering meten? Het antwoord ligt in het verschuiven van de focus van activiteit naar flow. We moeten ophouden met vragen hoeveel code we uitleveren, en beginnen met vragen hoe efficiënt werk door ons leveringssysteem stroomt.

Flowgebaseerde metrics geven een veel helderder beeld van wrijving in het systeem. We moeten metrics volgen zoals flow-efficiëntie, wachtrijleeftijd, doorlooptijden van reviews en limieten voor work in progress. Wanneer een AI-tool een berg code genereert, laat een flowgericht dashboard meteen het knelpunt zien: de code blijft stilliggen in reviewwachtrijen omdat menselijke reviewers het tempo van de generatie niet kunnen bijbenen. Door te meten hoe werk stroomt in plaats van hoe snel code wordt geschreven, kunnen leidinggevenden echte beperkingen identificeren en hun teams beschermen tegen kunstmatige knelpunten.

De DORA 5 introduceren en de rework rate meten

Om in te spelen op de realiteit van AI-ondersteunde ontwikkeling pleiten experts nu voor uitbreiding van de klassieke DORA-metrics met een vijfde dimensie: de rework rate. De traditionele DORA-metrics, zoals deploymentfrequentie, lead time for changes, change failure rate en mean time to recovery, zijn essentieel, maar ze leggen niet vast hoe duurzaam de gebouwde software is.

De rework rate meet hoeveel recent geschreven code kort na deployment of merge moet worden aangepast, herschreven of verwijderd. Als een engineeringteam AI gebruikt om snel grote hoeveelheden code te genereren, maar die code een hoge rework rate heeft, wijst dat op diepgewortelde systeemproblemen. Het duidt op zwakke verificatie, slechte duurzaamheid van de code, kwetsbare architecturen en een onjuist gebruik van AI. Het meten van de rework rate zorgt voor een noodzakelijke realiteitscheck op het engineeringdashboard en voorkomt dat snelheid ten koste gaat van duurzaamheid.

Burn-out als systeemmetric

Tot slot moeten we het hebben over menselijke duurzaamheid. Al te lang wordt burn-out bij ontwikkelaars puur als een HR-kwestie behandeld, iets wat je oplost met wellnessseminars of tafeltennistafels. In het AI-tijdperk moet burn-out bij ontwikkelaars worden gezien als een kernsysteemmetric.

Wanneer de cognitieve belasting piekt, de contextwisselingen toenemen en reviewwachtrijen onbeklimbare bergen worden, raken ontwikkelaars uitgeput. Hoge burn-out leidt onvermijdelijk tot langere reviewcycli, een hoger verloop onder je meest ervaren engineers en een forse daling van de algehele softwarekwaliteit. Als je beste mensen vertrekken, faalt je engineeringsysteem, hoe groen je deploymentdashboard er ook uitziet. Tevredenheid van ontwikkelaars en cognitieve gezondheid behandelen als leidende indicatoren voor de veerkracht van het systeem is de enige manier om een duurzame engineeringorganisatie voor de toekomst op te bouwen.

Conclusie: duurzame engineeringsystemen bouwen voorbij het groene dashboard

De opkomst van kunstmatige intelligentie in softwareontwikkeling is een van de meest opwindende verschuivingen in de geschiedenis van onze sector. Ze biedt echt de belofte om repetitief sleurwerk weg te nemen en ontwikkelaars de ruimte te geven om zich te richten op problemen met een grote impact. Toch is het een recept voor een ramp om AI te behandelen als een toverstokje dat de output simpelweg vermenigvuldigt zonder de fundamentele dynamiek van softwarelevering te veranderen. Als we vertrouwen op verouderde KPI's, riskeren we fragiele systemen te bouwen die worden gedreven door uitgeputte mensen.

Om voorbij het groene dashboard te komen, moeten leiding en engineeringteams het eens worden over metrieken die er echt toe doen: de doorstroming meten, de cognitieve belasting monitoren, het aantal herwerkingen bijhouden en burn-out behandelen als een vitale indicator van de gezondheid van de organisatie. Wil je dieper ingaan op deze cruciale verschuiving en leren hoe je je metrieken aanpast aan het AI-tijdperk? Luister dan zeker naar onze volledige aflevering, The Productivity Illusion: Why AI is Breaking Your Engineering KPIs. Laten we stoppen met optimaliseren voor beweging en beginnen met het bouwen van duurzame, hoogpresterende engineeringsystemen die echt waarde leveren.