AI-adoptie pas je in je sprintritme in. Ik gebruik daarvoor vijf stappen: de Vonk, de Fundering, de Regie, de Versnelling en de Borging. Geen big-bang-traject, maar elke sprint een behapbaar gedeelte, zodat je telkens een stap verder komt. In mijn eigen sprints doet vooral de volgorde ertoe: versnellen zonder Fundering en Regie bouwt al snel schuld op.
Voor wie? De tech lead of squad lead die AI-adoptie als team wil aanpakken, niet als los experiment per developer.
AI-adoptie voelt als een project dat niet in je sprint past. De backlog zit vol, iedereen heeft het druk, en ondertussen verandert het vak in hoog tempo. Teams die wachten op een rustig moment komen nooit van start. Teams die alles tegelijk omgooien, verzuipen in de chaos.
Daarom werkt AI-adoptie het best als sprintritme: elke sprint een behapbaar gedeelte, in een vaste volgorde, zodat je telkens een stap verder komt zonder dat de sprint eronder lijdt. Voor dat ritme gebruik ik een vijfstappenmodel: van de Vonk tot de Borging. Ik pas het toe in mijn eigen sprints. De vraag die dit artikel beantwoordt: welke stap zet je wanneer, en wat gaat er mis als je er eentje overslaat?
Uit welke vijf stappen bestaat het model?
| Stap | Fase | Focus | Kernactiviteit |
|---|---|---|---|
| 1 | De Vonk | Verkennen | Nieuwe tools en mogelijkheden klein verkennen, bijvoorbeeld met een kwartier demo |
| 2 | De Fundering | Kaders voor de AI | Context-files, guardrails, linters en een solide test-suite inrichten |
| 3 | De Regie | Normen voor het team | Afspreken wat AI overneemt en waar reviews over gaan |
| 4 | De Versnelling | Uitvoering | AI in de dagelijkse workflow, met kleine, reviewbare PR's |
| 5 | De Borging | Meten | Elke sprint meten wat het oplevert (zie hoe meet je of AI je team echt helpt?) |
De volgorde is bewust: elke keer dat je een nieuwe AI-tool of mogelijkheid introduceert, zorg je dat de Fundering en de Regie staan voordat je versnelt. De eerste ronde is de zwaarste. Daarna draai je lichtere rondes. Vertrouwen groeit sneller door kleine successen dan door in één keer alles aan de AI te delegeren.
Hoe draait dit mee in je bestaande sprintritme?
AI-adoptie moet geen project erbij worden waar nooit tijd voor is. Het model is bedoeld om mee te draaien in de vaste sprintmomenten die je al hebt:
| Sprintmoment | Stap | Wat je doet |
|---|---|---|
| Sprint planning / refinement | De Vonk | Kies een of twee backlogitems die zich lenen voor een nieuwe AI-tool of -workflow. Geen hele dagen reserveren. |
| Tijdens de sprint | Fundering, Regie en Versnelling | Kaders toepassen en direct bijstellen waar het schuurt. |
| Retrospective | De Borging | Kort evalueren: hielpen de context-files? Waren de PR's goed te reviewen? Lessen mee naar de volgende sprint. |
Tijdens de sprint zie je de stappen in het klein terug. Genereert de AI de verkeerde code, dan pas je direct de context-file aan: Fundering in de praktijk. Blijken PR's te groot en onleesbaar, dan spreek je bij de stand-up af om AI-PR's voortaan op te knippen: Regie. En omdat de kaders er dan staan, pak je op die taken meteen winst: Versnelling.
Het idee erachter: je stopt het normale werk niet, maar past het model toe op story's die toch al op de plank liggen. De feedbackloop blijft kort: een slecht reviewbare AI-PR in de ene sprint leidt tot een scherpere context-file in de volgende. En je geeft de AI pas meer autonomie zodra de Fundering en de Regie uit eerdere rondes stevig staan.
Wat gebeurt er bij Vonk en Fundering?
De Vonk
De eerste keer ontdek je wat AI kan in jouw codebase. In volgende rondes is De Vonk het moment waarop je een nieuwe tool, plugin of mogelijkheid verkent. Hou het klein: denk aan een kwartier demo bij de start van de sprint. Genoeg om bij te blijven, niet genoeg om je team gek te maken. Bij De Vonk bepaal je met elkaar hoe groot de volgende stap is: een kleine plugin, of een fundamenteel andere manier van werken. Dat tempo kies je samen. Maar enthousiasme zonder kaders leidt tot chaos. Daarom volgt direct:
De Fundering (kaders voor de AI)
In de eerste ronde leg je vast hoe de code eruitziet:
- Context-files: leg conventies en architectuurkeuzes vast in bijvoorbeeld
AGENTS.md,CLAUDE.md,copilot-instructions.mdof.cursorrules. - Guardrails: alles wat de AI binnen de lijnen houdt: pre-commit hooks, CI-linter-regels en je test-suite.
- Tests eerst: zonder tests heeft de AI geen feedbackloop. Lage test coverage + AI = code die je niet naar productie durft te brengen.
Kwaliteitsvalkuil: als een team met AI aan de slag gaat, daalt de kwaliteit vaak eerst. Je genereert sneller, maar de fouten nemen toe. Dat moet je verderop in het proces opvangen: scherpere PR reviews, meer automatische tests, browser tests, en strengere acceptatie.
Juist daarom niet te grote stappen zetten. Hier stokt het vaak: het voelt als overhead. Maar context-files zijn geen documentatie die niemand leest: je merkt direct als ze verouderd zijn, want de AI-output wordt slechter. Dat is een ingebouwde feedbackloop. En zonder die investering genereert je AI sneller rommel dan je kunt opruimen.
Bij elke volgende ronde van de cyclus scherp je De Fundering aan: nieuwe richtlijnen, betere tests, strengere guardrails.
Hoe bouw je zo’n context-file op? In hoe je zo'n context-file opbouwt laat ik stap voor stap zien hoe je 'm opzet, splitst naar regelbestanden en onderhoudt.
Wat gebeurt er bij Regie en Versnelling?
De Regie (normen voor het team)
In de eerste ronde bepaalt het team de normen. Vóór je gaat versnellen met AI. “Wij stoppen met het reviewen van code-conventies. Die horen in de context-file. Reviews gaan over architectuur en logica.” Verwacht hier discussie: wat is een conventie en wat is een architectuurkeuze? Naamgeving is een conventie. Maar “altijd via de repository-laag” is een architectuurkeuze die eruitziet als een conventie. Die grens trekken is de regie.
- Review-focus: stijl- en naamgevingsdiscussies verdwijnen van de reviewtafel; die horen in linters en context-files. Reviews gaan over architectuur, veiligheid en logica.
- Vakmanschap: het kan de senior van stijlpolitie veranderen in bewaker van het systeem. AI genereert code die werkt voor nu, maar een senior ziet of het ook werkt bij 10x meer gebruikers.
- Aanscherpen: in volgende rondes: wat werkte, wat niet, welke afspraken moeten strakker? Zonder Regie wordt De Versnelling rommelig.
De Versnelling (AI in je workflow)
In De Vonk heb je verkend wat er mogelijk is. Nu voer je het uit. De AI werkt zelfstandig in de codebase, runt tests, doet voorstellen. Hoeveel dat is hangt af van hoe sterk je Fundering en Regie staan. Die kaders houden je veilig.
- Kleine PR's: AI nodigt uit tot grote, monolithische wijzigingen. Stuur daar bewust tegenin en laat de AI taken opknippen in kleine, reviewbare PR's. Wie grote brokken AI-code over de schutting gooit, respecteert de tijd van de reviewer niet.
- Kortere doorlooptijden: sneller typen levert niks op. De versnelling zit in minder wachttijd, meer parallelle taken en snellere iteraties. En hoe scherper de spec, hoe minder je achteraf hoeft te reviewen.
- AI-review als voorcheck: naarmate je Regie sterker wordt, kun je AI-review-tooling inzetten voor de eerste check. De mens blijft eindverantwoordelijk.
Wat gebeurt er bij de Borging?
De Borging (meten wat het oplevert)
Elke sprint meet je wat de nieuwe werkwijze oplevert: doorlooptijd, revert-rate, PR-omvang en de velocity-trend. In de retrospective bespreek je de trend, niet het losse getal, en neem je de lessen mee naar de volgende ronde. Zo zie je of de versnelling zich uitbetaalt, of dat je vooral drukker bent geworden.
De volledige uitwerking, met de vier metrics en hoe je begint met meten, staat in hoe meet je of AI je team echt helpt?
Waarom doet de volgorde ertoe?
De volgorde is niet vrijblijvend: sla je de Fundering en de Regie over en ga je meteen naar de Versnelling, dan versnel je zonder kaders. Dat bouwt binnen een paar sprints verification debt op, code die wel gemerged is maar niet geverifieerd. Begin dus klein, in je eigen sprintritme: eerst de kaders, dan pas het gas erop.
