Kosten per geaccepteerde wijziging: dé metriek als AI je code schrijft

Zet AI-tooling aan in een ontwikkelteam en binnen een week gaan alle tellers omhoog. Meer commits. Meer pull requests. Meer deploys. Wie een dashboard heeft, ziet groene pijltjes.

Geen van die pijltjes zegt of het beter gaat. Ze zeggen dat er meer geproduceerd wordt, en dat was nooit het probleem. Als code goedkoop is, is een hoog aantal geen prestatie meer; het is de standaard.

De vraag die overblijft: wat kost het om één wijziging helemaal door te krijgen? Door review, door de pipeline, in productie, en daar te blijven. Dat cijfer noemen we kosten per geaccepteerde wijziging, en het is het enige dat ons nog iets vertelt.

In het stuk over DORA-metrics als AI de helft van je commits schrijft stond het al: AI verandert niet je cijfers, maar wat ze betekenen. Deployment frequency wordt ruis. Lead time daalt alleen op het stukje dat AI doet, het schrijven, en dat was zelden de bottleneck.

Wat er wél gebeurt: het aanbod aan wijzigingen groeit harder dan de capaciteit om ze te beoordelen. Reviewers worden de flessenhals. En een flessenhals reageert op druk op twee manieren: de wachtrij wordt langer, of de review wordt oppervlakkiger. Allebei zie je niet terug in het aantal merges. Je ziet het pas later, in de change failure rate en in de revert-commits.

Daarom telt het aantal niet. Wat telt is hoeveel van wat er geproduceerd wordt de reis overleeft, en wat die reis kost.

Kosten per geaccepteerde wijziging is een breuk.

Teller: alles wat een wijziging kost tot hij in productie staat. Concreet: de uren van de engineer die hem schreef of aanstuurde, de uren van de reviewer(s), de CI-minuten, en sinds kort de tokens van het model.

Noemer: het aantal wijzigingen dat geaccepteerd is. Niet gemerged; geaccepteerd. Een wijziging telt als hij is gemerged, gedeployed, en binnen dertig dagen niet is teruggedraaid of door een hotfix gerepareerd.

Dat laatste is de kern. Een merge is een mening van een reviewer. Dertig dagen productie is een feit.

De breuk is bewust ongevoelig voor volume. Twee keer zoveel PR's tegen dezelfde kosten per geaccepteerde wijziging is winst. Twee keer zoveel PR's tegen het dubbele is niets. Twee keer zoveel PR's waarvan de helft de review niet haalt, is verlies dat op elk ander dashboard als groei verschijnt.

Je hoeft niet te gaan turven. Bijna alles staat al in je tools; het moet alleen naast elkaar gelegd worden.

• Overlevingskans. Per merge: is hij binnen dertig dagen gerevert of gevolgd door een fix die naar dezelfde bestanden verwijst? Git heeft dat; het is de change failure rate, maar dan per wijziging in plaats van per deploy.
• Review-inspanning. Tijd tussen de eerste reviewaanvraag en de goedkeuring, aantal review-rondes, aantal opmerkingen. GitLab en GitHub leveren dat via de API.
• Uitval vóór de merge. PR's die gesloten worden zonder merge, of langer dan een week open staan. Die kostten review-tijd en leverden niets op; ze horen in de teller, niet in de noemer.
• CI-minuten per PR, inclusief de herhaalde runs na elke correctie.
• Token-uitgaven per PR als je agents inzet. De meeste tooling logt dat inmiddels per taak; koppel het aan de branch.

Uren zijn het lastigst en het minst precies. Werk met een vaste schatting per review-ronde en per PR-grootte; de fout is constant en valt weg zodra je vergelijkt.

Zet dat naast elkaar en je hebt een cijfer per week. Dat cijfer op zichzelf zegt weinig. De richting ervan, vóór en na een verandering in hoe je werkt, zegt alles.

Eén vuistregel om te beginnen: als minder dan de helft van wat je agents maken de review overleeft, doe je het werk dat de agent had moeten wegnemen.

Elke afgekeurde PR kostte een reviewer tijd. Bij vijftig procent uitval besteed je die tijd voor de helft aan werk dat nooit in productie komt. Dat is precies de review-capaciteit die al je plafond was voordat er een agent was.

Dus als je review-capaciteit je flessenhals is, en dat is hij bij de meeste teams, dan maakt een agent die de uitval niet omlaag brengt je wachtrij langer, niet korter. Het is de reden dat wij bij ZEN de agent die 's nachts onze merge requests leest niets laten mergen: hij verlaagt de kosten van het verzamelen, en de kosten van het oordelen blijven waar ze horen.

Het aardige van kosten per geaccepteerde wijziging is dat het de discussie over AI verplaatst van geloof naar meting.

De vraag is niet meer "schrijft het model goede code". De vraag is: daalde de prijs van een wijziging die het haalde? Zo ja, hoeveel, en op welk soort werk? Vaak zie je dat het cijfer bij koppelingen, migraties en tests hard daalt en bij ontwerpwerk niet beweegt. Dat is geen teleurstelling; dat is de kaart van waar je AI moet inzetten.

En het cijfer beschermt tegen de valkuil aan de andere kant: een team dat de review afzwakt om de wachtrij weg te werken, ziet zijn merges stijgen en zijn overlevingskans dalen. Het cijfer per geaccepteerde wijziging blijft dan gelijk of stijgt, terwijl elk ander dashboard groen kleurt.

1. Nulmeting. Vier weken data van vóór de verandering die je wilt beoordelen. Zonder nulmeting bewijs je achteraf niets.
2. Definieer "geaccepteerd" voor jouw team: gemerged, gedeployed, dertig dagen zonder revert of hotfix. Schrijf het op; anders verschuift het.
3. Haal de vijf bronnen bij elkaar: overlevingskans, review-inspanning, uitval vóór de merge, CI-minuten, tokens. Uren als vaste schatting.
4. Kijk per soort werk, niet alleen per team. Het cijfer verschilt enorm tussen boilerplate en ontwerp.
5. Volg de richting, wekelijks. Het absolute getal is voor de CFO; de richting is voor jou.

Dit is precies waar Agile Analytics voor gebouwd is: Git, CI/CD en Jira naast elkaar, met DORA als kader. Kosten per geaccepteerde wijziging is geen nieuwe metriek erbovenop; het is dezelfde data, gelezen vanuit de vraag die er nu toe doet.

AI maakt code goedkoop. Daarmee verliezen alle aantallen hun betekenis: commits, PR's, deploys. Wat overblijft is de prijs van één wijziging die het haalt en blijft staan. Meet die uit Git en CI, definieer "geaccepteerd" streng, begin met een nulmeting, en kijk naar de richting. Overleeft minder dan de helft de review, dan verplaatst je agent het werk in plaats van het weg te nemen.