Een werkende app in een paar dagen, zonder ontwikkelteam: dat is de belofte van vibe coding. Je beschrijft in gewone taal wat je nodig hebt, een AI-tool als Cursor of Lovable genereert de code en je stuurt bij tot het doet wat je bedoelde. Die belofte klopt grotendeels. De vraag die er voor jou toe doet is een andere: voor welk soort projecten is dit een verstandige route, en waar begint het risico?
We kunnen daar eerlijk over zijn, want we gebruiken deze tools zelf, elke dag, met software-engineers die elke wijziging beoordelen voordat die live gaat. We kennen beide kanten: wat deze manier van werken versnelt, en waar hij stilletjes breekt.
Waar vibe coding zijn waarde bewijst
Drie situaties komen in de praktijk steeds terug. Je wil een idee toetsen voordat je er serieus budget voor vrijmaakt: een klikbaar prototype zegt in een managementoverleg meer dan twintig slides. Je wil uitproberen of een klein intern hulpmiddel iets oplost, zoals een overzicht dat drie spreadsheets samenbrengt, voordat iemand er iets blijvends van maakt. Of het concept staat vast, maar je wil eerst voelen hoe het werkt voordat iemand een architectuur uittekent.
Deze situaties hebben iets gemeen: de scope is klein, de gebruikers zijn collega’s en het resultaat mag onaf zijn - je bouwt om te leren, niet om erop te blijven draaien. Interne gebruikers kennen de context, vergeven een ruwe interface en vertellen je binnen een dag wat er beter moet. Precies daar is snelheid meer waard dan perfectie.
Waar de grens ligt
De grens ligt waar de gevolgen van een fout groter worden dan het experiment. Verwerkt de applicatie klantdata of persoonsgegevens? Leunt een bedrijfsproces erop? Gaan klanten ermee werken? Dan is vibe coding niet de juiste aanpak. AI-gegenereerde code oogt overtuigend en doet het in een demo vlekkeloos, maar beveiliging, foutafhandeling en onderhoudbaarheid zie je niet aan de buitenkant. Zonder iemand met vakkennis die meekijkt, weet je niet wat er ontbreekt - en dat merk je pas als het misgaat.
Dat is geen pleidooi tegen AI-tools, wel tegen het overslaan van vakmanschap. Hoe die twee zich tot elkaar verhouden, lees je in het verschil tussen vibe coding en traditioneel programmeren.
Vijf vragen als beslissingskader
Twijfel je over je eigen project? Deze vijf vragen brengen de keuze terug tot de kern.
- Is de scope klein en scherp afgebakend?
- Zijn de gebruikers interne collega’s die snel feedback geven?
- Is dit een eerste versie om van te leren, geen definitief product?
- Weegt snelheid in deze fase zwaarder dan degelijkheid?
- Is er ruimte om later te investeren in een stevige technische basis?
Beantwoord je ze grotendeels met ja, dan is vibe coding een prima startpunt. Maar niet elke vraag telt hetzelfde. Zodra er klantdata of een bedrijfskritisch proces in het spel is, weegt dat ene nee zwaarder dan vier keer ja.
Als het prototype serieus wordt
Een patroon dat we bij beoordelingen van vibe-coded tools geregeld zien: een hulpmiddel dat voor één team is gemaakt, blijkt nuttig, verspreidt zich door de organisatie en bevat na verloop van tijd gegevens waar bij de start niemand over heeft nagedacht. De eisen verschuiven dan vanzelf: van werkend naar veilig, van demo naar iets waar je organisatie dagelijks op leunt en waar een ander aan verder kan. Dat zijn engineeringvragen, en die beantwoordt geen enkele prompt.
Staat er bij jou zo’n prototype te draaien dat groter wordt dan bedoeld? Weggooien hoeft niet. Onze engineers beoordelen wat er ligt, versterken de basis en maken er software van die dagelijks gebruik aankan. Bij doorontwikkeling en beheer lees je hoe we dat aanpakken.