Ik heb een “productie”-app gebouwd met vibecoding. 97.089 regels gegenereerd. Slechts 25.056 regels haalden productie. Vier complete refactors. De AI faalde niet door slechte prompts. Het faalde omdat AI dingen vergeet, context kwijtraakt en duplicaatlogica creëert, hoe goed je het ook stuurt. Vibecoding gaat er niet om AI voor je te laten bouwen. Het gaat erom dat je je systeem goed genoeg kent om de ruis te filteren. Zonder die kennis ship je alleen maar gissingen.
Wat vibecoding eigenlijk betekent
Mensen denken dat vibecoding betekent dat AI je app bouwt terwijl jij toekijkt. Reality check: dat is helemaal niet het geval als je een daadwerkelijk werkend product nodig hebt met elke keer het verwachte resultaat.
Vibecoding betekent nog steeds dat jij de controle hebt. Je prompt met precisie. Je experimenteert. Je stuurt. Je filtert. Het blijft handwerk, alleen met andere hefboomwerking.
“A fool with a tool is still a fool”
En als je niet weet wat je doet? Dan is het resultaat hetzelfde als altijd: een zooitje. Vibecoding zonder de juiste kennis is gewoon fout. En het grootste probleem met AI is dat het maar blijft produceren: code na code na code. Het doet gewoon wat je vraagt. Het is daar niet kritisch over. Dus als je niet weet wat je doet, spreek je jezelf de hele tijd tegen met geprogrammeerde functionaliteit die nooit samenwerkt binnen je app.
AI is koning in fallbacks. Ik had voor elke mislukte API-call 5 verschillende fallbacks gekregen. Zouden we niet gewoon de juiste manier aan de praat moeten krijgen in plaats van fallbacks bouwen? AI is ook lui: het onderdrukt liever notices dan dat het ze oplost. Zeker als het niet in één keer lukt.
Ik bouwde een productie-app met AI (maar niet dankzij AI)
Ik heb Windsurf gebruikt om een complete applicatie te bouwen. Geen menselijke developers. Geen code die ik direct heb geschreven. We gebruiken Sonnet 4.5 als onze kennisbron.
Het resultaat na veel frustratie: een volwaardig productiespel met backend-logica, login-flows, async data writes, mail queues, admin security, monitoring en cartesische algoritmes die updaten op basis van gebruikersinteractie.
De AI heeft alles geschreven. Ik heb geen enkele regel code aangeraakt. Zelfs de simpelste CSS-wijziging liet ik aan AI over.
Maar wat niemand je vertelt: ik heb het hele project vier keer compleet moeten refactoren. En niet omdat ik slecht promptte. Ik gebruikte KISS-principes, DRY-standaarden, PSR-richtlijnen. We schreven vooraf beslissingen uit en maakten implementatiedocumenten. We gebruikten richtlijnen voor de talen die we gebruikten.
Uiteindelijk maakte het niets uit.
AI vergeet. Het verliest context. Het begint duplicaatfuncties te maken zonder door te hebben dat het die logica al drie files terug schreef. Hoe complexer je project wordt, hoe meer het afdrijft. En hoe vaker het niet in één keer goed gaat, hoe meer AI denkt backwards compatibility te moeten handhaven, waardoor je code nog complexer wordt. Het maakt niet uit hoe je het de eerste keer prompt, of met project rules.
Na vier complete refactors leerde ik: AI vergeet de context niet. Het heeft die nooit gehad ;).
De enige reden dat de definitieve versie werkt, is dat ik precies wist wat ik aan het bouwen was. Ik had het systeem in mijn hoofd. Ik zag wanneer AI zichzelf herhaalde. Ik wist wanneer ik moest stoppen, bijsturen of opnieuw beginnen. Ik controleerde elke file op duplicaat fallback-data, duplicaten enzovoort. Ik gebruikte ook het zeer handige npm-package knip.
https://www.npmjs.com/package/knip
Je kunt niet iets de productie in vibecoden zonder je product te begrijpen. Punt. En je moet accepteren dat bugfixen betekent dat je op AI leunt om het op te lossen zonder iets anders te breken. Veel succes daarmee…
De data vertelt de rest van ons verhaal
Tijdens ons vibecoden produceerde Windsurf:
- 97.089 regels code gegenereerd
- 2.925 prompts verstuurd
- 5.693 credits gebruikt
- 15.734 tool calls (waaronder 7.000 code-edits)
Wat er daadwerkelijk in productie is gegaan:
- 25.056 regels code
Meer dan 70.000 regels zijn geschrapt, vervangen of gerefactord.
Nu denk je misschien: dan moet je AI dus gewoon “beter sturen” of “preciezer prompten”. Dat is niet het punt dat ik wilde maken.
Het punt is: je kunt AI-gebral op dit moment niet voorkomen. Hoe goed je ook prompt. Hoe gestructureerd je aanpak ook is. AI overproduceert. Het genereert redundante code. Het raakt de tel kwijt van wat het al gebouwd heeft. Het creëert ruis. AI is gebouwd om altijd een vorm van AI-verbaal diarree te produceren.
Die 70k+ regels verspilde output? Dat is geen bug. Dat is de huidige staat van vibecoding.
En als je je systeem niet goed genoeg kent om te herkennen wat troep is en wat niet, ship je alles en kun je zelfs met AI niet meer debuggen. Of erger: je besteedt persoonlijk weken aan het debuggen van een codebase die je niet snapt.
De kosten per 1000 credits liggen rond de 35 dollar. De ontwikkeling van dit spel kostte me 210 dollar. Elk bedrijf dat Large Language Models levert verliest geld. De code die ik produceerde had makkelijk 210 x 10 = 2.100 dollar moeten kosten, minimaal. Ik vraag me af of ze dan überhaupt geld verdiend hadden.
Los van het geld: is dit onze kostbare elektriciteit echt waard? Ik ben benieuwd hoe haalbaar dit is als je de echte prijs betaalt.
Wat mensen verkeerd begrijpen
AI is geen magie. Het is een “slimme”, snelle assistent. Maar hij begrijpt niet wat er voor jouw bedrijf telt. Hij heeft geen grip op edge cases, constraints, risico’s, performance-implicaties of security-kwetsbaarheden.
Dat is jouw werk!
In mijn geval hielp AI om iets echts te bouwen. Maar de AI beveiligde het adminpaneel niet. Die mail queue-logica ontwierp hij niet. Hij besliste niet wanneer async writes gedebounced moesten worden. Dat deed ik. Door kritisch te zijn en de juiste vragen te stellen dankzij bouwervaring van vroeger.
Zonder die richting was het hele ding in elkaar gestort.
En ik zie dit patroon overal. Teams die AI-producten bouwen zonder ownership of richting, alleen maar om te kunnen zeggen dat ze “iets met AI gedaan hebben”. Dat is oppervlakkig. Dat is broos. Het schaalt niet.
“You’re not building products. You’re laundering prompts into deployments”
Hoe vaak hoor je niet van bovenaf: we moeten iets met AI doen. We raken achter. Achter op wat?
De customer service-val
Dan is er nog de hype rond AI voor klantenservice. Bedrijven beweren dat het perfect is voor 24/7 support, snellere antwoorden, minder mensen nodig.
Maar als je een bot nodig hebt om met je klanten te praten, ligt je echte probleem waarschijnlijk ergens anders. AI repareert kapotte processen niet. Het verstopt ze. Tijdelijk.
Als je minder menselijk contact als winst ziet, heb je al verloren. Als het beantwoorden van vragen lang duurt, moet je misschien ergens anders kijken waarom mensen zoveel vragen hebben, en dat eerst verbeteren.
Het eigenlijke punt
Vibecoding is gewoon weer een tool. Meer niet. Wel een heel give tool in de juiste handen, maar toch een tool. En vooral goed voor prototyping. Maar met een flinke dosis kennis kun je er misschien standalone apps mee bouwen die écht werken, die je op z’n minst zelf kunt testen en waarvan het resultaat op een transparante manier te herleiden is naar de geschreven code.
Het vervangt geen denken. Het zou je denken moeten versterken, en het zou je niet minder moeten laten nadenken.
Goed gebruikt kan het krachtig zijn. Maar je moet nog steeds weten wat je wilt bouwen. Je moet de structuur ownen. Je moet de ruis filteren. Je moet AI-geklets herkennen als je het ziet. Je moet het proces leiden.
Anders bouw je geen prototype. Dan genereer je alleen gokken.
De toekomst is niet AI-first. De bedrijven die ertoe doen blijven human-first. Zij begrijpen het probleem voordat ze een tool kiezen. En ze blijven de enige vraag stellen die telt, voordat ze AI te hulp roepen:
Wat lossen we nu eigenlijk op?
