Mijn laatste release PR. 57 PR's, 446 commits, 568 bestanden. Grotendeels AI-gegenereerd. Alles compileert. Tests slagen. Maar begrijp je het geheel? Durf je te releasen? Ik snap wat het doet, maar niet waarom het klopt.
Je team heeft GitHub Copilot. Misschien Claude Code of Cursor. Iedereen heeft het geprobeerd. En toch, als je eerlijk kijkt, levert het team niet meer op dan een half jaar geleden. Je team genereert meer code, maar shipt niet meer features. Herkenbaar?
Ik heb die PR wél gereleased. Aan het eind van dit artikel vertel ik waarom. Maar eerst: hoe je leert vertrouwen op AI-gegenereerde code. Niet blind, maar onderbouwd.
Na 20+ jaar development had ik mijn manier van werken. Lange tijd gebruikte ik code-analyse tools en later GitHub Copilot voor autocomplete en de ingebouwde chatfunctie in mijn IDE. Handig. Mijn output bleef hetzelfde.
Tot ik in september 2025 overstapte naar Claude Code in de CLI. Niet als slimmere autocomplete in mijn IDE, maar als een assistent die zelfstandig in mijn codebase werkt: code genereren, tests draaien, refactoren. Ik specificeer, review en stuur bij. De AI doet het werk.
Dat veranderde alles. Niet de tool, maar wat die tool van mij vraagt. En dat is precies waar het voor de meeste teams misgaat.
Experimenteren vs adopteren
Het verschil klinkt klein, maar het is groot:
Experimenteren
Tool aanzetten. Geen resultaat. Afhaken.
Adopteren
Tool integreren. Werkwijze aanpassen. Versnelling.
De cijfers bevestigen dat beeld. Bijna elke developer gebruikt AI [1], maar minder dan de helft reviewt altijd voor commit [2], en PRs worden steeds groter [3]. Dat hoeft niet per se door AI te komen, en grotere PRs zijn niet per definitie slechter. Maar het patroon is herkenbaar: AI maakt het verleidelijk om meer code te genereren dan je kunt reviewen, en die code bevat meer issues [4]. Dat creëert review-druk.
Kevin Browne en Werner Vogels noemen dit verification debt [5][6]: de kloof tussen hoe snel AI code genereert en hoe snel je die kunt begrijpen. Bij technical debt weet je wat je inlevert: je kiest bewust voor snelheid boven kwaliteit. Die schuld ken je. Bij verification debt is dat anders. De code ziet er goed uit, compileert, en de tests slagen. Maar niemand heeft elke regel doorgrond.
Technical debt is een lening die je bewust aangaat. Je weet wat je terugbetaalt.
Verification debt is een contract dat je tekent zonder de kleine lettertjes te lezen.
En wat je niet begrijpt, dat betaal je terug in reviews, bugs en herstelwerk. Het gevolg: het zware werk verschuift van coderen naar reviewen. Dat is wennen. Je identiteit als developer zat in het coderen, niet in het beoordelen. En eerlijk: het voelt alsof je vakmanschap minder waard wordt.
Waarom is AI-snelheid een risico?
AI-snelheid zonder guardrails (kaders die bepalen hoe de AI werkt) leidt tot drie gevaren:
Context-erosie
Zonder gedeelde context-files (CLAUDE.md, .cursorrules, copilot-instructions.md) gaat elke dev met z’n AI een eigen kant op. Elke PR ziet er anders uit. Patronen, naamgeving, structuur: niets is meer consistent.
Review-moeras
AI genereert sneller en meer. PR’s worden groter en bevatten meer issues [4]. Reviewen vraagt daardoor meer inspanning, niet minder. En de druk om snel te approven groeit mee. Dat is verification debt: de code gaat sneller dan het begrip.
Vertrouwensgat
Er komt code bij die niemand heeft geschreven en niemand volledig begrijpt. Bugs duiken op waar je ze niet verwacht. En wie is eigenaar van code die niemand heeft geschreven? Zonder antwoord op die vraag daalt het vertrouwen snel.
Deze gevaren zijn technisch. Maar het meest complexe deel is menselijk. Ik herken dit uit eigen ervaring. Wat gebeurt er als je zelf al verder bent met AI dan de rest van het team? Er ontstaat frictie. Niet over de tooling, maar over het tempo. Jij ziet de mogelijkheden. Je team ziet alleen enorme PR's en denkt: moet dit echt zo? Hoe neem je ze mee zonder te gaan duwen? Hoe voorkom je dat senior devs in de weerstand schieten? En wie bepaalt eigenlijk het tempo?
Het eerlijke antwoord: een senior die AI wantrouwt heeft vaak gelijk. AI-output is niet betrouwbaar genoeg om blind te vertrouwen. Dat is geen weerstand, dat is vakmanschap. De kunst is om die kritische blik productief te maken: laat die senior de kwaliteitsnormen bepalen voor AI-output. Niet “gebruik het nu”, maar “onder welke voorwaarden zou jij dit accepteren?” Dat verandert het gesprek van dwang naar eigenaarschap.
Hoe pak je dat aan? Niet met een betere tool, maar met een gedeelde aanpak.
De AI-Adoptie Cyclus
Er bestaan uitgebreide maturity models voor AI in software teams (ELEKS, Microsoft CMM). Die vertellen je waar je staat. Wat volgt is geen theorie, maar een praktische werkwijze die je per sprint kunt toepassen. Zie het als een werkwijze, geen framework. Dit model is gebouwd vanuit mijn eigen ervaring en gesprekken met andere developers. Ik heb het nog niet bij een team toegepast. Het is een werkmodel, geen bewezen methode.
Voordat je verder leest
Wie zijn tests op orde heeft, zijn architectuur begrijpt en scherpe prompts schrijft, is al halverwege. Dit model is geen extra proces bovenop je werk. Het is een manier om als team af te spreken hoe je met AI werkt.
Als solo developer heb je dat niet nodig. In een team van vijf wel, want dan is de vraag niet “kan ik dit?” maar “doen we dit samen op dezelfde manier?”
En wacht niet tot het model compleet is voordat je begint. Eén senior die op maandagochtend een halfuur met het team zit en twee regels aan de context-file toevoegt, is al genoeg om te starten. De vijf stappen hieronder zijn geen voorwaarde om te beginnen. Ze zijn een kaart voor als je verder wilt.
De aanpak werkt op twee niveaus. Per sprint doorloopt het team vijf stappen. Per dag werkt elke developer in een eigen ritme van specificeren, delegeren, reviewen en bijsturen. Eerst de AI-Adoptie Cyclus: vijf stappen die je bewust gedoseerd doorloopt. Niet te snel, zodat ieder teamlid het kan bijbenen: de enthousiaste junior en de terughoudende senior.
De vijf stappen
Doorloop de eerste keer de hele cyclus intensief. Daarna draai je elke sprint een lichtere versie: richtlijnen aanscherpen, afspraken bijstellen, nieuwe tools uitproberen.
De Vonk
Je ontdekt wat AI kan in jouw codebase. Iedereen enthousiast, maar nog geen echte verandering. In volgende rondes wordt dit: af en toe een nieuwe plugin of mogelijkheid uitproberen. Niet tien tools tegelijk, maar een kwartier demo in de retro. Genoeg om bij te blijven, niet genoeg om je team gek te maken.
De Fundering (richtlijnen voor de AI)
Je legt vast hoe de code eruit moet zien. Context-files voor je AI-tool (CLAUDE.md, .cursorrules, copilot-instructions.md), code guidelines, architectuurkeuzes. Guardrails zijn niet alleen documenten: denk ook aan pre-commit hooks en CI-linter regels die je richtlijnen automatisch afdwingen. En cruciaal: je test-suite. Zonder tests heeft de AI geen feedbackloop. Lage test coverage + AI = code die je niet naar productie durft te brengen. Hier haken veel teams af. Het voelt als overhead. Maar het is de reden dat de AI straks doet wat je bedoelt, niet wat hij denkt.
De Regie (normen voor het team)
Vóór je gaat versnellen met AI: het team bepaalt de normen. “Wij stoppen met het reviewen van code-conventies. Die horen in de context-file. Reviews gaan over architectuur en logica.” Hier ontstaan discussies: wat is een conventie en wat is een architectuurkeuze? Die grens trekken is de regie. En het geeft de senior zijn vakmanschap terug: geen discussies meer over naamgeving, maar focus op de robuustheid van het systeem.
Drie rollen zijn cruciaal:
- De senior als gatekeeper: een senior die zich een veredelde linter-robot voelt, haakt af. Terecht. De kunst is niet overtuigen, maar de rol herdefiniëren. De senior verschuift van schrijver naar bewaker: hij reviewt op architectuur en logica, niet op conventies. Niemand kent de codebase beter. Dat geeft ownership over de kwaliteit van AI-output, in plaats van het gevoel dat AI zijn rol overneemt.
- De junior als leerling: AI versnelt het coderen, maar vertraagt vaak het leren. Een junior moet vlieguren maken in het zelf schrijven van code om de intuïtie te ontwikkelen die nodig is voor een kritische review. Zonder die basis wordt hij een passief doorgeefluik van AI-output, en groeit de verification debt met elke PR. De uitdaging: laat juniors eerst zonder AI aan een taak beginnen, of laat ze de AI om uitleg vragen in plaats van code. Zo wordt AI een tutor die het denkwerk aanscherpt, niet een vervanger die het overneemt.
- De champion als tuinman: AI introduceert patronen die niet bij je architectuur passen. Zonder iemand die dat signaleert, verspreidt het zich als onkruid door je codebase. De champion voorkomt nieuw onkruid door de context-files en richtlijnen bij te houden. Bestaande vervuiling opruimen is teamwerk in de sprint. Geen aparte rol, maar een vaste deeltaak. Net als je CI-pipeline: niemand heeft dat als fulltimebaan, maar als niemand het doet, loopt alles vast.
Zonder die aandacht vervuilt de AI-context: verouderde richtlijnen leiden tot output die niet meer past bij hoe jullie bouwen, en de verification debt groeit. Zonder regie wordt de versnelling rommelig.
De Versnelling (AI in je workflow)
Elke sprint geef je de AI meer verantwoordelijkheid. Eerst kleine taken, dan grotere. Van coderen naar delegeren. De AI werkt zelfstandig in de codebase, runt tests, doet voorstellen. Hoeveel je loslaat hangt af van hoe sterk je fundering en regie staan. Die kaders houden je veilig. Belangrijk: AI nodigt uit tot grote, monolithische wijzigingen. Stuur daar bewust tegenin. Instructeer de AI om taken op te knippen in kleine, reviewbare PR's. De versnelling zit niet in sneller typen, maar in kortere doorlooptijden: minder wachttijd, meer parallelle taken, snellere iteraties. En naarmate je regie sterker wordt, kun je ook AI-review tooling inzetten voor de eerste check op conventies en patronen. De mens blijft eindverantwoordelijk voor architectuur, logica, en het beoordelen of de AI-review zelf klopt.
De Borging
Zonder meten weet je niet of je vooruitgaat. Meet vier dingen: de review-tijd, de revert-rate, het aantal post-review bugs en de PR-omvang. Die laatste is cruciaal: als PR's groeien terwijl je AI inzet, schaalt je review niet mee. Geen dashboard nodig. Een korte check in de retro is genoeg.
Waar let je op? Als de review-tijd stijgt terwijl de output gelijk blijft, groeit je verification debt. De echte test: gaat de snelheid omhoog zonder dat de kwaliteit daalt?
Daarnaast: zijn de richtlijnen nog up-to-date? Werken de afspraken nog? Ik verwacht dat dit het punt is waar het vaak verslapt. Zonder evaluatie sluipt de luiheid erin. Maar als je het wel doet, voedt elke retro de volgende ronde van de cyclus. Juist door in de retro ook aandacht te hebben voor De Vonk: een korte demo van een nieuwe AI-tool of feature. Zo blijft de cyclus draaien.
Het snelle ritme: elke dag
Naast deze cyclus per sprint draait er een kleiner vliegwiel. Dit is hoe je dagelijks met AI werkt:
Dit ritme draait continu. Specificeren wordt steeds preciezer naarmate je fundering beter staat. Reviewen wordt makkelijker naarmate je regie klopt. En bijsturen voedt de borging. Hoe ik dat concreet zelf toepas beschrijf ik in mijn artikel over mijn dagelijkse workflow.
Voorbeeld uit de praktijk
De AI genereert een service die rechtstreeks de database aanroept in plaats van via je repository-laag. Je stuurt bij, maar de volgende keer maakt hij dezelfde fout.
Dat is het moment dat je een regel toevoegt aan je context-file: “gebruik altijd de repository-laag, nooit rechtstreeks de database.” Vanaf dat moment gaat het goed.
Dat is waar de twee niveaus elkaar raken: je reviewt en stuurt bij (het dagelijkse ritme), je scherpt de fundering aan (de cyclus), en in de retro bespreek je met je team of die aanpassing goed genoeg is (de borging).
Wat levert dit op?
Snellere iteraties doordat je delegeert in plaats van zelf schrijft. En kwaliteit die niet daalt, mits je fundering staat: gedeelde richtlijnen maken de AI-output consistent, je test-suite geeft de AI een feedbackloop, en kleinere opdrachten dwingen je scherper na te denken over structuur.
Zonder die fundering daalt de kwaliteit juist. Dat is het verschil tussen experimenteren en adopteren.
Waarom het niet stopt
AI-adoptie is een opwaartse spiraal: elke sprint scherp je richtlijnen aan, worden reviews makkelijker en groeit het vertrouwen. Maar als je stopt met bijsturen, keert de spiraal om:
- Codebase-vervuiling: AI introduceert patronen die niet bij je architectuur passen. Zonder de tuinman uit stap 3 verspreidt het zich als onkruid. Tegelijk verouderen je context-files: je code verandert, maar de richtlijnen niet. Context-files bijwerken is net zo belangrijk als je tests bijwerken.
- Tooling en werkwijze veranderen continu: de tools van vandaag zijn niet die van over drie maanden. En nieuwe mogelijkheden vragen om aanpassingen in je werkwijze. De richting is duidelijk: meer autonomie, meer orchestratie, meer agents die samenwerken. Hoe langer je wacht, hoe groter de achterstand.
- Team-discipline: zonder evaluatie sluipt het blind op “Approve” klikken bij een review erin. De kwaliteit daalt en er glippen meer issues ongezien door de PR.
Waar begin je?
Het knelpunt verschuift van code schrijven naar code begrijpen. Ik denk dat teams die dat snappen, vooroplopen.
Wil je vandaag beginnen? Maak een context-file aan en los daar één gedeelde frustratie in op. Bijvoorbeeld: “gebruik altijd de repository-laag, nooit rechtstreeks de database.” Dat is stap 2. Eén bestand, één regel. Kijk wat er verandert.
Loop je daarna vast bij de regie of de borging? Ik zoek teams om dit model in de praktijk te toetsen en praat daar graag over.
En die release PR?
Kijk nog eens naar de screenshot bovenaan dit artikel. Die release PR met 57 PR's, 446 commits en 568 bestanden? Ik durfde te releasen. Niet omdat ik elke regel had gelezen, maar omdat ik elke PR had gereviewd samen met Claude Code en GitHub Copilot, en omdat de guardrails op orde waren. 1200 unit tests groen. 8 uur automatische browser tests slaagden na enig rework. En na de release: het aantal post-review bugs viel mee bij de acceptatietest, en de PR-omvang per wijziging bleef klein.
De metrics uit stap 5 bevestigden wat ik voelde: de fundering werkte. De wijziging die je in de screenshot ziet gaat precies daarover: de context-file (in dit geval: CLAUDE.md) met de richtlijnen die dat mogelijk maakten. Daar begint het. Van “ik snap wat het doet, maar niet waarom het klopt” naar “ik durf te releasen.”
AI-adoptie is geen project dat je afrondt. Het is een werkwijze die bepaalt of je team versnelt of vastloopt.
Lees ook: Hoe Claude Code mijn .NET development-workflow versnelt
