Bijna elk dev-team heeft tegenwoordig AI in de toolstack. Maar weinig teams weten die lawine aan AI-code om te zetten in meer features in productie. Code produceren is het probleem niet meer. Begrijpen wat er geproduceerd is, dat is de uitdaging.
Voor wie? De tech lead of senior developer die ziet dat het team blijft hangen in AI-experimenten en de controle terug wil over de codebase.
Leeswijzer Dit is het overzichtsartikel van de reeks: je krijgt hier de hele lijn, en per onderdeel linkt het door naar een verdiepend artikel.
De release van maart 2026: 57 PR's, 446 commits, 568 bestanden. Grotendeels AI-gegenereerd. 4 microservices, 1 frontend en 1 website die tegelijk live moeten. Alles compileert. De tests slagen.
De realiteit: durf je te releasen? We snappen wat de code doet, maar we doorgronden niet meer waarom het klopt.
Dat gevoel is de geboorte van verification debt: als je team meer genereert dan het kan reviewen, bouw je een schuld op die vaak lastiger te herkennen is dan technical debt.
Waarom is meer AI-code niet automatisch meer resultaat?
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. De code compileert en de tests slagen, maar het vertrouwen is niet onderbouwd. Veel teams blijven hangen in experimenteren: meer code, maar niet meer grip erop. Waar verification debt ontstaat en hoe je het aflost, leg ik uit in wat is verification debt en waarom bouwt AI het zo snel op?
Het moeilijkste deel is niet de techniek
Wat gebeurt er als je zelf al verder bent met AI dan de rest van het team? Er ontstaat frictie over het tempo: een senior die AI wantrouwt heeft vaak gelijk. Hoe je die weerstand aanpakt, beschrijf ik in AI-weerstand in je dev-team: waarom de discussie muurvast zit, en hoe teams omgaan met wie niet vooraan rijdt in vijf gesprekken over de kopgroep en het peloton.
Wat is er bij mij veranderd?
Na 20+ jaar development dacht ik mijn manier van werken al te kennen. Sinds augustus 2025 werk ik met Claude Code, GitHub Copilot en Codex: assistenten die zelfstandig in mijn codebase werken terwijl ik specificeer, review en bijstuur. Hoe dat er dagelijks uitziet, beschrijf ik in mijn artikel over mijn workflow met Claude Code.
Hoe pak je het aan?
Er bestaan uitgebreide modellen voor AI in software teams, zoals ELEKS AI-SDLC en DORA. In mijn eigen SaaS werk ik met een model in vijf stappen: de Vonk (kort verkennen), de Fundering (context-files en tests op orde), de Regie (het team bepaalt de reviewnormen), de Versnelling (AI zelfstandig binnen die kaders) en de Borging (elke sprint meten wat het oplevert). Neem dit model niet blind over: het is een werkmodel dat ik nog wil toetsen bij teams. De uitwerking per stap staat in hoe pak je AI-adoptie aan? Het vijfstappenmodel.
De cyclus draait niet vanzelf: vier petten (architectuurcoach, mentor, champion, tuinman) houden hem in beweging. Ik werk dat uit in Agentic coding verandert de rollen in je team: van samen bouwen naar samen sturen.
Zonder meten weet je niet of je vooruitgaat. Ik kijk per sprint naar vier metrics: doorlooptijd per PR, revert-rate, PR-omvang en de velocity-trend. De uitwerking, inclusief hoe je de teamervaring meeneemt, staat in hoe meet je of AI je team echt helpt?
Het snelle ritme: elke dag
Naast deze cyclus per sprint draait er een kleiner vliegwiel: specificeren, delegeren, reviewen, bijsturen, dagelijks uitgewerkt in mijn artikel over mijn dagelijkse workflow.
Eén valkuil verdient extra aandacht: controleer niet alleen de code, maar ook de tests. Als de AI code én tests schrijft zonder goede specs, ontstaat schijnzekerheid: tests die groen zijn maar het verkeerde testen. De coverage ziet er goed uit, maar de aannames kloppen niet. Dat is een echokamer. Review of de tests de juiste aannames en edge cases valideren, of dat ze alleen de coverage ophogen.
Wat verandert er en wat levert dit op?
In het begin voelt het tegennatuurlijk: je besteedt meer tijd aan sturen en reviewen dan aan meters maken. Maar naarmate je specs scherper worden en je Fundering staat, kantelt het. De reviewlast daalt, je specificeert preciezer, en de rest gaat meer vanzelf. De totale output kan omhoog, omdat je delegeert in plaats van zelf te coderen.
Wat er verandert, is het dagelijkse werk, de rollen en de vragen die je stelt:
- Je besteedt meer tijd aan specificeren dan aan coderen, en AI helpt je om vage requirements scherper te formuleren
- De review wordt breder: naast de code beoordeel je ook de intentie, de aannames en het geleverde bewijs
- Veel eenvoudige, afgebakende bugs lost AI zelfstandig op. Complexe bugs worden lastiger: je debugt code die je niet zelf hebt geschreven
- De junior kan sneller leren met AI, mits hij zelf blijft reconstrueren en een mentor houdt
- De senior verschuift van codeur naar architectuurcoach: kaders bepalen en risicovolle beslissingen beoordelen
Dat klinkt als veel. Neem het stap voor stap. Als de kaders staan en iedereen weet wie wat reviewt, ontstaat het vertrouwen om meer aan de AI te delegeren. Het team dat het meest investeert in de Fundering, durft uiteindelijk het meest te versnellen.
Waarom het niet stopt
AI-adoptie is continu werk: elke sprint scherp je richtlijnen aan en groeit het vertrouwen. Maar zonder onderhoud val je terug:
- Codebase-vervuiling: AI introduceert patronen die niet bij je architectuur passen. Zonder de tuinman sluipen afwijkingen erin die je pas merkt als het te laat is. En wie onderhoudt die code over twee jaar als niemand meer weet waarom het zo is gebouwd? 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 workflow veranderen continu: de tools van vandaag zijn niet die van volgend kwartaal. En nieuwe mogelijkheden vragen om aanpassingen in je workflow. De richting is duidelijk: meer autonomie, meer orkestratie, 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.
AI-adoptie is geen optionele plugin. Het is een verandering in mindset. Teams die het gesprek over hoe ze AI inzetten laten liggen, verliezen terrein zonder het te merken.
Waar begin je?
Wil je vandaag beginnen? De Vonk (stap 1) heeft je team waarschijnlijk al gehad: er wordt al geëxperimenteerd. Begin dus bij de Fundering: maak een context-file aan en los daar één gedeelde frustratie in op. Bijvoorbeeld: “geen business logic in controllers, altijd via een servicelaag.” Eén bestand, één regel. Kijk wat er verandert.
Loop je vast bij De Fundering (wat leg je vast?), De Regie (wie doet wat?) of De Borging (hoe meten we kwaliteit?)? Zullen we een uurtje sparren over jullie workflow? Zonder zwaar traject eraan vast: gewoon een gesprek waarin ik deel wat ik zelf heb geleerd.
En die release PR?
Die release met 57 PR's, 446 commits en 568 bestanden? Ik durfde te releasen. Niet omdat ik alles in één keer had gelezen. Die 57 PR's zijn over weken gemaakt, elk gereviewd op het moment dat ze klaar waren, samen met Claude Code en GitHub Copilot. De release bundelt ze achteraf. En de guardrails waren op orde. 1.253 unit tests groen op dat moment. Acht uur automatische browsertests slaagden ook, 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: het vertrouwen was opgebouwd, en De Fundering werkte. In de screenshot zie je het contrast: de review-comment “ik snap wat het doet, maar niet waarom het klopt” naast de context-files die de AI sturen. Van angst naar vertrouwen. Dat begint bij De Fundering.
AI maakt output goedkoop. Maar verantwoordelijkheid niet. AI-adoptie is geen project dat je afrondt. Het is een workflow die bepaalt of je team versnelt of vastloopt.
Welke regel voeg jij vandaag toe aan je context-file om met meer grip te releasen?
