Vibe coding heeft zijn belofte gebroken

Besteed een uur aan een willekeurig forum van mensen die software bouwen en je vindt dezelfde bekentenis in honderd verschillende bewoordingen. Iemand bouwde zijn app in een weekend met een AI-hulpmiddel. Het werkte. Hij bracht het uit. Nu is het maandag, de authenticatie is stuk, de database laat stilzwijgend rijen vallen en de fout die niemand kan reproduceren is de fout die hem klanten kost.

De droom die we elkaar zes maanden geleden verkochten, staat nu aan de deur en wil zijn geld terug.

Ik wil voorzichtig zijn met hoe ik dit zeg, want ik denk niet dat de mensen die deze hulpmiddelen bouwden of gebruikten ongelijk hadden met hun enthousiasme. De sprong was echt. Kijken hoe een werkende interface uit een alinea gewoon Nederlands tevoorschijn komt, is een van de werkelijk magische ervaringen van het afgelopen softwaredecennium. Ik voelde het ook. Wij allemaal.

Maar ergens tussen de demonstratie en de uitrol vond een stille vervanging plaats. We begonnen prototypes producten te noemen. We begonnen demonstraties software te noemen. En de rekening voor die verwarring komt nu.

De verkeerde diagnose

De meest voorkomende verklaring die ik hiervoor zie, wijst naar het model. De AI is nog niet slim genoeg. Ze verzint dingen. Ze kiest de verkeerde bibliotheken. Ze schrijft code die iemand met veel ervaring in de ontwikkeling zou onderscheppen en herschrijven.

Die verklaring is troostend omdat ze een oplossing suggereert die al onderweg is. Wacht zes maanden. Het volgende model is beter. Uiteindelijk sluit het gat en werkt alles.

Ik geloof dat niet. En ik geloof het niet omdat de manier van falen die ik steeds zie niets te maken heeft met hoe goed de code is.

Microsoft meldde bij de jaarcijfers van 2025 dat ongeveer 46 procent van alle code die door actieve gebruikers van GitHub Copilot wordt ingestuurd nu door AI is gegenereerd. Rond dezelfde tijd publiceerde het beveiligingsbedrijf Veracode onderzoek waaruit bleek dat door AI gegenereerde code in ongeveer 45 procent van de onderzochte steekproeven veiligheidslekken introduceerde. Die cijfers worden slechter voordat ze beter worden, en een slimmer model lost ze niet op.

Het model is niet het probleem. Het proces wel.

Wat er werkelijk ontbreekt

Loop met me door hoe een met vibe coding gemaakte app ontstaat en wijs me aan waar de architectonische beslissing valt.

Je beschrijft wat je wilt. De AI levert een interface en wat code erachter. Je kijkt naar de interface, je klikt rond, ze doet ongeveer wat je hebt gevraagd, en je verklaart het af. Op geen enkel punt in die lus heeft iemand, mens of machine, stilgestaan om te bepalen wat er eigenlijk gebouwd werd.

Er is geen schema. Er is geen gegevensmodel. Er is geen lijst van toestanden waarin het systeem kan zijn en geen bepaling van wat als geldig geldt. Er is geen contract tussen de frontend en wat zich voordoet als een backend. Er is geen beslissing over wat er gebeurt wanneer de gebruiker iets doet wat de generator niet had voorzien, want niemand had het voorzien.

Wat er gebouwd is, is een ding dat lijkt op het ding dat je hebt gevraagd, op precies het pad dat je tijdens de demonstratie toevallig hebt gelopen. Verlaat dat pad en de hele structuur blijkt een steiger. Eronder heeft nooit een gebouw gestaan.

Dat is geen falen van intelligentie. Het is een falen van bepaling. En geen hoeveelheid extra intelligentie toegepast op een onbepaald probleem levert een bepaald resultaat. Ze levert alleen een overtuigender versie van dezelfde steiger.

De drie beslissingen die nooit zijn genomen

Ik word concreet, want abstracties zijn de reden dat dit gesprek in rondjes blijft draaien.

Authenticatie is geen functie die je later toevoegt. Het is een beslissing over wie je gebruikers zijn, wat ze mogen zien en op welke vertrouwensgrens je toepassing staat. Die twee weken na de start aan een met vibe coding gemaakte app vastschroeven is het softwaresequivalent van een voordeur plaatsen in een huis dat zonder muren is gebouwd.

Het schema van een database is niets wat een AI zou moeten raden terwijl ze het formulier oplevert dat erin schrijft. Het schema is de rugsteun van de toepassing. Elke beslissing verderop (wat je kunt opvragen, wat je kunt indexeren, wat je later kunt veranderen zonder alles te breken) wordt begrensd door keuzes die vooraf zijn genomen of juist niet. Wanneer het schema wordt geïmproviseerd, is elke toekomstige verandering een verbouwing.

Een API-contract is niet optioneel, en in een economie waarin AI-agenten software direct afnemen staat het dichter bij het product dan de interface. Zodra jouw app met iets anders praat (een betalingsverwerker, een e-maildienst, een ander stuk software, een AI-agent) moet er een bepaald oppervlak zijn. Zonder dat worden integraties een reeks eenmalige noodoplossingen die niemand kan onderhouden en niemand wil erven.

Dit zijn geen gevorderde onderwerpen. Het is het minimum om software te bouwen die langer leeft dan haar eerste weekend. En het is precies wat wordt overgeslagen wanneer het hele bouwproces bestaat uit beschrijven, kijken, uitbrengen.

Het 70-procentprobleem heeft nu een naam

Ik denk niet dat iemand zich voornam een sector te bouwen die brakke software uitbrengt. Ik denk dat de hulpmiddelen die in deze categorie ontstonden optimaliseerden voor het moment dat het hulpmiddel verkoopt: het magische moment waarop een idee in minder dan een minuut een werkend scherm wordt.

De tijd tot de magie werd het meetbare. De tijd tot productie was het probleem van iemand anders.

Dat is een redelijke optimalisatie voor een demonstratie. Het is een verschrikkelijke optimalisatie voor een softwarecategorie die nu verantwoordelijk is voor het uitbrengen van echte toepassingen aan echte gebruikers met echt geld in het spel. Ze laat een hele generatie bouwers stranden op de 90 procent, met een ding dat op hun scherm werkt en overal elders afbrokkelt.

Bouwers in de Lovable-gemeenschap gaven dit een naam: het 70-procentprobleem. Je komt bij iets dat bijna af lijkt, en dan houdt de voortgang op. Elke reparatie breekt iets anders. Het resterende werk is geen werk waar je je met prompts door heen kunt praten, want wat je blokkeert is geen ontbrekende code. Het is een ontbrekende beslissing, stilzwijgend genomen, enkele honderden generaties eerder.

Het smerige geheim van deze categorie is dat het makkelijke deel de eerste 90 procent was. De volgende 9 procent, het ding werkelijk laten werken voor meer dan één gebruiker, op meer dan één apparaat, onder omstandigheden die je niet had voorzien, is moeilijker dan de eerste 90 procent samen. En de laatste procent, het deel dat een werkende toepassing onderscheidt van een brakke, is het deel dat vraagt dat je vóór de start wist wat je bouwde.

De regel die de AI niet heeft veranderd

Hier is het punt dat niemand wil horen, want het klinkt als een stap terug in een moment dat helemaal uit voorwaartse beweging zou moeten bestaan.

De beste software is altijd begonnen met een bepaling. Architectuur vóór code. Een helder model van het probleem voordat er een regel wordt geschreven. Dat gold toen teams van vijftig mensen systemen met de hand bouwden, en het geldt nu één persoon en een model hetzelfde systeem in een weekend kunnen bouwen.

De AI heeft die regel niet veranderd. De AI heeft hem belangrijker gemaakt, niet minder.

Wanneer de kosten van het opleveren van code naar nul gaan, gaan ook de kosten van het opleveren van de verkeerde code naar nul. Wat betekent dat het enige dat nog kost, is uitzoeken wat de juiste code zou zijn geweest. Dat werk (het bepalingswerk, het architectuurwerk, het deel waarin je beslist wat je werkelijk bouwt voordat je begint te bouwen) is het enige deel dat geen ongedifferentieerde waar is geworden.

Het is ook het deel dat de huidige generatie hulpmiddelen heeft overgeslagen.

Waar dit werkelijk naartoe gaat

Ik denk niet dat het antwoord vertragen is. Ik denk niet dat het antwoord is alles weer met de hand te schrijven. De sprong was echt, en de sprong blijft.

Het antwoord is de bepalingsstap in de lus bouwen, de praktijk die de sector nu specificatiegestuurde ontwikkeling noemt. Niet als handmatige poort die je ophoudt, maar als het werkelijke fundament waarop het overige werk rust. De mensen die uitzoeken hoe dat moet, werken aan iets stillers dan wat je tot nu toe hebt gezien. Ze staan op het punt de luide versie van deze categorie te laten lijken op wat ze altijd was. Over hoe die volgende generatie er werkelijk uitziet schreef ik apart.

Een werkend scherm is nooit hetzelfde geweest als een werkend systeem. We staan allemaal op het punt ons te herinneren waarom.

Verwante lectuur

Wat de plaats ervan innam: specificatiegestuurde ontwikkeling. Hoe de hulpmiddelen er nu voor staan: de beste AI-appbouwers in 2026.

Veelgestelde vragen

Wat betekent «vibe coding»? Vibe coding is software schrijven door in gewone taal te beschrijven wat je wilt en te aanvaarden wat de AI oplevert, zonder de architectuur, het gegevensmodel of de contracten eronder vast te leggen. Andrej Karpathy muntte de term begin 2025. Het beschrijft een manier van werken, geen categorie hulpmiddelen: vibe coding kan in bijna elke AI-bouwer.

Waarom breken met vibe coding gemaakte apps in productie? Omdat het falen structureel is en geen kwestie van codekwaliteit. De generatielus levert nooit een schema op, geen bepaalde verzameling geldige toestanden en geen contract tussen frontend en backend. De toepassing werkt op het pad waarop ze is voorgedaan en brokkelt daarbuiten af. Een slimmer model toegepast op een onbepaald probleem levert nog steeds een onbepaald resultaat.

Wat is het 70-procentprobleem? Het patroon waarin een door AI gebouwde toepassing ongeveer 70 procent gereed raakt en dan niet meer vordert: elke reparatie breekt iets anders en meer prompts sluiten het gat niet. De blokkade is doorgaans een architectonische beslissing die honderden generaties eerder stilzwijgend is genomen en niet meer te veranderen valt zonder herbouw.

Is door AI gegenereerde code minder veilig? Het huidige bewijs zegt dat die nagekeken moet worden. Het onderzoek van Veracode vond dat door AI gegenereerde code in ongeveer 45 procent van de onderzochte steekproeven veiligheidslekken introduceerde, op een moment dat Microsoft meldde dat ongeveer 46 procent van de door actieve Copilot-gebruikers ingestuurde code door AI was gegenereerd. Het volume groeit sneller dan de verificatie.

Betekent dit dat AI-appbouwers niet gebruikt moeten worden? Nee. Voor prototypes, demonstraties en interne hulpmiddelen zijn ze werkelijk uitstekend en is de snelheid echt. Het argument hier is nauwer: een werkend scherm is geen werkend systeem, en de hulpmiddelen die de bepalingsfase overslaan kunnen het tweede niet opleveren, hoe goed het model ook wordt.