Vibe coding: een app bouwen zonder de code te lezen

Het is zaterdagavond en je bent al drie uur bezig met een AI-tool die voor je programmeert. Je typt "maak die knop groter", "voeg een inlogscherm toe", "los deze foutmelding op" en plakt de melding er zonder verder commentaar bij. Elke keer verschijnt er nieuwe code, je klikt op "Accept All" en de app doet het weer. Wat er precies is veranderd, heb je allang niet meer bekeken. Het werkt, dus je gaat door.

Dat is eigenlijk hetzelfde als een verbouwing laten doen door alleen te zeggen "maak het maar gezellig" en nooit naar de bouwtekening te kijken. Zolang de aannemer goed werk levert gaat dat prima, en je merkt pas dat een leiding verkeerd loopt als de kraan een keer lekt. Zo werkt het ook met AI-code: je stuurt op gevoel in plaats van op controle. Dat gaat lang goed, tot het misgaat op precies de plek waar je niet keek.

Die manier van bouwen heeft inmiddels een naam: vibe coding. AI-onderzoeker Andrej Karpathy muntte de term begin 2025 en omschreef hem zo: je geeft je volledig over aan de vibes, vergeet dat de code eigenlijk bestaat, en drukt op "Accept All" zonder de wijzigingen te lezen. De term ging binnen weken de hele wereld over en staat inmiddels te boek als een van de meest toonaangevende nieuwe woorden van het jaar.

De term is intussen breder gaan leven dan Karpathy's letterlijke "ik lees de diffs niet meer". In de praktijk gebruikt bijna iedereen "vibe coding" voor het hele spectrum van AI-geassisteerd programmeren, van een wegwerp-weekendprojectje tot professionele software-engineers die AI inzetten in serieuze trajecten. Handig is daarom het onderscheid dat programmeur Simon Willison maakte: zodra je de code die AI schrijft leest en begrijpt, ben je niet meer aan het vibe-coden, dan doe je AI-ondersteund engineeren. Dat is geen woordspelletje: het bepaalt hoeveel risico je neemt.

Zodra je dat onderscheid kent, snap je meteen waarom vibe coding twee compleet verschillende reputaties heeft. Voor prototypes, interne tools zonder gevoelige data, en gewoon leren en experimenteren is het goud waard: je test een idee in een avond in plaats van in een maand. Voor productiesystemen die klanten echt gebruiken, alles met betalingen, en alles met persoonsgegevens ligt dat anders. Juist de code die je niet leest, zoals de logica achter inloggen en rechten, kan er prima uitzien en toch gaten hebben. Hoe verder een project van "prototype" af staat, hoe meer reden er is om alsnog te gaan lezen.

• Ondernemer (MKB): je wilt in een weekend testen of een idee voor een interne tool werkt, voordat je geld steekt in een echte ontwikkelaar.
• Zzp'er: je bouwt snel een demo om een idee aan een klant of opdrachtgever te laten zien, nog niet het uiteindelijke product.
• Office/administratie: je zet een klein hulpmiddel op voor intern gebruik, waarbij een foutje weinig kost omdat er geen klant of geld bij betrokken is.
• Corporate teams (manager, product, IT): de manager wil in een middag een idee testen zonder een hele sprint te reserveren, een product­team maakt snel een interne demo, en IT weet dat er alsnog een check moet komen voordat iets echte data raakt.

1. Bepaal eerst wat er op het spel staat: een prototype of leerproject (lage inzet) of iets dat klanten, geld of persoonsgegevens raakt (hoge inzet).
2. Bij lage inzet: vibe er gerust op los, maar lees de foutmeldingen die je terugplakt toch even, dat helpt je snappen wat er gebeurt.
3. Zet nooit een wachtwoord of API-sleutel rechtstreeks in de code of de prompt; laat de AI dat via een omgevingsvariabele regelen.
4. Zodra een project serieuzer wordt, vraag de AI dan expliciet om een beveiligingscheck van inloggen en rechten voordat je live gaat.
5. Vertrouw geen pakketnaam die AI zomaar installeert zonder die zelf even op te zoeken; AI kan de naam van bestaande software verzinnen.
6. Breng vóór een echte lancering traditionele discipline terug: laat een mens meelezen, test het, en scan het op risico's voordat het écht gebruikt wordt.

Een ondernemer bouwt in een weekend, puur voor de lol, een besteltool voor zijn webshop. Hij typt wensen in, klikt telkens "Accept All", en na een paar uur staat er een werkende versie. Hij is dolblij en wil hem maandag meteen live zetten, inclusief het verwerken van echte bestellingen en betalingen.

Zijn zwager, die wel programmeert, kijkt voor de zekerheid mee. Die vindt binnen tien minuten dat betaalgegevens zonder enige controle worden opgeslagen en dat een wachtwoordveld gewoon leesbare tekst doorstuurt. Niets daarvan was zichtbaar in de app zelf: die werkte perfect. Als interne tool om zelf mee te oefenen was het weekendproject prima geweest. Als systeem voor echte klanten en echt geld was het bijna een groot probleem geworden, precies omdat niemand de code had gelezen.

• Gebruik dit morgen bij een idee dat je snel wilt testen: vibe een prototype in elkaar en beoordeel het idee, niet de code.
• Gebruik dit morgen bij een AI-foutmelding: plak hem letterlijk terug in plaats van hem samen te vatten, dat werkt beter dan zelf herformuleren.
• Gebruik dit morgen zodra een weekendproject serieus dreigt te worden: vraag expliciet om een beveiligingscheck van login, rechten en data voordat je verdergaat.
• Gebruik dit morgen bij elk stuk gegenereerde code met een sleutel of wachtwoord erin: verplaats die meteen naar een omgevingsvariabele.

Alle modellen (ChatGPT, Claude, Gemini, Copilot)

Leg in gewone taal uit wat je zojuist hebt veranderd in de code en
waarom. Geen technisch jargon, gewoon: wat werkte er niet, en wat
doet jouw oplossing nu anders.

Alle modellen: beveiligingscheck voor je live gaat

Ik wil dit project echt gaan gebruiken (met [echte klanten /
betalingen / persoonsgegevens, vul aan wat van toepassing is).
Doorloop de code die met inloggen, rechten en het opslaan van
gegevens te maken heeft, en wijs specifiek aan waar iemand toegang
zou kunnen krijgen tot iets waar hij niet bij mag, of waar gevoelige
gegevens onbeveiligd worden opgeslagen. Geen algemene geruststelling,
concrete zwakke plekken graag.

• "Accept All" klikken op elke wijziging zonder ooit te vragen wat er precies verandert.
• Een weekendprototype zonder extra check openzetten voor echte klanten of echte betalingen.
• Wachtwoorden of API-sleutels rechtstreeks in de code laten staan in plaats van als omgevingsvariabele.
• Denken dat "het werkt in de browser" hetzelfde is als "het is veilig gebouwd".
• Een pakket of library laten installeren zonder te checken of die naam echt bestaat.

• Weet altijd of je aan het vibe-coden bent (niet lezen, op gevoel) of aan AI-ondersteund bouwen (wel lezen en begrijpen); maak daar een bewuste keuze van, geen toeval.
• Gebruik vibe coding voluit voor prototypes, interne tools zonder gevoelige data, en om te leren.
• Bouw discipline terug, code laten meelezen, testen, een beveiligingscheck, zodra er echte gebruikers, geld of persoonsgegevens bij komen kijken.
• Bewaar nooit geheimen in code of prompt; altijd via een omgevingsvariabele.

Pak een klein idee waar je al een tijdje over nadenkt. Open een AI-codeertool en vibe in een paar minuten een eerste versie in elkaar zonder ook maar één wijziging te lezen. Vraag de AI daarna alsnog om in gewone taal uit te leggen wat er precies is gebouwd, en beoordeel eerlijk: zou je dit zo naar echte gebruikers durven sturen? Zo niet, wat zou je eerst willen laten checken?