Van vibe coding naar productie: de gevaarlijkste kloof in AI

Vorige week zat ik in een gesprek met een IT-bedrijf dat al 35 jaar actief is. Ze hadden een klant met een systeem dat eruitzag als Teletekst. Eén gepensioneerde developer kon het onderhouden. Niemand anders.

Diezelfde week sprak ik met een startup-founder die trots zijn nieuwe platform liet zien. Volledig gebouwd met Claude Code en Lovable. Geen regel zelf geschreven. "Het werkt geweldig," zei hij.

Twee uitersten. Dezelfde rode draad: niemand snapt wat er onder de motorkap zit.

De nieuwe realiteit

Andrej Karpathy, mede-oprichter van OpenAI, bedacht begin 2025 de term "vibe coding": volledig meegaan met de vibe, vergeten dat de code bestaat, en gewoon beschrijven wat je wilt. Het werd woord van het jaar. En het veranderde alles.

Ondanks dat vibe coding al langer een ding is zie ik het nu opeens elke week in mijn discovery calls.

Klanten die binnenkomen met werkende prototypes. Gebouwd in een weekend. Met tools als Cursor, Lovable, v0, Windsurf of Claude Code. Ze hebben iets wat draait, wat er goed uitziet, en waar ze enthousiast over zijn.

Niets voelt ook beter dan zelf iets bouwen en het dan aan anderen laten zien. (Hoewel mijn vriendin mijn enthousiasme niet altijd begrijpt, zeker als het nog niet helemaal werkt..)

Terug naar die discovery calls met potentiële klanten, want dan zeg ik: "Mooi. Maar dit kan niet naar productie."

Waarom niet?

De cijfers zijn inmiddels hard. Een analyse van CodeRabbit over 470 open-source projecten op GitHub liet zien dat AI-geschreven code 1,7 keer meer grote fouten bevat dan code van mensen. Beveiligingsproblemen? 2,74 keer vaker. Bij Lovable, een van de populairste vibe coding platforms, bleken 170 van de 1.645 gebouwde applicaties een beveiligingslek te hebben waarmee persoonsgegevens voor iedereen toegankelijk waren.

En dan hebben we het nog niet eens over de échte incidenten.

In februari dit jaar werd Moltbook gehackt: een social platform volledig gebouwd via vibe coding. 1,5 miljoen authenticatietokens en 35.000 e-mailadressen lagen open op internet. De founder had de infrastructuurcode nooit bekeken. De AI had tijdens development permissieve instellingen gebruikt, en die gingen mee naar productie.

Nog erger: SaaStr-oprichter Jason Lemkin liet een AI-agent van Replit een productie-app bouwen. De agent begon te liegen over unit tests, negeerde code freezes en verwijderde uiteindelijk de volledige productiedatabase. Maanden aan data, weg.

Het prototype-paradox

Hier zit de paradox. Vibe coding is fenomenaal voor prototypes. Je kunt in vier minuten een werkend 3D-spel bouwen (Ethan Mollick deed het live). Je kunt in een weekend een complete SaaS lanceren. De drempel om iets te maken is nog nooit zo laag geweest.

Maar een prototype is geen product.

Uit onderzoek blijkt dat 60 tot 80 procent van vibe-coded projecten herschreven moet worden voordat ze naar productie kunnen. Niet een beetje aanpassen: fundamenteel herschrijven. Beveiliging, foutafhandeling, schaalbaarheid, monitoring, logging, data-integriteit. Alles wat je niet ziet als gebruiker, maar wat bepaalt of je systeem morgen nog draait.

Ethan Mollick, professor aan Wharton en een van de scherpste AI-denkers, verwoordde het treffend: de vaardigheid van de toekomst is niet zelf code schrijven. Het is weten hoe goed eruitziet, en dat helder genoeg kunnen uitleggen zodat een AI het kan leveren. Management wordt de AI-superkracht. Maar dat vereist wel dat je weet wat je niet weet.

Wat ik in de praktijk zie

Bij NinA AI merken we deze verschuiving dagelijks. Steeds vaker komen klanten niet met een vraag, maar met een prototype. "Kun je dit in productie nemen?" Dat is een fundamenteel ander gesprek dan twee jaar geleden.

Vier weken geleden besprak ik met mijn team hoe we hier een structurele service van kunnen maken. Security checks op AI-gegenereerde code. Niet als nice-to-have, maar als standaard stap. Het resultaat: een professioneel rapport met concrete aanbevelingen.

Een stempel dat het veilig is. Want dat is wat ontbreekt. Niet het bouwen, dat kan iedereen nu. Maar het valideren, beveiligen en schaalbaar maken. Het verschil tussen een demo en een bedrijfskritisch systeem. Ik ben dolblij dat ik een team om me heen heb die dat kan!

De vijf dingen die vibe coding mist

Na tientallen van deze gesprekken zie ik steeds dezelfde vijf gaten:

1. 1.Beveiliging. AI-modellen genereren code die werkt, niet code die veilig is. Hardcoded API-keys, open database-toegang, ontbrekende input-validatie. Het zijn geen edge cases, het is de standaard.
2. 2.Foutafhandeling. Wat gebeurt er als een API-call faalt? Als een gebruiker onverwachte data invoert? Als je database vol raakt? Vibe-coded apps hebben hier zelden antwoord op.
3. 3.Schaalbaarheid. Het werkt voor 1 gebruiker. Maar voor 2? of 10? of misschien wel 1.000? De architectuurkeuzes die een AI maakt tijdens prototyping zijn bijna nooit geschikt voor schaal.
4. 4.Monitoring en logging. Als er iets misgaat in productie, hoe weet je dat? Vibe-coded apps hebben geen observability. Geen alerts. Geen audit trail.
5. 5.Data-integriteit. De gevaarlijkste: wat als je AI-agent stilletjes data overschrijft? Of dupliceert? Of verwijdert? Zonder logging merk je het pas als het te laat is.

Wat je er wel mee kunt (en moet) doen

Ik ben absoluut geen tegenstander van vibe coding. Integendeel. Het is een van de krachtigste ontwikkelingen van de afgelopen jaren. Maar je moet weten waar de grens ligt.

Gebruik het voor prototypes en proof of concepts. Om snel te valideren of een idee werkt. Om stakeholders te overtuigen met iets tastbaars in plaats van een PowerPoint. Om in een weekend te testen wat vroeger maanden kostte.

Maar behandel het resultaat als een schets, niet als een blauwdruk. Laat een professional de code reviewen voordat het naar productie gaat. Zorg voor een aparte test-omgeving. Implementeer monitoring. En bouw de foutafhandeling die de AI vergat.

Bij een van onze klanten kwamen ze met een werkend AI-platform dat hun consultants ondersteund en uiteindelijk door klanten gebruikt kan worden. Gebouwd in Python, FastAPI, React. Prima stack. Maar volledig op localhost, zonder multi-tenancy, zonder toegangsrechten, zonder scheiding van klantdata. De stap van "het werkt op mijn laptop" naar "dit kunnen we aan klanten aanbieden" kostte zes tot acht weken professioneel ontwikkelwerk. Dat is geen falen van vibe coding. Dat is precies hoe het hoort te werken: snel bouwen, dan professioneel maken.

De nieuwe rol: van bouwer naar keurmeester

De markt verschuift. Twee jaar geleden was de vraag: "Kun je dit voor ons bouwen?" Nu hoor ik steeds vaker: "We hebben iets gebouwd, kun je het in productie nemen?"

Dat vraagt om een andere skillset. Niet alleen bouwen, maar ook beoordelen. Niet alleen creëren, maar ook valideren. De waarde zit niet meer in het schrijven van code. Die zit in het weten of code goed genoeg is.

Of zoals Mollick het zegt: de mensen die het gaan maken zijn degenen die weten hoe goed eruitziet, en dat helder genoeg kunnen uitleggen.

Dat geldt voor developers. Maar ook voor jou als ondernemer. De vraag is niet of je AI gaat gebruiken om software te bouwen. De vraag is of je weet wanneer het resultaat goed genoeg is voor je klanten.

En als je dat niet zeker weet? Dan is dat precies het moment om een professional erbij te halen.

Tot de volgende!