Verification debt: de schuld achter je groene tests

Verification debt is de kloof tussen wat je denkt te weten over je software en wat je daadwerkelijk hebt aangetoond: verificatiewerk dat blijft liggen wanneer een team wijzigingen accepteert zonder voldoende bewijs dat ze doen wat het team bedoelt, ook buiten het happy path. AI kan die achterstand snel laten groeien: meer wijzigingen, minder kennis die je al bouwend opdoet, en overtuigend ogende code die verkeerde aannames verbergt. Je merkt het als niemand meer durft te releasen zonder eerst alles handmatig na te lopen.

Voor wie? De tech lead of senior developer die merkt dat er meer AI-code doorheen komt dan het team betrouwbaar kan reviewen.

Nog twee dagen tot het einde van de sprint. Er staan 25 pull requests open, voor een flink deel door AI geschreven. De druk neemt toe. Kijk je alles nog goed na? Neem je de tijd om iets terug te draaien? Of laat je het liggen, en hoop je dat het de volgende sprint opgepakt kan worden?

Herkenbaar? De CI staat op groen: unit tests, smoke tests en e2e-tests slagen. Formeel kan alles door. Toch knaagt de vraag: heeft het team deze code begrepen?

Een developer aarzelt met zijn hand boven een rode release-knop terwijl het scherm vol groene vinkjes staat en twee collega's gespannen toekijken — Alles op groen. Toch aarzelt de hand boven de release-knop.

Dat is geen paranoia. AI kan code sneller produceren dan een team de gevolgen ervan kan beoordelen. Accepteer je wijzigingen zonder voldoende controle van gedrag, veiligheid en belangrijke aannames, dan blijft verificatiewerk liggen. Niet uit onwil, maar uit tijdnood. Die opgebouwde achterstand heet verification debt. Groene tests helpen, maar geven alleen zekerheid over de scenario's die je expliciet hebt getest.

Wat is verification debt?

Verification debt is de kloof tussen wat je denkt te weten over je software en wat je daadwerkelijk hebt aangetoond: het verificatiewerk dat blijft liggen wanneer een team wijzigingen accepteert zonder voldoende bewijs dat ze doen wat het team bedoelt, ook buiten het happy path. Welk bewijs voldoende is, hangt af van het risico. Denk aan: acceptatiecriteria die vooraf vaststaan, tests die de requirements, randgevallen en risico's afdekken, een beoordeling van de kritieke logica, en een developer of team dat eigenaar is van de wijziging en er verantwoordelijkheid voor neemt. Voor een tekstuele wijziging is dat lijstje kort. Voor core-logica of autorisatielogica niet.

De term 'verification debt' komt van Kevin Browne ^[1]: de opgebouwde kosten van onvoldoende verificatie. Het verschil tussen hoe snel AI output genereert en hoe snel mensen die kunnen controleren, is daarvan een belangrijke oorzaak. Browne beschrijft het breder dan software, van academische papers tot medische diagnoses. Werner Vogels past het toe op software development ^[2], en daar zoomt dit artikel op in. Kostakis Bouzoukas scherpt de definitie op de ACM-blog aan tot de kloof tussen wat je released en wat je hebt aangetoond: technical debt is een weddenschap over toekomstige kosten, verification debt is onbekend risico dat je nu al loopt ^[3].

Technical debt voel je als je de code wilt aanpassen. Verification debt voel je pas als niemand meer durft te releasen.

De twee overlappen, maar leggen de nadruk anders. Technical debt gaat over toekomstige kosten van ontwerp- en onderhoudskeuzes; die schuld ga je soms bewust aan en soms ontstaat hij onbedoeld. Martin Fowler onderscheidt beide varianten in zijn Technical Debt Quadrant ^[4]. Verification debt gaat over uitgesteld controlewerk: vertrouwen dat je niet met bewijs kunt onderbouwen. De code ziet er goed uit, compileert, en de tests slagen. Het happy path wordt meestal nog wel gecheckt. De schuld zit vooral in de randgevallen en uitzonderingen: of de code dáár doet wat je bedoelt, heeft niemand aangetoond.

Technical debt is vaak een lening met een bekende rente.
Verification debt lijkt eerder op een contract dat je tekent zonder de kleine lettertjes te lezen.

	Technical debt	Verification debt
Nadruk	Toekomstige kosten van ontwerp- en onderhoudskeuzes	Uitgesteld controlewerk en onvoldoende onderbouwd vertrouwen
Ontstaat door	Bewuste shortcuts, maar ook onbedoelde keuzes ^[4]	Wijzigingen accepteren zonder voldoende bewijs dat ze doen wat het team bedoelt
Zichtbaarheid	Soms bekend bij het team, soms verborgen in het ontwerp	Verborgen achter groene tests en nette code
Gevolg	Hogere onderhoudskosten en trage feature-delivery	Onvoorspelbare incidenten en slinkende domeinkennis
Pijnpunt	Voel je als je de code wilt aanpassen	Voel je pas als niemand meer durft te releasen
Aanpak	Refactoring en bewust aflossen	Nieuwe schuld beperken en bestaande schuld gericht aflossen (zie hieronder)

De tabel zet het contrast scherp aan; in de praktijk overlappen de twee. Rommelige code is ook lastiger te verifiëren.

Wat je niet controleert, betaal je terug in reviews, bugs en herstelwerk. En hoe meer regels niemand doorgrondt, hoe minder domeinkennis er in het team achterblijft om het systeem over twee jaar nog aan te passen. Het zware werk verschuift van coderen naar reviewen.

Die verschuiving raakt niet alleen het proces, maar ook de developer zelf. Ik zat ineens de hele dag code te lezen die ik niet had geschreven. Het geeft een flow, maar ik mis soms het zelf coderen: een uur in een probleem duiken en puzzelen tot het opgelost is. Je identiteit als developer zat in dat coderen. Niet in het beoordelen ervan. Eerlijk: het voelt alsof je vakmanschap minder waard wordt. Maar juist die jarenlange ervaring maakt je de beste reviewer van AI-code. Vakmanschap verdwijnt niet. Het wordt anders ingezet.

Vakmanschap verdwijnt niet. Het wordt anders ingezet.

Waarom kan AI de schuld zo snel laten groeien?

Niet alleen door het tempo. Drie factoren versterken elkaar:

Meer volume: er komen meer wijzigingen binnen, en de reviewdruk groeit mee.
Minder opgebouwde kennis: wie minder zelf bouwt, doet minder kennis op over de randgevallen die je juist bij een review nodig hebt.
Overtuigende schijn: AI-code oogt syntactisch perfect en netjes gestructureerd, en dat camoufleert logica- en veiligheidsfouten.

Of dat tot schuld leidt, hangt af van hoe je AI inzet:

Experimenteren

Tool gebruiken. Proberen. Nog een keer. De workflow blijft hetzelfde. Je krijgt meer code, maar niet meer grip erop.

Adopteren

Tool integreren. Workflow aanpassen. Snelheid mét controle.

Veel teams blijven hangen bij experimenteren. De cijfers geven dat beeld kleur, al vertellen ze geen compleet verhaal. In de JetBrains-enquête zegt 85% van de developers regelmatig AI te gebruiken voor coding en development ^[5]. In het Sonar-onderzoek is 48% het volledig eens met de stelling dat ze AI-code altijd controleren voor een commit, en 27% enigszins ^[6]; dat is zelfrapportage, en controleren voor een commit zegt nog niets over wat er voor merge of release gebeurt. CodeRabbit vond in 470 onderzochte PR's ongeveer 1,7 keer zoveel reviewbevindingen per PR bij AI-gegenereerde code ^[7]; dat bewijst niet dat alle AI-code slechter is, wel dat reviewers er meer werk aan hebben. En DORA waarschuwt expliciet voor grote AI-wijzigingen en adviseert kleine batches ^[8].

Zonder afspraken kan dat drie kanten op mislopen:

Codebase-fragmentatie

Zonder gedeelde context-files kan elke dev met z’n AI een eigen kant op gaan. Patronen, naamgeving en structuur lopen uiteen. Context-files helpen consistent te blijven, al garanderen ze het niet.

Review-achterstand

Meer output kan de reviewbelasting flink verhogen; hoeveel hangt af van omvang, complexiteit en beschikbare reviewcapaciteit. De druk om snel te approven groeit mee, en niemand wil onbegrepen AI-code reviewen.

Niemandsland

Er komt code bij die niemand heeft geschreven en niemand volledig begrijpt. Wie is eigenaar van code die niemand heeft geschreven? Spreek dat af, hoe de code ook is gemaakt.

Hoe dat er in het klein uitziet, zag ik bij het bouwen aan mijn eigen SaaS. Mijn unit tests stonden op groen. Toch vond een browser-agent die de applicatie doorklikte bugs in een combinatie van invoervelden die bijna niemand gebruikt. Het gewenste gedrag voor die combinatie stond nergens vastgelegd, dus geen test dekte het, en de reviews keken eroverheen. De tests waren groen omdat ze de verkeerde vraag beantwoordden. Pas een controle die het werkelijke gebruik nabootste, maakte de achterstand zichtbaar.

Hoe voorkom je nieuwe verification debt?

Acceptatiecriteria vooraf: leg vast waar de wijziging aan moet voldoen voordat de agent begint met bouwen.
Tests op requirements en risico's: dek de requirements, de randgevallen en de risico's, niet alleen het happy path.
Reviews op logica: beoordeel PR's op aannames en veiligheid, niet op codeerstijl.
Kleine PR's: houd PR's klein en splits ze op, zodat een reviewer de logica kan doorgronden.

Hoe krijg je bestaande schuld er weer uit?

Dat is het lastigere deel, want je weet niet precies waar de schuld zit. Alles alsnog verifiëren kost enorm veel tijd, en overal een beetje controleren voegt weinig toe. Wat wel werkt:

Maak de schuld zichtbaar: selecteer op risico. Kritieke onderdelen eerst, zoals core-logica en autorisatie. Kijk daarna waar incidenten en reverts vandaan komen, en welke delen grotendeels door AI zijn geschreven zonder scherpe requirements vooraf.
Reconstrueer de requirements: schrijf per onderdeel alsnog op wat het moet doen. Een agent helpt hier juist goed: laat hem de code uitleggen, de aannames eronder in kaart brengen, en toets dat aan wat je verwacht. Waar uitleg en verwachting uiteenlopen, heb je schuld gevonden.
Voeg gedragstesten toe: laat AI de randgevallen doortesten met integratie- en e2e-tests die het werkelijke gebruik nabootsen. In mijn eigen SaaS doet een browser-agent dat werk: die vond de bugs die mijn groene unit tests misten.
Beleg eigenaarschap: wijs per onderdeel iemand aan die verantwoordelijk is voor het component en zijn functionaliteit. Vanaf dat moment vallen nieuwe wijzigingen onder de voorkant-afspraken voor nieuwe code.

Plan dit als gewoon werk in het sprintritme: elke sprint een portie, te beginnen bij het hoogste risico. Soms betekent dat tijdelijk minder nieuwe wijzigingen aannemen. En je bent niet klaar als alles geverifieerd is, want dat punt bereik je nooit. Je bent klaar als je de vraag "durven we dit te releasen?" per onderdeel met bewijs kunt beantwoorden.

Houd daarbij signalen in de gaten: doorlooptijd, revert-rate en PR-omvang per sprint. Het zijn signalen, geen directe meting van de schuld; een langere review kan ook betekenen dat er zorgvuldiger wordt gecontroleerd. Maar samen laten ze een groeiende achterstand zien voordat niemand meer durft te releasen. Hoe je dat meet werk ik uit in hoe meet je of AI je team echt helpt?, en de volledige aanpak staat in het AI-adoptie werkmodel. Begin met meten: welke van deze signalen volg je al, en welke nog niet?

Wat is verification debt en waarom bouwt AI het zo snel op?

Wat is verification debt?