Drie getallen, met hun bron
Drie onderzoeken uit de afgelopen twee jaar beschrijven hetzelfde beeld vanuit verschillende hoeken. Harness rapporteerde in 2025 dat 72 % van de ondervraagde teams al een productie-incident had gehad door code van AI. Faros AI vond in 2026 dat 31,3 % van de pull requests zonder enige review werd samengevoegd. GitClear mat in 2025 dat gedupliceerde codeblokken vier tot acht keer vaker voorkwamen dan vóór AI. En het DORA-rapport van 2025 vatte het mechanisme in één zin: AI versterkt de engineeringcultuur die er al is.
Dit zijn andermans getallen over andermans teams. Ze zeggen niets over onze gates. Wat ze wel zeggen, is waar je moet kijken.
Vier gedaanten van dezelfde schuld
Het gedupliceerde blok
Een agent die een hulpfunctie niet ziet, schrijft er zelf een. En dan nog een. Drie maanden later zijn er vijf manieren om een datum op te maken, allemaal net anders, allemaal met hun eigen bug. Niets is rood. De gate die het tegenhoudt: statische analyse met duplicaatdetectie aan, blokkerend boven een drempel in plaats van rapporterend.
De test die niets bewijst
Een test die de code aanroept, controleert dat er geen exceptie kwam, en groen wordt. De dekking gaat omhoog. De veiligheid niet. De gate die het tegenhoudt: mutatietesten op elke nieuwe test. De test moet rood worden als de code die hij test wordt veranderd, anders telt hij niet.
De merge die niemand las
Een pull request die er goed uitzag, van een agent die zelfverzekerd klonk, op een vrijdag samengevoegd. De gate die het tegenhoudt: een sceptische tweede agent beoordeelt vóór een mens, en de mergeknop werkt alleen als de gate groen is, nooit op vertrouwen.
Het geheim in de historie
Een werkende connection string in een configbestand geplakt om een test lokaal groen te krijgen. De gate die het tegenhoudt: een secretscan in de pre-commit hook en nog eens bij de push, blokkerend, met bestand en regelnummer.
Waarom het erger is dan gewone schuld
Gewone technische schuld kondigt zichzelf aan: de code is lelijk, de tests zijn traag, iemand klaagt. Agentic schuld is beleefd. Hij houdt zich aan de linter, hij heeft een test, hij leest lekker weg. De persoon die het vroeger zou hebben opgemerkt (degene die het schreef) heeft het niet geschreven. De enige verdediging is dus structureel: checks die bij elke wijziging draaien, wat iemand er ook van vindt, en de regel dat elke gevonden fout een check wordt die hem de volgende keer vindt.
Waar je begint
Kijk naar de laatste twintig merges op je drukste repository. Tel hoeveel er door een mens zijn beoordeeld, hoeveel nieuwe tests een mutatie zouden overleven, en hoeveel hulpfuncties twee keer bestaan. Dat is een ochtend werk en het beslecht meestal de discussie. Laat je het liever door ons doen, dan leest een Hardening Audit je app zoals een aanvaller en een auditor dat doen, op volgorde van wat het eerst pijn doet, en vertelt hij je wat je moet repareren.