Wat is vibe coding, en wat het niet is

Wat betekent vibe coding?

Vibe coding betekent dat je een AI-model vertelt wat je wilt, het resultaat aanneemt zonder de code te lezen, en verder werkt op wat je op het scherm ziet. Werkt het niet, dan beschrijf je het probleem opnieuw en accepteer je de volgende versie. Je stuurt op gedrag, niet op tekst. De code is een tussenproduct dat je niet opent.

Het verschil met programmeren is niet dat er een AI meedoet. Programmeurs gebruiken dezelfde modellen. Het verschil is wat je doet met wat terugkomt. Een programmeur leest de wijziging, begrijpt waarom hij werkt en beslist of hij blijft. Een vibe coder kijkt of het scherm doet wat hij bedoelde. Beide zijn legitiem; ze zijn alleen voor andere momenten.

Wie zo bouwt, komt verrassend ver. Een werkend formulier, een lijst met filters, een pagina die er goed uitziet: dat is een avond werk zonder een regel code te lezen. Het punt van dit artikel is niet dat dat fout is. Het punt is dat je moet weten wanneer het ophoudt te volstaan.

• Beschrijven, accepteren, kijken, opnieuw beschrijven.
• Sturen op wat het scherm doet, niet op wat de code zegt.
• Hetzelfde gereedschap als programmeurs, een andere omgang met het resultaat.

Waar komt de term vandaan?

Van Andrej Karpathy, een van de bekendste onderzoekers in het vak. Hij beschreef in februari 2025 in een bericht hoe hij tegenwoordig kleine projecten bouwde: volledig meegaan met de stroom, de code vergeten, bij een foutmelding de tekst ervan in het model plakken en kijken wat er gebeurt. Hij noemde het vibe coding, en de term sloeg aan omdat hij precies benoemde wat veel mensen al deden zonder er een woord voor te hebben.

Het woord ging snel. Merriam-Webster nam het in maart 2025 op als trending, en Collins koos het eind 2025 tot woord van het jaar. Dat zegt iets over hoeveel mensen ineens bouwden die dat een jaar eerder niet konden, en dat is de kern van wat er veranderd is: de drempel om iets werkends te maken is weggevallen.

Karpathy zei er zelf bij dat het geschikt was voor wegwerpprojecten in het weekend. Dat voorbehoud is in de verspreiding van de term grotendeels verloren gegaan, en daar komt de spanning vandaan die de rest van dit artikel beschrijft.

• Andrej Karpathy, februari 2025: meegaan met de stroom, de code vergeten.
• Merriam-Webster (maart 2025) en Collins (woord van het jaar 2025) namen het op.
• Zijn eigen voorbehoud: voor wegwerpprojecten. Dat deel reisde niet mee.

Waarom werkt het zo goed voor een prototype?

Omdat een prototype maar één vraag hoeft te beantwoorden: klopt het idee? Daarvoor hoeft de code niet mooi, veilig of onderhoudbaar te zijn. Hij hoeft te doen wat je bedoelde, lang genoeg om het aan iemand te laten zien. Vibe coding is daar de snelste weg naartoe die er ooit is geweest, omdat elke stap tussen idee en scherm is weggevallen.

Het werkt ook omdat je fouten goedkoop zijn. Een prototype dat verkeerd loopt gooi je weg en begin je opnieuw; er zijn geen gegevens die verloren gaan, geen bezoekers die iets merken, geen rekening die doorloopt. In die omgeving is niet-lezen geen risico maar tijdwinst. Elke minuut die je aan code besteedt die je morgen weggooit, is een minuut die je niet aan het idee besteedt.

En het werkt omdat de tools erop gebouwd zijn. Lovable, Bolt, v0, Replit en hun soortgenoten geven je een omgeving waarin het resultaat direct draait, met een database om te proberen en een adres om te delen. Ze zijn gemaakt voor dit tempo. Wat ze niet doen, is je vertellen wanneer het tempo moet veranderen.

• Een prototype beantwoordt één vraag: klopt het idee.
• Fouten kosten niets zolang er geen gegevens, bezoekers of rekeningen zijn.
• De bouwtools zijn op dit tempo gemaakt; het moment om te schakelen zit er niet in.

Wat is de kritiek, en klopt die?

De kritiek komt neer op drie dingen: je begrijpt niet wat er staat, wat er staat is vaker onveilig, en wat er staat is moeilijker te onderhouden. Het eerste is per definitie waar; niet-lezen is het uitgangspunt. Het tweede en derde zijn onderzocht. Een analyse van CodeRabbit uit december 2025 vond in code die samen met een AI geschreven was meer logische fouten en meer beveiligingsproblemen dan in code van mensen alleen. GitClear zag over 2025 minder opruimwerk en meer gekopieerde code in repositories dan in de jaren ervoor. De precieze getallen staan in de bron onderaan; ze hangen af van hoe je meet.

Klopt de kritiek? Voor een prototype niet, want daar zijn onderhoud en beveiliging geen doelen. Voor iets wat live staat wel, en dan volledig. Een formulier dat werkt maar zijn invoer niet controleert, een wachtwoord dat in de code staat omdat dat sneller was, een database die iedereen mag lezen: dat zijn geen theoretische risico's maar de standaardfouten van code die niemand gelezen heeft.

De kritiek gaat dus niet over de methode maar over het moment. Vibe coding is niet slecht. Vibe coding op een project met echte mensen erin is een gok die je pas verliest als het te laat is om nog te lezen.

• Drie bezwaren: begrip, beveiliging, onderhoud. Het eerste is per definitie waar.
• Onderzoeken van CodeRabbit (2025) en GitClear (2025) vinden meer fouten en meer kopieerwerk; de maat verschilt per onderzoek.
• Voor een prototype maakt het niet uit. Voor iets wat live staat maakt het alles uit.

Wat is vibe coding niet?

Het is geen synoniem voor bouwen met AI. Iemand die een model laat schrijven en elke wijziging leest, doet iets anders, ook al gebruikt hij dezelfde tool en dezelfde prompts. Het is ook geen synoniem voor slecht werk: er bestaan uitstekende prototypes die niemand gelezen heeft, en dat is hun kracht. En het is geen vaardigheid die je moet afleren. Het is een stand die je aan en uit zet.

Het is ook niet gratis. Wie op deze manier bouwt, verbruikt tokens, en de rekening daarvoor loopt door of je de code nu leest of niet. Een model dat driemaal opnieuw probeert omdat de beschrijving vaag was, kost driemaal zoveel. Het artikel over wat een miljoen tokens kost gaat daarover.

En het is niet af als het werkt. Een prototype dat werkt is het begin van een lijst die de bouwtool niet voor je maakt: eigendom van de code, een adres, gegevens die blijven staan, sleutels buiten de code. Die lijst heet de klif, en het is de plek waar vibe coding overgaat in iets anders.

• Niet hetzelfde als bouwen met AI: het verschil is of je leest.
• Niet slecht, niet af te leren; een stand die je bewust kiest.
• Niet gratis, en niet af als het werkt.

Hoe ga je van accepteren naar begrijpen?

Niet door te leren programmeren. Door drie gewoontes die een niet-programmeur in een week heeft. De eerste: vraag het model na elke wijziging wat het veranderd heeft en waarom, in gewone taal, en lees dat antwoord wel. Je hoeft de code niet te begrijpen om te snappen dat er nu een wachtwoord in staat, of dat het formulier alles doorlaat wat je intikt.

De tweede: zet je project in versiebeheer, zodat elke wijziging een voor en een na heeft. Dan zie je niet alleen dat het anders werkt, maar welke regels er anders zijn, en kun je terug als het misging. Vijf begrippen zijn genoeg; die staan in het artikel over Git en GitHub.

De derde: bepaal het moment waarop je schakelt. Een goede regel is de eerste vreemde. Zolang alleen jij het gebruikt, mag alles. Zodra iemand anders gegevens invoert, lees je wat er met die gegevens gebeurt, en loop je de veiligheidschecklist door. Dat is geen ander vak. Dat is dezelfde tool, met een tweede spoor eronder.

• Na elke wijziging: laat het model uitleggen wat er veranderde, en lees dat.
• Versiebeheer: elke wijziging een voor en een na.
• Schakelmoment: de eerste vreemde die gegevens invoert.

Bronnen

Nagelopen op 5 september 2026. De onderzoeken van CodeRabbit en GitClear zijn via het encyclopedie-artikel aangehaald en niet zelf opgehaald; daarom staan hun getallen hier niet.

• Wikipedia, Vibe coding
• OWASP, LLM01:2025 Prompt Injection

Verder lezen

Drie plekken die hierop aansluiten.