Governance voor vibe coding: een schillenmodel voor AI-assisted coding
30 juni, 2026
Farisch Hanoeman
DE VRAAG IS NOOIT OF JE AI-ASSISTED CODING TOESTAAT, MAAR WAAR JE WAT TOESTAAT
Figuur 1: Een developer beoordeelt AI-gegenereerde code voordat deze naar productie gaat.
Een collega van de financeafdeling bouwde vorige maand in een middag een dashboard dat het managementteam nu elke week gebruikt. Geen developer, geen ticket. Ze beschreef in gewone taal wat ze wilde zien, een AI-agent schreef de code, en het werkte. Een week later liet een developer in een ander team een agent een databasewijziging draaien op de productieomgeving. De agent verwijderde een kolom waar drie andere systemen op leunden. Een halve dag downtime.
Allebei is het vibe coding. Allebei is het AI-assisted coding. Het verschil zit hem in waar de code terechtkomt. Dezelfde tool, een even handige persoon, en toch een wereld van verschil in wat er misging.
De termen lopen trouwens door elkaar, en dat geeft niet. Vibe coding gaat meestal over snel iets werkends bouwen door een AI in gewone taal aan te sturen. AI-assisted coding is breder, een developer die een agent als hulp inzet binnen een bestaand project. Agentic engineering legt de nadruk op agents die grotere stukken zelfstandig oppakken. Voor de governance maakt dat onderscheid weinig uit. Zodra een AI code schrijft die in jouw systemen draait, telt maar één ding: wat er kapot kan en hoeveel controle daarbij hoort.
De meeste organisaties reageren op een van twee manieren. Of ze verbieden het, omdat het onveilig voelt. Of ze laten het volledig los, omdat de snelheid te mooi is om te negeren. Beide kosten je op termijn geld. Een verbod jaagt je slimste mensen naar schaduw-IT, waar je geen zicht meer op hebt. Vrijheid zonder kaders levert een berg code op die niemand begrijpt, een vorm van technische schuld die je straks niet meer durft aan te raken.
Er is een tussenweg. Die begint met een simpele vraag: hoeveel schade richt deze code aan als hij faalt?
Risico hangt af van waar de code landt
Stel je je software voor als een set ringen rond een kern. In het midden zit alles waar je bedrijf op draait. De database, de authenticatie, de betaalstromen, je ERP of kernadministratie. Een fout hier plant zich voort door alles wat eraan hangt. Verlies je data of breek je een interface, dan vallen processen stil die niets met die ene wijziging te maken hadden.
Daaromheen ligt een eerste ring. Hier zitten de interne integraties en API’s, de services die de kern uitlezen en er soms naar terugschrijven. Denk aan een koppeling die ordergegevens uit het ERP haalt en doorzet naar een planningssysteem. Faalt die koppeling, dan heb je een probleem, maar je kernadministratie blijft overeind.
De buitenste ring is het terrein van dashboards, rapportscripts en losse analyses. Deze code leest gegevens uit de kern en schrijft er niets naar terug. Het dashboard van de financecollega hoort hier. Gaat het stuk, dan klopt een grafiek niet en draai je het terug. Vervelend, geen ramp.
Wat dit model laat zien is dat software governance geen uniform jasje is dat je over je hele codebase trekt. De kern verdient strenge controle. De buitenste ring vraagt om een handvol afspraken en verder rust. AI governance werkt op dezelfde manier: je stemt de mate van controle af op wat er kapot kan gaan.
Figuur 2: Drie schillen, drie regimes. De mate van controle volgt de straal van de explosie bij een fout.
Wat een lek kost, en wat snelheid oplevert
De verleiding van vibe coding is echt. Een analist die zelf een rapportagescript schrijft, wacht niet drie weken op de backlog. Een team dat met agentic engineering een integratie opzet, levert in dagen wat vroeger een maand kostte. Die snelheid is waar het om draait.
Snelheid in de kern is alleen een ander beest dan snelheid aan de rand. Reken het ruwweg door. Een kapot dashboard kost je een middag herstel. Een verkeerde migratie op je productiedatabase kost je een week, plus het vertrouwen van iedereen wiens proces stillag. Een API-sleutel die een agent per ongeluk in een publieke repository plaatst, kan je maanden bezighouden, met in het ergste geval een datalek dat je moet melden.
Het verschil is de straal van de explosie. Code aan de rand heeft een kleine straal. Code in de kern raakt alles. Je governance hoort die straal te volgen. De hoeveelheid code of de afdeling die hem schreef, doet er veel minder toe.
Wil je hier meer mee doen?
Governance per schil, concreet gemaakt
Zo ziet een werkbare verdeling eruit.
In de kern (rood) laat je geen wijziging los zonder menselijke review door iemand met seniorervaring. Geautomatiseerde tests moeten groen zijn voordat er iets naar productie gaat. Een agent krijgt hier geen directe schrijfrechten op de productieomgeving, hooguit op een afgeschermde testomgeving. Secrets en sleutels komen uit een kluis, nooit uit de code zelf. Elke wijziging heeft een naam eronder, iemand die tekent voor het resultaat.
In de eerste ring (oranje) mag het lichter. Een peer review door een teamgenoot volstaat, zolang er tests draaien op de integratie zelf. Wijzigingen gaan eerst naar een staging-omgeving voordat ze live komen. De agent mag hier meer, mits een mens de pull request bekijkt voor de merge.
In de buitenste ring (groen) houd je het tot een minimale set. Drie afspraken volstaan meestal. Secrets staan nooit hardcoded in de code. De databasetoegang is read-only, zodat een script per definitie niets in de kern kan breken. En iemand kijkt kort mee voordat het in gebruik gaat. Verder geef je mensen de ruimte. Dat is precies de plek waar vibe coding het meeste oplevert en het minste kan slopen.
Let op die read-only toegang in groen. Die ene regel doet veel werk. Hij maakt het technisch onmogelijk dat een dashboardscript de kern raakt, ook als de AI iets geks verzint. Goede governance leunt op dit soort grenzen die je niet per ongeluk kunt overschrijden, in plaats van op een document dat iedereen uit zijn hoofd moet kennen.
Twee situaties bij één fictief bedrijf
Neem Bergveld Logistiek, een verzonnen transporteur met een eigen planningssysteem en een datawarehouse.
Situatie één. Een planner wil weten welke ritten structureel te laat vertrekken. Ze beschrijft het probleem aan een AI-agent en bouwt in een middag een dashboard dat de werkelijke vertrektijden tegen de planning afzet. Dit is buitenste-ring werk. De data-afdeling heeft ooit een read-only gebruiker aangemaakt voor precies dit soort analyses. De planner gebruikt die, zet haar secrets in de gedeelde kluis en laat een collega vijf minuten meekijken. Klaar. Geen sprint, geen wachttijd. Bevat het dashboard een fout, dan ziet ze dat in de cijfers en past ze het aan. Het raakt verder niets.
Situatie twee. Datzelfde planningssysteem moet ritten voortaan automatisch herplannen bij vertraging. Dat is een wijziging in de kern. Hier laat Bergveld de agent niet los op productie. Een developer gebruikt de AI om een eerste versie te schrijven, maar die code gaat door een volledige code review, draait eerst tegen een set tests die de oude planninglogica beschermt en wordt op staging getest met echte ritdata voordat er iets live gaat. Een senior tekent voor de merge. Het duurt langer, en dat hoort zo. Een fout in de herplanlogica zou elke vrachtwagen in de vloot kunnen raken.
Hetzelfde bedrijf, dezelfde tools, twee compleet verschillende regimes. Dat is het hele idee. De vraag is nooit of je AI-assisted coding toestaat, maar waar je wat toestaat.
Hoe je hiermee begint
Je hebt geen beleidsdocument van veertig pagina’s nodig. Begin met je software in schillen tekenen, letterlijk. Welke systemen vormen je kern, wat hangt er in de eerste ring omheen, wat leeft er aan de rand. Bij de meeste organisaties is dat in een uur op een whiteboard te doen, en het gesprek zelf levert al inzicht op.
Definieer daarna per schil de minimale set regels. Houd het kort genoeg dat mensen het onthouden. Geef teams autonomie in het groene gebied en knijp de teugels aan naarmate je naar de kern beweegt. Eén eerste stap die bijna altijd loont: laat AI-agents standaard alleen read-only toegang krijgen tot je kerndata, tenzij iemand expliciet anders beslist. Dan is je gevaarlijkste scenario meteen afgedekt terwijl je de rest uitwerkt.
Leg ook vast wie de schillenkaart beheert. Eén persoon of klein team dat bijhoudt welk systeem in welke ring zit, voorkomt dat de indeling na een half jaar niet meer klopt. En zet een lichte vorm van logging op de kern, zodat je achteraf kunt zien welke agent of welke persoon wat heeft gewijzigd. Dat hoeft geen zwaar apparaat te zijn. Een audit trail op je belangrijkste repositories is al een goed begin.
Vibe coding gaat niet meer weg, en dat hoeft ook niet. Mensen in je organisatie bouwen nu al dingen met AI, met of zonder jouw toestemming. De keuze die je hebt is of dat binnen grenzen gebeurt die je zelf hebt getrokken, of in het donker.
Wil je dit scherp krijgen voor jouw eigen organisatie? Bij School of Data Science helpen we teams om hun softwarelandschap in schillen te brengen en de juiste afspraken per laag op te zetten. Plan een incompany training voor je team of bekijk de Vibe Coding training, waarin we developers en teams leren AI-assisted coding in te zetten zonder de controle te verliezen. Voor specifieke vragen over wat dit model betekent voor jouw softwarelandschap, kun je ons bereiken via de contactpagina.