Cost per accepted change: wat kost een wijziging die niet wordt teruggedraaid?

Zet AI-tooling aan in een ontwikkelteam en binnen een week staan alle tellers hoger. 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 nullijn.

De vraag die overblijft: wat kost het om één wijziging helemaal door te krijgen? Door de review, door de pipeline (de automatische build- en testrun), naar productie — en dertig dagen later niet teruggedraaid. Dat getal noemen we de cost per accepted change: de kosten per wijziging die geaccepteerd is. Het is het enige getal dat nog iets zegt.

In het stuk over DORA-metrics lezen als AI de helft van je commits schrijft stond het al: AI verandert je cijfers niet, maar wel wat ze betekenen. Deployment frequency (hoe vaak code productie bereikt) wordt ruis. Lead time (van commit tot draaiend in productie) daalt alleen op het stuk dat AI doet, het schrijven — en dat was zelden de bottleneck.

Wat er wél verandert: er komen meer wijzigingen binnen dan het team kan beoordelen. De reviewers worden de bottleneck. En een bottleneck onder druk doet één van twee dingen: de wachtrij groeit, of de review wordt oppervlakkiger. Geen van beide zie je in het aantal merges. Je ziet het pas later, in de change failure rate (het aandeel releases dat een fix nodig heeft) en in de reverts, de wijzigingen die weer teruggedraaid worden.

Daarom zegt het aantal niets. Wat telt is hoeveel van wat er gemaakt wordt de hele weg haalt, en wat die weg kost.

Cost per accepted change is een breuk.

Boven de streep: 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 (de rekentijd van je pipeline) en, sinds kort, de tokens van het model.

Onder de streep: het aantal wijzigingen dat geaccepteerd is. Niet gemerged; geaccepteerd. Een wijziging telt pas als hij gemerged en gedeployed is, en dertig dagen later niet is teruggedraaid of met een hotfix (een spoedreparatie in productie) is gerepareerd.

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

De breuk is bewust blind voor volume. Twee keer zoveel pull requests (voorgestelde wijzigingen die op review wachten) tegen dezelfde kosten per geaccepteerde wijziging: winst. Twee keer zoveel tegen het dubbele: niets. Twee keer zoveel waarvan de helft de review niet haalt: verlies — dat op elk ander dashboard als groei verschijnt.

Je hoeft niets met de hand bij te houden. Bijna alles staat al in je tools; het moet alleen naast elkaar worden gezet.

• Overleving. Per merge: is hij binnen dertig dagen teruggedraaid, of gevolgd door een fix in dezelfde bestanden? Dat staat in Git. Het is de change failure rate, maar dan per wijziging in plaats van per deploy.
• Reviewtijd. De tijd tussen de eerste reviewaanvraag en de goedkeuring, het aantal reviewrondes, het aantal opmerkingen. GitLab en GitHub leveren het via hun API.
• Afvallers vóór de merge. Pull requests die zonder merge gesloten worden, of langer dan een week openstaan. Ze kostten reviewtijd en leverden niets op; ze horen boven de streep, niet eronder.
• CI-minuten per pull request, inclusief de herhaalde runs na elke correctie.
• Tokens per pull request 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 reviewronde en per grootte van de pull request. De fout is dan constant, en valt weg zodra je vergelijkt.

Zet dit naast elkaar en je hebt één getal per week. Dat getal op zichzelf zegt weinig. De richting — vóór en na een verandering in hoe je werkt — zegt alles.

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

Elke afgewezen pull request kostte een reviewer tijd. Bij vijftig procent uitval gaat de helft van die tijd naar werk dat nooit in productie komt. En dat is precies de reviewcapaciteit die al je plafond was vóór er een agent was.

Is reviewcapaciteit je bottleneck, en dat is hij bij de meeste teams, dan maakt een agent die de uitval niet omlaag brengt je wachtrij langer, niet korter. Daarom laten wij bij ZEN de agent die 's nachts onze merge requests leest niets mergen. Hij maakt het verzamelen goedkoper; het oordelen blijft waar het hoort.

Het prettige aan cost per accepted change is dat het het gesprek over AI verplaatst van geloof naar meting.

De vraag is niet meer "schrijft het model goede code?". De vraag is: is de prijs van een wijziging die het haalt gedaald? Zo ja, met hoeveel, en op welk soort werk? Vaak zie je het getal hard dalen bij integraties, migraties en tests, en niet bewegen bij ontwerpwerk. Dat is geen teleurstelling. Het laat zien waar AI zijn geld waard is.

Het getal beschermt ook tegen de valkuil aan de andere kant. Een team dat de review versoepelt om de wachtrij weg te werken, ziet zijn merges stijgen en zijn overleving dalen. De cost per accepted change 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: overleving, reviewtijd, afvallers vóór de merge, CI-minuten, tokens. Uren als vaste schatting.
4. Kijk per soort werk, niet alleen per team. Het getal 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 (het automatisch bouwen, testen en uitrollen van elke wijziging) en Jira naast elkaar, met DORA als kader. Cost per accepted change is geen nieuwe metriek erbovenop. Het is dezelfde data, gelezen vanuit de vraag die er nu toe doet.

AI maakt code goedkoop, en daarmee zeggen aantallen niets meer: commits, pull requests, deploys. Wat overblijft is de prijs van één wijziging die productie haalt en niet wordt teruggedraaid. Meet die uit Git en CI, definieer "geaccepteerd" streng, begin met een nulmeting en kijk naar de richting. Haalt minder dan de helft de review, dan verplaatst je agent het werk in plaats van het weg te nemen.