Of AI een dev-team aantoonbaar helpt, meet je met vier metrics per sprint: doorlooptijd, revert-rate, PR-omvang en de velocity-trend. Samen laten ze zien of extra AI-code ook extra resultaat oplevert, of vooral extra reviewlast. Meet daarnaast de teamervaring: vertrouwen en werkplezier verklaren wat de cijfers alleen niet laten zien.
Voor wie? De tech lead of squad lead die wil weten of AI-tooling het team aantoonbaar helpt, in plaats van te varen op een onderbuikgevoel.
In de retro zegt iedereen hetzelfde: het voelt sneller. Niemand heeft er een getal bij, maar het gevoel is goed genoeg om mee door te gaan. Tot een sprint tegenvalt en niemand kan zeggen of dat aan de AI ligt, aan de sprint zelf, of aan iets heel anders.
Gevoel is een slechte raadgever bij AI-adoptie. Welke cijfers vertellen je wél wat er in je team gebeurt?
Waarom volstaat gevoel niet?
Developers denken zo'n 20% sneller te zijn met AI. Uit een METR-onderzoek bleek dat ervaren developers op vertrouwde codebases gemiddeld 19% trager waren. Dat gat tussen gevoel en werkelijkheid is geen incident: gevoel overschat AI-winst systematisch, want de tijd die je bespaart op typen merk je meteen, en de tijd die je erbij inlevert aan reviewen, bijsturen en het debuggen van code die je niet zelf hebt geschreven veel minder. Op teamniveau wordt dat verschil alleen maar groter: de een voelt zich sneller, de ander is vooral meer tijd kwijt aan reviews, en in de retro heeft niemand een cijfer om het gesprek mee te beslechten.
Meet je niet, dan stuur je op gevoel. En gevoel overschat AI-winst systematisch.
Tel ook activiteit niet als bewijs. Commits, regels code en geopende PR's zeggen iets over drukte, niet over resultaat. Een stijgend AI-gebruikspercentage al helemaal niet: dat verklaart hooguit een verandering, het bewijst geen succes.
Welke vier metrics gebruik je?
Begin met een nulmeting vóór je AI serieus inzet, zodat je weet of het daadwerkelijk verschil maakt en niet alleen sneller vóélt. Meet daarna iedere sprint vier dingen:
| Metric | Waar je op let | Risicosignaal |
|---|---|---|
| Doorlooptijd per PR | Tijd van eerste commit tot merge | Stijgt die terwijl je meer genereert? Dan komen de reviews niet mee. |
| Revert-rate en post-review bugs | Teruggedraaide code en bugs die door de review glippen | Een stijging in het begin is normaal. Daalt die na een paar sprints niet, dan groeit je Fundering of Regie niet mee. |
| PR-omvang | Gewijzigde regels per PR | Te groot om in 15 minuten te doorgronden? Dan groeit de verification debt sneller dan je kunt aflossen. |
| Velocity-trend | Story points per sprint, geschat op complexiteit met een referentiestory (niet in uren, en pas de schattingsmethode niet aan omdat AI “het makkelijker maakt”) | Stijgt de velocity terwijl reverts en bugs meestijgen? Dan meet je schijnproductiviteit. |
Geen dashboard nodig. Een korte check in de retro is genoeg. De kernvraag: gaat de snelheid omhoog zonder dat de kwaliteit daalt?
Tip: laat AI je Git-historie analyseren. Via de Git- en GitHub API kun je reverts tellen, PR-omvang meten en doorlooptijd per PR berekenen. Een paar prompts en je hebt deze metrics.
Wat meet je vaak niet mee?
De doorlooptijd per PR vangt niet alles. Rond AI-werk zit een keten die zelden in een metric belandt: prompts en context voorbereiden, gegenereerde code lezen, onbruikbare output herstellen, extra reviewrondes, regressies na de merge. Gaat het coderen een half uur sneller maar duurt de review twee uur langer, dan heeft het team niets gewonnen. Voor AI telt vooral de tijd tot een geverifieerde wijziging; wat daarvoor blijft liggen, is precies de verification debt.
DORA adviseert daarom: houd je bestaande metingen als baseline en voeg alleen AI-specifieke signalen toe, zoals reviewtijd en vertrouwen [1]. Zo blijft vergelijken door de tijd heen mogelijk.
Hoe neem je de teamervaring mee?
Cijfers verklaren niet alles; de ervaring van het team en van elke developer afzonderlijk wel. Peil in de retro periodiek drie dingen:
- Vertrouwen: vertrouw je de AI-code die je merget?
- Energie: kost het reviewen van AI-output meer of minder energie dan zelf bouwen?
- Werkplezier: houd je tijd over voor de complexe puzzels, of ben je vooral AI-output aan het bijsturen?
Dalend vertrouwen of dalend werkplezier is een even hard signaal als een stijgende revert-rate. Weeg zelfrapportage wel op waarde: nuttig, maar niet als enig bewijs. Het gat tussen gevoel en meting uit het METR-onderzoek laat zien waarom je beide nodig hebt.
Hoe begin je met meten?
Meet niet “hoeveel AI gebruiken we?”, maar “welk probleem lost AI aantoonbaar op?”
- Formuleer een toetsbare verwachting, per toepassing. Codegeneratie, testgeneratie, debugging en documentatie zijn verschillend werk; AI kan bij het ene helpen en bij het andere vertragen. Bijvoorbeeld: “bij kleine bugfixes verlaagt AI de gemiddelde tijd van start tot productie met 15%, zonder extra herstelwerk, incidenten of reviewtijd.” Dan weet je vooraf wat je meet, en wanneer je tevreden bent.
- Doe een eerlijke nulmeting. Geen nieuw dashboard: je CI-pipeline en sprintboard leggen doorlooptijd, reverts en story points vaak al vast. Meet één sprint voordat je iets aan je workflow verandert, op vergelijkbare taken. En zet AI-gebruikers niet zomaar af tegen niet-gebruikers: wie enthousiast of ervaren is, kiest eerder voor AI, dus dan meet je selectie in plaats van effect.
- Kijk naar de trend, niet naar één sprint. Bespreek in de retro de lijn over drie of vier sprints. Eén losse sprint zegt weinig; een lijn die drie sprints stijgt of daalt wel.
- Reken de kosten conservatief mee. Licenties, tokens, training en het extra verificatiewerk tellen mee, en bespaarde minuten zijn pas waarde als het team ze daadwerkelijk ergens anders inzet. De ROI-calculator van DORA [2] rekent dat door, inclusief een tijdelijke productiviteitsdip bij invoering, en noemt de uitkomst zelf nadrukkelijk een schatting.
Dan heb je in de eerstvolgende retro een antwoord op de vraag die er toch al hangt: helpt AI dit team aantoonbaar, of voelt het alleen zo?
