Steeds meer founders en product owners lopen bij ons binnen met een project dat ze zelf in elkaar hebben gevibecode. Met Lovable, Cursor of ChatGPT, een handvol tutorials en veel momentum. Het werkt, min of meer. En dan komt onvermijdelijk dezelfde vraag: kan dit naar productie, en is het eigenlijk wel veilig?
Om die vraag eerlijk te beantwoorden helpt het om eerst te begrijpen wat er nou écht gebeurt als je vibecodet. Want bijna alle verwarring komt voort uit één misverstand.
De fundamentele mismatch
Er is iets raars aan de hand met vibe coding. De tool schrijft code. Dus denk je dat je aan het programmeren bent. Maar dat is niet wat er gebeurt.
Omdat de tool code schrijft, denk je dat je programmeert. Maar je programmeert niet. Je designt.
Dat klinkt als een woordspelletje, maar het verschil is fundamenteel. Als je denkt dat je programmeert, neem je beslissingen alsof je developer bent. Je gaat nadenken over architectuur, schaalbaarheid, best practices. Terwijl je precies de kennis mist om die beslissingen goed te maken. Je dwingt jezelf in een rol die niet bij je past, en dat is precies waar het misgaat.
Vibecoders zijn designers
Wees eerlijk over wie er vibecodet. Het zijn de designers en de product owners. De mensen die dicht genoeg bij development zitten om te zien welke problemen developers oplossen, en denken: dat wil ik ook kunnen.
Een vibecoder is een designer met een product owner-pet op. Je geeft om wat je ziet. De backend is onzichtbaar, en zolang het werkt, kijk je er niet naar om.
En dat is precies waar vibe coding goed in is: het visuele. Iets maken om naar te kijken. Een idee schetsen dat je gisteren nog niet kon laten zien.
Designen betekent: versies maken
Stel je weet dat je een spec aan het schrijven bent waaraan het eindresultaat moet voldoen. Dan ga je het ook zo aanpakken als elke andere designer: je maakt versies.
Je speelt met opties. Je zegt: we kunnen het deze kant op doen, of die kant op. Dat is de superkracht van vibe coding met schermen. Je kunt razendsnel wisselen:
- Maak er nog drie varianten bij
- Bij scherm 2 wil ik het zus
- Bij scherm 3 wil ik het zo
- Deze voelt het beste, ga daarmee verder
Wat je daarbij vooral niet moet doen, volgt logisch uit het feit dat je aan het designen bent:
Niet de techniek in duiken
Je houdt je niet bezig met de implementatiedetails; die wil je niet zien en niet snappen. Je schetst wat het moet worden. Hoe het gebouwd wordt, is niet jouw laag.
Niet optimaliseren voor schaal
Bij elke technische afweging is de juiste keuze: negeren. Je bouwt een prototype om je idee te valideren. Duizend gelijktijdige gebruikers zijn een probleem voor later.
Niet doen alsof je het snapt
Mis je de technische kennis, dan heeft net-doen-alsof geen zin. Je neemt toch de verkeerde beslissingen. Laat die laag los en oordeel op wat je wél kunt beoordelen: het resultaat.
De Figma-parallel
Het is eigenlijk hetzelfde als werken in Figma. Je opent een leeg canvas om een ontwerp te maken en je staart naar het stenen tijdperk: een witte pagina.
Genereer eerst iets lelijks. Het maakt niet uit dat het kut is. Je hebt een startpunt, en aanpassen is altijd makkelijker dan vanaf nul beginnen.
Dat is wat vibe coding doet voor mensen die designen. Geen blanco-pagina-syndroom. Je hebt meteen iets om naar te kijken, op te reageren, weg te gooien. En iets aanpassen wat je voor je ziet gaat altijd sneller dan iets uit het niets bedenken.
Waar het misgaat: prototype is geen productie
Het gaat mis op het moment dat je vergeet dat je aan het designen was. Als je denkt dat je app productie-klaar is, simpelweg omdat hij werkt.
Een prototype laat zien dát iets kan. Productie betekent dat het ook echt werkt: betrouwbaar, veilig, en als er honderd mensen tegelijk inloggen. Dat is een ander vak dan een extra rondje polijsten.
Jeroen , 010 Coding Collective
Dit is precies de kloof waar founders in vallen. De demo werkt, dus de aanname is: nog even afmaken en we kunnen live. Maar de laatste 20% (edge cases, foutafhandeling, performance onder druk) is juist het deel dat AI-tools meestal overslaan. En het deel dat je niet ziet, zie je dus ook niet kapotgaan:
Authenticatie en rollen
Inloggen werkt in de demo. Maar werkt het ook over sessies, apparaten en gebruikersrollen heen, zonder dat iemand bij andermans data kan?
Betalingen en randgevallen
De happy path checkt af. Tot iemand een refund, een kortingscode of een mislukte betaling probeert, en het stil omvalt.
Security die je niet ziet
Blootgestelde API-keys, injecties, zwakke autorisatie. AI genereert ze zonder waarschuwing, en zonder review gaan ze ongemerkt live.
Dat maakt vibe coding niet slecht. Wij gebruiken het zelf ook. Het probleem zit in wat je niet weet over de code die het oplevert.
Wat je écht overhoudt aan een vibe-coded project
Hier zit de geruststelling. Want als je vibe coding ziet als design, dan weet je ook waar de blijvende waarde zit. En dat is bijna nooit de code zelf.
Klanten komen binnen met een ge-vibecode project en denken dat de code het waardevolle is. Soms klopt dat, vaak niet. Wat altijd waardevol is: alle keuzes die ze al gemaakt hebben over wat het moet worden.
Jeroen , 010 Coding Collective
Die kennis is goud waard. Je weet wat werkt en wat niet. Je hebt feedback van echte gebruikers. Je hebt een scherp beeld van het eindresultaat. Dat is precies wat een designer oplevert, en het is een uitstekend vertrekpunt voor een developer die er een echt systeem van maakt.
Het denkwerk is het kapitaal
De uren die je stak in 'wat is het probleem, wat lossen we op, hoe ziet het eruit': dát is herbruikbaar, ongeacht of de code het haalt.
De code is een hypothese
Vibe-coded code bewijst dat je idee kán. Of het ook standhoudt onder echte gebruikers is een aparte vraag, en die beantwoord je met een review.
Praktisch: zo pak je het wél goed aan
Behandel het als prototyping
Je maakt een interactief prototype om je idee te valideren. Houd dat doel scherp en je stuurt op de juiste dingen.
Maak versies, kies niet te snel
Net als bij design: meerdere varianten, spelen met opties, pas daarna kiezen.
Focus op het visuele
Daar heb je een mening over, daar voeg je waarde toe. De rest laat je aan mensen die de onderlaag wél overzien.
Weet wanneer je stopt
Op een punt is je prototype goed genoeg om te valideren. Dan stop je, en laat je een professional de productieversie bouwen, of nakijken wat je hebt.
Veelgestelde vragen
Is vibe-gecodeerde software klaar voor productie?
Is AI-gegenereerde code veilig?
Moet ik mijn vibe-coded MVP weggooien en opnieuw bouwen?
Wat is herbruikbaar aan een vibe-coded prototype?
Prototype klaar, wat nu?
Jij hebt het denkwerk gedaan. Wij kijken je vibe-coded project na, vertellen je eerlijk wat standhoudt en wat breekt onder druk, en helpen je het veilig naar productie te brengen: ondersteunen, overnemen of hosten.