Een nuchtere, praktische gids over vibe coding: wat de term betekent, hoe de workflow er in de praktijk uitziet, waar het stilletjes misgaat, en hoe je eindigt met een echte applicatie die van jou is in plaats van een demo die omvalt zodra een vreemde hem voor het eerst gebruikt.
Beginnende bouwers, founders, productmensen en developers die sneller willen bouwen door software te beschrijven in plaats van elke regel zelf te typen.
- Een helder beeld van wat vibe coding wel en niet is
- Een herhaalbare loop om van een zin naar een werkende versie te gaan
- De gewoontes die het verschil maken tussen een echte app en een wegwerp-demo
Vibe coding heeft van software beschrijven een volwaardige manier van bouwen gemaakt. In deze gids lees je wat de term echt betekent, hoe de workflow er dag in dag uit uitziet, welke valkuilen niemand je vertelt, en hoe je eindigt met een echte applicatie in plaats van een demo die barst zodra een vreemde hem aanraakt.
Andrej Karpathy muntte de term begin 2025, en hij bleef hangen omdat hij iets benoemde wat mensen al deden. In plaats van elke regel zelf te typen, beschrijf je in gewone taal wat je wilt en laat je een model de code schrijven. Je leest het resultaat, draait het, ziet wat er niet klopt en vraagt om de volgende aanpassing. De loop voelt meer als regisseren dan als typen.
Het helpt om twee dingen uit elkaar te houden die vaak door elkaar lopen. Het eerste is de manier van werken: in gewone taal met een model praten. Het tweede is het fundament eronder: krijg je echte broncode en een echte database, of een configuratie die vastzit in het product van iemand anders? Die vriendelijke interactie kun je op allebei bovenop leggen. Het fundament bepaalt of wat je bouwde over zes maanden nog steeds van jou is.
Stel bij elke tool in deze categorie de vraag: heb ik aan het eind code en data die van mij zijn, of een abonnement waar ik niet uit kan? Al het andere is ondergeschikt aan dat antwoord.
Haal de hype eraf en een vibe coding-sessie heeft een vast ritme. Na een paar keer zit het in je vingers.
In plaats van "bouw een boekingsapp voor me", probeer: "Een klant kiest een vrij slot van 30 minuten voor volgende week en boekt het met naam en e-mailadres. Medewerkers zien de boekingen van de dag op één scherm. Sla klanten, slots en boekingen op, en laat nooit twee mensen hetzelfde slot boeken." De tweede briefing benoemt de mensen, de gegevens en de ene regel die ertoe doet, dus de eerste versie komt specifiek genoeg terug om te testen.
De demo's ogen altijd moeiteloos. De problemen komen later, en ze duiken telkens op dezelfde paar plekken op.
Een model produceert code die er goed uitziet, draait, en toch fout is. Het verzint soms een functie die niet bestaat, of handelt het gelukkige pad prachtig af terwijl het vergeet wat er gebeurt als een veld leeg is. De output klinkt even stellig of hij nu klopt of niet, dus je kunt niet afgaan op hoe zeker het klinkt. Controleer gedrag, niet toon.
Dit is de fout die echt geld kost. Je bouwt zo een takenapp waarin elke gebruiker stilletjes de taken van alle anderen kan lezen, omdat het model de leesquery schreef zonder het filter dat hem beperkt tot de ingelogde persoon. Niets op het scherm waarschuwt je. In je demo werkt de app prima, want jij bent de enige gebruiker. Test toegangscontrole altijd met een tweede account, en lees alles wat betalingen, wachtwoorden of persoonsgegevens raakt regel voor regel.
Iets bouwen dat grotendeels werkt is het snelle deel. Het laatste stuk, de randgevallen, de foutmeldingen, de state die uit sync raakt, daar loopt ongestructureerd vibe coding vast. Als elke aanpassing een nieuw gesprek is zonder geheugen van het vorige, draai je rondjes. De uitweg is structuur: een echte codebase die je kunt zien, versies waarnaar je kunt terugrollen, en een model dat bestanden bewerkt in plaats van elke keer alles opnieuw te genereren.
Mensen gooien vibe coding op één hoop met no-code, omdat je bij allebei geen syntax hoeft te typen. Het verschil zit in wat je aan het eind in handen hebt.
De interactie in gewone taal is een snellere ingang. Het is geen kooi. Als er echte code en data uitkomen die van jou zijn, is de grens van wat een template toelaat geen muur meer, maar het punt waarop je zelf code gaat bewerken.
Het gat tussen een speeltje en iets dat je aan klanten kunt laten zien is vooral discipline, geen talent. Een paar gewoontes doen het meeste werk.
Nee. Genoeg ervaren developers gebruiken het om sneller te werken aan scaffolding, boilerplate en eerste versies, en lezen en verfijnen daarna de delen die ertoe doen. Het verandert hoe je werkt, meer dan wie je bent.
Ja, als je de discipline van echte software vasthoudt: een helder datamodel, authenticatie vanaf het begin, versies waarnaar je kunt terugrollen, en zorgvuldige review van alles wat beveiliging of betalingen raakt. De tool moet je achterlaten met echte code en data die van jou zijn.
Onzichtbare beveiligingsgaten, vooral in toegangscontrole. Een app kan er af uitzien terwijl elke gebruiker stilletjes de data van alle anderen kan lezen. Test altijd met een tweede account en lees de gevoelige codepaden zelf.
No-code levert een configuratie op die alleen binnen één platform draait, dus je kunt niet weg zonder alles opnieuw te bouwen. Vibe coding, goed gedaan, levert echte, bewerkbare broncode op en een echte database die van jou is en die je zelfstandig kunt hosten en onderhouden.