DORA-metrics lezen als AI de helft van je commits schrijft

Je DORA-dashboard toont nog steeds dezelfde vier getallen. Alleen betekenen ze niet meer hetzelfde.

Zodra een flink deel van je code niet meer met de hand geschreven wordt, verschuift wat elk van die metrics je vertelt. Sommige gaan omhoog zonder dat er iets verbeterd is. Eén wordt plotseling veel belangrijker dan de rest. En de naïeve lezing — “onze deployment frequency stijgt, dus het gaat goed” — wijst precies de verkeerde kant op.

De vier DORA-metrics meten je software delivery, niet je productiviteit. Dat onderscheid is altijd al belangrijk geweest, maar met AI in de mix wordt het bepalend.

• Deployment frequency — hoe vaak je naar productie brengt.
• Lead time for changes — hoe lang het duurt van commit tot productie.
• Change failure rate — welk deel van je wijzigingen problemen veroorzaakt.
• Time to restore — hoe snel je herstelt als het misgaat.

Geen van deze vier meet hoeveel code je schrijft. Dat was ooit een detail. Nu is het de kern: code schrijven is niet langer je bottleneck, dus een metric die code-volume negeert is precies wat je nodig hebt.

Dit is de metric die het snelst beweegt als je AI-tooling invoert, en de metric die het makkelijkst misleidt.

Meer wijzigingen komen sneller klaar, dus er gaan meer wijzigingen naar productie. Je grafiek gaat omhoog. Iemand zet hem in een presentatie.

Maar deployment frequency meet beweging, geen vooruitgang. Als de extra deploys bestaan uit wijzigingen die niemand gevraagd heeft, of uit correcties op wijzigingen van vorige week, dan is je grafiek een teller van activiteit. Kijk er dus nooit naar zonder de change failure rate ernaast te leggen. Stijgen ze samen, dan is er geen winst — dan is er alleen meer verkeer.

Lead time for changes is een optelsom: nadenken, schrijven, reviewen, testen, wachten op goedkeuring, uitrollen.

AI verkort betrouwbaar precies één van die stappen. De rest blijft staan waar hij stond.

Dat betekent dat je totale lead time veel minder daalt dan je verwacht — en dat de verhouding binnen die optelsom scheeftrekt. Waar schrijven vroeger misschien een derde van de doorlooptijd was, is het nu een fractie, en is wachten op een reviewer of op een pipeline verhoudingsgewijs veel dominanter geworden.

Dat is geen tegenvaller, dat is de meest bruikbare informatie die je uit deze metric kunt halen. Splits je lead time op in fases zodra je AI serieus inzet. Zonder die opsplitsing zie je één getal dat licht verbetert; mét die opsplitsing zie je precies waar je volgende uur winst ligt.

Als code goedkoop wordt om te maken, wordt het duur om te vertrouwen.

Dat maakt de change failure rate de metric waar je het scherpst op moet letten. Niet omdat AI-code per se slechter is — dat argument is grotendeels achterhaald — maar omdat er méér van komt, sneller, en met minder mensen die elke regel echt gelezen hebben.

Twee dingen om in de gaten te houden. Ten eerste een stijging die samenvalt met je AI-invoering: dat is het signaal dat je snelheid je controlemechanismen voorbij is gelopen. Ten tweede, en subtieler, een change failure rate die gelijk blijft terwijl je deployment frequency verdubbelt. Dat betekent in absolute zin twee keer zoveel incidenten. Percentages verhullen dat.

Van de vier metrics is dit degene die het minst reageert op AI-tooling, en juist daarom is hij zo informatief.

Herstellen na een incident hangt af van je observability, je runbooks, je rollback-mechanismen en of de juiste persoon bereikbaar is. Een model dat sneller code schrijft, raakt daar niets van.

Dus als je deployment frequency omhoog gaat, je lead time daalt en je time to restore blijft precies waar hij was, dan heb je de risicokant van je systeem niet meegeschaald met de snelheidskant. Dat is een prima situatie om in te zitten zolang je het wéét, en een uitstekende manier om verrast te worden als je het niet meet.

DORA blijft belangrijk, maar het is niet meer voldoende. Drie aanvullingen die in een AI-zware workflow het meeste opleveren:

• Review-latency. De tijd tussen “klaar voor review” en “gereviewd”. Dit is in de meeste teams inmiddels de grootste enkele post in je lead time, en hij wordt zelden apart bijgehouden.

• Rework-ratio. Welk deel van je wijzigingen binnen bijvoorbeeld twee weken alweer aangeraakt wordt. Stijgt dit terwijl je sneller levert, dan produceer je herstelwerk in plaats van vooruitgang.

• Aandeel AI-ondersteunde wijzigingen. Je hoeft niet elke regel te herleiden, maar zonder enige indicatie kun je geen enkele uitspraak doen over wat AI je gebracht heeft. Zelfs een grove markering op PR-niveau maakt het verschil tussen meten en gokken.

Begin met een nulmeting vóór je AI-tooling breed uitrolt. Zonder die basislijn kun je achteraf niets aantonen, en precies dát is waar de meeste discussies over AI-investeringen op stuklopen: iedereen heeft een mening, niemand heeft een grafiek van ervoor.

Splits daarna je lead time op in fases, en zet review-latency en rework-ratio ernaast. Bekijk change failure rate altijd in absolute aantallen naast het percentage.

Dit is precies het soort meting waar onze Agile Analytics-engine voor gebouwd is: DORA en SPACE naast elkaar, met de fases uitgesplitst, zodat je ziet waar je doorlooptijd werkelijk heen gaat in plaats van één samengevat getal.

AI verandert je DORA-metrics niet. Het verandert wat ze betekenen.

Deployment frequency wordt gevoeliger voor ruis. Lead time verbetert minder dan verwacht, en verschuift van schrijven naar wachten. Change failure rate wordt je belangrijkste signaal. Time to restore beweegt nauwelijks, en verraadt daarmee of je risicobeheersing is meegegroeid.

Lees ze samen, in absolute aantallen zowel als percentages, met je lead time opgesplitst. Dan meet je wat AI werkelijk heeft opgeleverd — in plaats van te vieren dat de grafiek omhoog loopt.