Een team dat ik ken had net zijn beste maand op het dashboard. Pull requests met 98% omhoog. Commits met de helft toegenomen. De burn-down chart als een skipiste.
Toen iemand op een dag git log draaide op de bestanden waar ze het trotst op waren.
Ongeveer veertig procent van de regels die in de eerste week van de maand waren ingecheckt, bleek tegen het einde van de tweede week alweer verdwenen. Dezelfde bestanden. Dezelfde auteurs. Andere code, en soms een tweede oplossing voor exact hetzelfde probleem. Het team had niet sneller gebouwd. Het team had alleen sneller gechurnd.
Dit is het stuk van het AI-productiviteitsverhaal dat niemand op het dashboard zet.
De stille tweeling van de lavalaag
Een tijd geleden schreef ik over de lavalaag: AI-code die niemand begrijpt, die afkoelt tot gesteente waar niemand meer aan durft te komen. Dat is de faalmodus die blijft.
Churn is de faalmodus die dat niet doet.
Allebei dezelfde auteur. Een agent die met overtuiging code schrijft zonder mentaal model van het systeem, alleen een model van hoe de prompt eruitzag. De lavalaag is toevallig die ene versie die compileerde, de test groen liet en in de PR belandde voordat iemand de moeilijke vraag stelde.
De gechurnde code is al het andere: de versie die op dinsdag werd herschreven, op donderdag vervangen, en de week erop nog eens vervangen door iemand die geen van de eerdere pogingen had gelezen.
Andere afloop. Zelfde oorzaak. Er is niemand thuis.
Wat de cijfers zeggen
De langetermijnanalyse van GitClear zet de churn-ratio van AI-intensieve repositories op ongeveer het dubbele van de pre-AI-baseline. De enquête van The Pragmatic Engineer onder 900 respondenten geeft een gezicht aan dezelfde cijfers:
"builders" die verzuipen in slop, review-tijd 91% omhoog, "shippers" die technische schuld sneller produceren dan het team kan verwerken.
De analyse van Cerbos laat zien wat er gebeurt op het moment dat die churn de security-laag raakt: 322% meer privilege-escalatiepaden, 153% meer design flaws, en AI-commits die vier keer zo snel worden gemerged als menselijke commits, simpelweg omdat reviewers het volume niet meer bijbenen.
Let op wat die cijfers beschrijven. Geen ervan gaat over code die fout is. Ze gaan over code die voorlopig is. Code die wordt gemerged, bijgewerkt, teruggedraaid, herschreven en opnieuw gemerged. De PR-teller loopt elke keer op. Aan de andere kant komt er niets bruikbaars uit.
Waarom agents churnen
Een mens schrijft een feature met een mentaal model van het systeem. Dat model klopt op interessante punten niet, prima, maar het is een model. Verschuift de requirement, dan buigt het model mee. Code die uit echt begrip voortkomt, valt meestal te bewerken.
Een agent schrijft een feature met een model van hoe de prompt eruitziet. Er zit geen systeem in zijn hoofd. Geen invarianten. Geen "zo praten wij met billing." Verandert de prompt, ook maar minimaal, dan is de enige eerlijke zet om het vorige antwoord weg te gooien en opnieuw te genereren.
De agent doet dat zonder met de ogen te knipperen. Hij heeft geen belang bij de versie van gisteren. Hij heeft nergens belang bij.
Daarom komt het 70%-probleem dat Addy Osmani benoemde zo helder terug in de churn-cijfers. De agent levert je razendsnel een eerste draft.
De laatste 30%, het stuk waarvoor je moet begrijpen waar de code voor is, komt er nooit. Dus wordt de draft vervangen. En nog eens vervangen. Het dashboard telt elke vervanging als werk.
Het dashboard heeft het mis.
De metric die je team al heeft
Je hebt hier geen leverancier voor nodig. Geen observability-stack. Niets om in te bouwen. De data zit in git log.
Een vuistregel die werkt:
- Pak een bestand dat de afgelopen twee weken is veranderd.
- Tel het aantal regels dat in de eerste week is toegevoegd.
- Tel hoeveel van die regels aan het einde van de tweede week nog bestaan.
Dat is je retentie. Zit die onder de 60% voor bestanden die niet bewust worden gerefactord, dan churn je. Geen iteratie. Churn.
Het verschil is belangrijk. Iteratie is wanneer je versie één uitrolt, iets leert en bewust vervangt. Churn is wanneer versie één op dag één al fout was, versie twee op een andere manier fout, en niemand kan vertellen wat het verschil tussen die twee jou had moeten leren.
Iteratie heeft een verhaal. Churn heeft dat niet.
De kosten betaal je drie keer
Elke churn-cyclus wordt drie keer betaald:
- Generatie. Tokens kosten echt geld. Uit de enquête van The Pragmatic Engineer blijkt dat bedrijven $200 tot $2.000 per engineer per maand neerleggen voor Claude Code, Cursor en Codex. Veertig procent van de output weggooien betekent dat je voor de prullenbak betaalt.
- Review. Elke gegenereerde versie gaat alsnog door code review. De review-tijd is bij AI-zware teams met 91% gestegen. Reviewers keuren werk goed waarvan ze weten dat het volgende week weer weg is, en ze keuren het toch goed, anders loopt de queue niet leeg.
- Herschrijven. Tegen de tijd dat de herschrijving eindelijk komt, heeft de oorspronkelijke auteur het bestand al dagen niet aangeraakt. De agent die het schreef, heeft er natuurlijk geen herinnering aan. Dus begint de herschrijving vanaf nul, en de cyclus start opnieuw.
Drie betalingen. Eén resultaat. Of helemaal geen resultaat.
Dit is het stuk dat alle "AI maakte ons 30% sneller"-enquêtes blijven missen. Die 30% is echt, op het moment zelf, aan het toetsenbord. Het is precies de dopamine die Cerbos beschrijft. De rekening komt later, in een ander grootboek.
Wat je in plaats daarvan doet
Stop met pull requests tellen. Het is geen eenheid van output meer, het is een eenheid van activiteit, en daar heeft je team al te veel van.
Probeer dit:
- Netto behouden regels per week, per bestand. Was een feature op maandag 800 regels en vrijdag nog 320, dan heeft het team die week 320 regels werk geleverd, niet 800. Bonus als je dashboard dit naast het aantal PR's kan tonen. Het gat zal je niet vleien.
- Een tweewekelijks churn-budget. Kies een getal. Vijf procent, tien, wat dan ook. Schiet een bestand daar overheen zonder geplande refactor, dan is dat het signaal om af te remmen en je af te vragen wat er in het begrip van het team is veranderd, niet alleen in de code.
- Behandel de eerste draft als wegwerp. Altijd. De eerste poging van de agent is een gesprek met het probleem, geen oplossing ervan. De echte waarde zit in de tweede draft, nadat een mens de eerste heeft gelezen en heeft geleerd wat er aan de prompt schortte. Bewaar je review-energie voor die tweede.
- Stop met mergen op 70%. Dit is de moeilijke. De agent brengt je glimlachend tot 70%. Het team voelt zich productief elke keer dat je die 70% de deur uit doet. Het voelt zich minder productief als je ze laat zwoegen op de laatste 30%. Laat ze toch zwoegen. Die laatste 30% is precies het stuk dat bepaalt of het bestand donderdag opnieuw wordt herschreven.
De twee manieren waarop code nergens heen gaat
De lavalaag van versteende AI-code is de code die zich zo om je codebase heen verhardt dat je hem niet meer kunt refactoren. Churn is de code die nooit verhardt. De eerste is een museum. De tweede is een loopband.
Allebei zien ze er op het dashboard uit als productiviteit.
Geen van beide is dat.
Het goede nieuws is dat één van de twee in git log opduikt voordat hij tijd heeft om te verstenen. Lees de log. Tel de overlevers. Let op welke bestanden stilletjes worden herschreven door mensen die niet meer weten dat ze die ooit zelf hebben geschreven. Lees hem als een verloop over weken, want dat is ook de enige eerlijke manier om te vragen of het aan je nieuwe model ligt.
Er is niemand thuis. Maar de deur staat in elk geval nog open.