"Dit is bizar."
Dat zeg ik regelmatig als iemand me een MVP laat zien die met AI-tooling
is gebouwd.
Want het ziet er écht indrukwekkend uit. Een handige ICT'er werkt een
businessidee in een paar dagen uit tot een complete applicatie. Strak design,
een dashboard, werkende workflows.
Functioneel lijkt het gewoon te werken.
Maar dan: "Kunnen we dit live zetten?"
Bijna altijd is het antwoord: nog niet.
Wat er aan de hand is
AI-agents als Cursor, Lovable en Bolt zijn geniaal in het bouwen van
functionaliteit. Ze maken precies wat je vraagt.
Maar ze denken niet automatisch mee over wat er naast de functionaliteit
nodig is. De niet-functionele kant. De dingen die onzichtbaar zijn zolang
het goed gaat — en die pijnlijk zichtbaar worden zodra echte klanten
inloggen.
Dit zijn de vijf dingen die ik keer op keer tegenkom.
1. Secrets in de code
Wachtwoorden, API-sleutels, databaseverbindingen — ze staan gewoon in de
code. Soms zelfs in de git-history, ook nadat ze zijn "verwijderd".
Voor een developer is dit een klassieke fout. Een AI-agent vindt het de
makkelijkste oplossing.
Zodra die repository ooit ergens publiek wordt, of zodra er een lek is:
meteen raak.
2. Geen echte authenticatie
De loginpagina werkt. Maar klopt de autorisatie ook?
Wat als ik als ingelogde gebruiker de URL aanpas en bij de data van een
andere gebruiker kan? Wat als er een admin-endpoint is dat niet afgeschermd
is? Wat als sessies nooit verlopen?
Dit soort fouten zijn niet zichtbaar in de demo. Ze worden zichtbaar als
iemand gaat zoeken.
3. Schaalbaarheid? Welke schaalbaarheid?
Bij tien gelijktijdige gebruikers werkt het gewoon.
Bij honderd wordt de app traag.
Bij duizend gaat hij plat.
Niet omdat de code slecht is, maar omdat er nooit over nagedacht is. Geen
database-indexen, N+1-queries, geen caching, geen rate limiting. Een
AI-agent bouwt wat functioneel werkt voor de demo — niet wat schaalbaar
is voor productie.
4. Als er iets misgaat, hoor je het van een klant
Er is geen monitoring. Geen alerting. Geen logging die je iets vertelt over
wat er precies misging.
De server is crasht om 03:00 's nachts. Jij weet het de volgende ochtend
als de eerste boze mail binnenkomt.
Disaster recovery? Back-ups? Niet aan gedacht.
5. AVG — zonder dat je het weet
Persoonsgegevens worden opgeslagen. Misschien meer dan nodig. Misschien bij
een Amerikaanse cloudprovider zonder verwerkersovereenkomst. Misschien langer
dan toegestaan.
Niemand heeft dit bewust besloten. Het is gewoon hoe het gebouwd is.
Tot er een klant om zijn gegevens vraagt. Of een toezichthouder.
Wat dit niet is
Dit is geen pleidooi tegen vibe coding.
Ik vind het oprecht indrukwekkend wat teams tegenwoordig in een weekend
kunnen bouwen. De drempel naar een werkend idee is nagenoeg verdwenen. Dat
is winst.
Dit is een pleidooi voor het verschil kennen tussen "het werkt" en
"we kunnen dit verantwoord live zetten".
Die twee zijn niet hetzelfde. En dat is prima — zolang je weet wanneer je
de stap van het een naar het ander moet maken.
Hoe los je dit op?
Meestal niet door alles opnieuw te bouwen.
Wel door iemand met software-engineering-achtergrond er systematisch
doorheen te laten lopen. Wat is het risico? Wat heeft prioriteit? Wat
moet er gebeuren vóór livegang?
Dat is precies wat ik doe via VibeGuard —
een quickscan van 1–2 dagen die precies dat in kaart brengt, samen met
een geprioriteerd plan voor de vervolgstap.
Geen herbouw. Geen onnodig groot traject. Gerichte hardening van wat er
al staat.
Herken je dit? Zit je met een vibe-coded MVP die eigenlijk al bijna klaar
is voor livegang — maar je durft het nog niet aan?
Laat het weten in de comments. Of kijk op vibeguard.nl.