De term “vibe coding” komt van Andrej Karpathy, die begin 2025 een manier van bouwen beschreef waarbij je je “volledig overgeeft aan de vibes” en nauwelijks naar de code kijkt. Het is een reëel ding, en het is echt handig voor een prototype in een weekend. Het is ook de snelste manier die ik ken om een website te lanceren die af lijkt en het stilletjes niet is.
Ik gebruik AI elke dag. Het maakte me sneller en, alles bij elkaar, een betere developer. Maar het soort AI-ontwikkeling dat ik voor klanten doe is niet dezelfde bezigheid als vibe coding, ook al draait het op dezelfde modellen. Het verschil zit niet in het gereedschap. Het zit in wie verantwoordelijk blijft voor het resultaat.
Wat vibe coding echt is
Je gaat zitten met een AI-editor, beschrijft de site die je wilt, en accepteert wat eruit komt. Je draait het, het werkt, je zet het live. Niemand las de inloglogica. Niemand koos het datamodel. Niemand kan zeggen waarom een bepaalde functie bestaat. Het ziet er in een demo prachtig uit.
Voor sommige dingen is dat helemaal prima. Een wegwerpprototype, een tool die je toch opnieuw bouwt, een manier om in een middag iets te leren of te testen. Vibe coding is een snel, bruikbaar gereedschap voor werk dat niet hoeft te blijven.
Het is niet meer prima zodra het resultaat echte gebruikers, echt geld, of volgend jaar nog onderhoud aankan. Want de code werkt tot het moment dat het niet meer werkt, en dan is er niemand in het pand die hem begrijpt.
Wat AI-ondersteund ontwikkelen is
Dezelfde modellen, een andere verhouding. De AI schrijft voor, ik beslis. Ik lees elke regel die live gaat. Ik bezit de architectuur, het beveiligingsmodel, en de afwegingen die bij allebei horen. De AI is de snelste junior developer met wie ik ooit heb gewerkt en wordt nooit moe. Maar hij heeft geen oordeel en geen verantwoordelijkheid. Die twee dingen blijven van mij.
Dit is geen langzamer-maar-veiliger principerigiditeit. Ik lever sneller dan drie jaar geleden. Ik lever alleen geen code die ik niet begrijp. Die ene regel is de grens tussen de twee manieren van werken.
Het echte verschil: wie het repareert als het breekt
Elke website gaat een keer stuk. Een dependency update, een edge case duikt op, het verkeer piekt, een formulier begint te falen. De vraag die er echt toe doet is simpel: als dat gebeurt, begrijpt iemand het systeem dan goed genoeg om het snel te repareren?
Bij een vibe-coded site is het eerlijke antwoord vaak nee. Bij AI-ondersteund ontwikkelen is het antwoord ja, omdat iemand de beslissingen de eerste keer al nam en begreep.
| Aspect | Vibe coding | AI-ondersteund ontwikkelen |
|---|---|---|
| Wie reviewt de code | Niemand leest het | Elke live regel is gelezen en begrepen |
| Wie bezit de architectuur | Het model koos het | Een developer besloot het bewust |
| Beveiliging | Ongecontroleerd, duimen maar | Nagekeken en doordacht |
| Als het breekt | Niemand weet waarom het werkte | Wie het bouwde kan het repareren |
| Goed voor | Prototypes, demo's, wegwerptools | Sites met gebruikers, geld, levensduur |
| Kosten als het faalt | Opnieuw bouwen, vaak vanaf nul | Een fix, omdat het systeem begrepen is |
De rol verschoof omhoog, hij verdween niet
Drie jaar geleden besteedde ik het grootste deel van mijn tijd aan het typen van oplossingen die ik al kende: een contactformulier, een responsive grid, een API-koppeling, de honderdste variant van een layout. AI doet dat werk nu, in seconden, en goed ook. Ik ben er niet nostalgisch over. Daar zat de waarde nooit.
Dus mijn tijd verschoof naar de delen die de waarde altijd droegen. Bedenken wat je bouwt. Hoe het gestructureerd moet zijn. Wat er mis kan gaan, en wat er dan gebeurt. Wat de klant echt nodig heeft, wat vaak niet hetzelfde is als wat hij eerst vraagt. Het werk verschoof van productie naar regie.
Ik zie het nu minder als coderen en meer als regisseren en redigeren. Ik zet de bedoeling, de kaders en de lat. De AI maakt daar concepten tegenaan. Ik review, corrigeer, integreer en zet mijn naam onder het resultaat. Dat ligt dichter bij een architect dan bij een typist, en het is een grotere baan, geen kleinere. De saaie delen werden geautomatiseerd en de delen die een mens nodig hebben kregen al mijn aandacht.
De verdeling, concreet. AI is uitstekend in boilerplate, eerste concepten, vertalen tussen patronen die ik al ken, syntax onthouden, en het doorploegen van refactors. Wat menselijk blijft is besluiten dat het überhaupt het juiste is om te bouwen, beveiligingsoordeel, performance-afwegingen, smaak, weten wanneer het model met grote stelligheid fout zit, en verantwoordelijk zijn naar jou als het live gaat.
Waarom dit jou raakt
Je koopt geen regels code. Je koopt een website die werkt, online blijft, en die één herkenbaar persoon begrijpt en kan repareren. Dat laatste vergeet je makkelijk, tot er iets breekt.
Een vibe-coded site kan een demo doorstaan en daarna op drie voorspelbare manieren falen. Beveiligingsgaten die niemand controleerde, omdat controleren betekent dat je code leest die niemand las. Code die niemand kan onderhouden, dus de eerste echte wijziging betekent opnieuw bouwen. En “ziet er af uit” dat “is niet af” verbergt, de duurste van de drie, want daar kom je in productie achter. Als je mij inhuurt zit AI de hele tijd aan tafel, maar het oordeel is menselijk en de verantwoordelijkheid heeft een naam.
Hoe ik het zelf gebruik
De bestelwizard op deze site is een goed voorbeeld. AI hielp me de voorwaardelijke staplogica snel op te zetten, werk dat me met de hand een vervelende middag had gekost. Maar de stapflow heb ik zelf ontworpen, en de anti-spam honeypot en de afhandeling van prompt-injectie op de gebruikersinvoer schreef ik met de hand, omdat dat beslissingen met gevolgen zijn en ik ze allemaal wilde bezitten. De AI maakte de makkelijke 70% snel. De gewonnen tijd stak ik in de 30% die echt bepaalt of het ding veilig is.
GuardingWP, mijn WordPress-beveiligingsscanner, maakt het punt nog botter. Je kunt geen tool vibe-coden waarvan de hele taak is om de slordigheid te vangen die vibe coding produceert. Het goed bouwen betekende elke check begrijpen die hij draait, en waarom. AI hielp me daar sneller doorheen. Bezitten kon hij het nooit.
Dit geldt al vóór er één regel geschreven is. De juiste basis kiezen is een afweging die AI kan voeden maar niet voor je kan maken, en precies daar gaat het beslisschema statisch versus WordPress over.
Het gereedschap veranderde. De verantwoordelijkheid niet.
AI haalde de developer niet uit de lus. Het zette me waar ik het meeste waard ben: bedenken wat er gebouwd wordt, zorgen dat het standhoudt, en ervoor staan. Wil je een site die zo gebouwd is, zo werk ik. Weet je al wat je nodig hebt? Start de bestelwizard.