‘Je hoeft niet meer te leren programmeren.’ Zo wordt vibe coding vaak samengevat, en voor het maken klopt dat aardig: je vertelt een AI-tool wat er moet komen en er rolt iets werkends uit, zonder dat je zelf een regel code schrijft. Voor het beoordelen klopt de belofte niet. Of dat werkende ook deugt, vertelt de tool er niet bij.
De kennis die daarvoor nodig is, verdwijnt dus niet. Ze verschuift: van de handen van de maker naar het oordeel van degene die beslist. Vaak ben jij dat. Vroeg of laat ligt er een vibe-coded prototype in je organisatie en moet jij bepalen of het iets mag worden.
Werkend is niet hetzelfde als af
AI-codetools optimaliseren op een resultaat dat draait, niet op software die veilig, onderhoudbaar en schaalbaar is. Een prototype dat vlekkeloos oogt, kan wachtwoorden onversleuteld bewaren, elke gebruiker bij alle gegevens laten of stilvallen zodra tien mensen tegelijk inloggen. In een demo zie je daar niets van, en de maker ziet het vaak zelf niet. Je hoeft geen regel code te kunnen lezen om dit te ondervangen. Je moet wel weten welke vragen het verschil blootleggen.
Vijf vragen die je zelf kunt stellen
Dit toetsingskader vraagt geen technische achtergrond, alleen de bereidheid om door te vragen. Stel de vragen aan degene die het prototype maakte, en let behalve op de antwoorden ook op hoe zeker ze klinken.
- Waar staan de wachtwoorden en API-sleutels? Het goede antwoord: in een afgeschermde configuratie, buiten de code. Staan ze in de code zelf, dan ligt de sleutel onder de deurmat.
- Wie kan wat zien? Maak twee testaccounts aan en probeer met het ene de gegevens van het andere te openen. Lukt dat, dan is de toegangscontrole niet op orde.
- Wat gebeurt er als het misgaat? Vraag naar back-ups, foutafhandeling en verkeerde invoer. Een prototype zonder vangnet is prima, tot iemand er echte gegevens aan toevertrouwt.
- Welke persoonsgegevens zitten erin? Klantdata in een prototype betekent dat de AVG nu al geldt, niet pas bij livegang. Vraag ook of er gegevens in een AI-tool zijn geplakt tijdens het maken.
- Kan de maker het uitleggen? Laat een willekeurig onderdeel toelichten. Wat niemand kan uitleggen, kan ook niemand onderhouden of repareren.
Waarvoor je vibe coding wel en niet inzet
Voor verkenning is vibe coding een nuttig instrument: een idee toetsen, een demo voor een klantgesprek, een wegwerptool voor een eenmalige klus. We ontwikkelen zelf ook AI-assisted en zien elke week hoeveel vaart dat geeft. Maar bij ons kijkt er altijd een engineer mee die de gegenereerde code beoordeelt en bijstuurt, want deze tools maken bij een ervaren gebruiker dezelfde soort fouten als bij een beginner. Welke dat zijn, lees je in de valkuilen waar ook gevorderde gebruikers intuinen. Zodra een applicatie klantgegevens verwerkt, aan andere systemen koppelt of een proces draagt waar de organisatie op leunt, is die vakkundige blik geen luxe maar een voorwaarde.
Wat je met de uitkomst doet
Doorstaat het prototype de vijf vragen, dan heb je waarschijnlijk meer in handen dan een experiment. Zakt het erdoorheen, dan weet je wat er moet gebeuren voordat collega’s of klanten erop mogen vertrouwen. De volgende stap is in beide gevallen dezelfde: laat iemand met vakkennis beoordelen wat er nodig is om er robuuste software van te maken. Soms is dat opschonen en aanvullen, soms is gedeeltelijk opnieuw ontwikkelen eerlijker en uiteindelijk goedkoper. Die beoordeling en het doorbouwen erna doen we bij doorontwikkeling en beheer. Het gesprek begint dan bij wat jij met de applicatie wilt, niet bij wat er mis is met de code.