Wat is Vibe Coding, Eigenlijk?

De term "vibe coding" verspreidde zich snel in 2024-2025 omdat het iets benoemt wat veel developers al stilletjes deden: beschrijven wat ze willen in gewoon Engels aan een model als GPT-4, Claude, of een tool als Cursor of GitHub Copilot, en het laten genereren van de meeste daadwerkelijke code. De programmeur blijft in het proces, maar het proces ziet er anders uit dan traditioneel programmeren.

De daadwerkelijke definitie

Andrej Karpathy bedacht de uitdrukking en beschreef een workflow waarbij je "je volledig overgeeft aan de vibes" — je geeft een prompt, accepteert suggesties, voert de code uit, ziet wat kapotgaat, en geeft opnieuw een prompt. Je leest niet elke diff regel voor regel. Je stuurt op resultaat: doet de app wat het hoort te doen, slaagt de test, render de pagina correct. De vaardigheid verschuift van het schrijven van syntax naar het duidelijk beschrijven van bedoeling en het herkennen wanneer output fout is.

Dit verschilt van simpelweg autocomplete gebruiken. Copilot-achtige inline suggesties nemen nog steeds aan dat je de functie zelf schrijft met wat hulp om regels af te maken. Vibe coding gaat ervan uit dat het model de functie schrijft, het bestand, soms de hele feature, en jij beoordeelt en stuurt om in plaats van van nul af aan te schrijven.

Hoe een echte sessie eruitziet

Een typische vibe-coding loop met een tool als Cursor of Replit's Agent mode verloopt ongeveer als volgt:

1. Prompt: "Voeg een rate limiter toe aan deze Express API, 100 requests per 15 minuten per IP, return 429 met een JSON error body."
2. Het model bewerkt middleware/rateLimit.js, verbindt het in app.js, misschien trekt het express-rate-limit erbij.
3. Je voert npm test uit of hit het endpoint met curl in een loop om te controleren dat de 429 werkelijk afgaat.
4. Iets klopt niet — de limiter reset bij elke deploy omdat het in-memory is. Je zegt dat.
5. Het model vervangen door een Redis-backed store, voegt de ioredis dependency toe, update het docker-compose bestand.
6. Je test opnieuw, het werkt, je commit.

Geen regel van die middleware werd met de hand getypt. Maar zes of zeven beoordelingen werden gemaakt door een mens: wat de limiet moest zijn, dat in-memory storage fout was voor productie, dat het docker-compose bestand ook updated moest worden.

Waar het goed werkt

Vibe coding is sterk voor boilerplate-intensief werk: CRUD endpoints, form validation, test scaffolding, config files, glue code tussen twee API's die je al kent. Het is ook goed voor prototyping — een werkende demo van een idee in een uur opzetten in plaats van een dag, en dan beslissen of het het moeite waard is om goed uit te bouwen.

Het is echt snel voor solo devs en kleine teams die interne tools of MVP's uitleveren waar de prijs van een bug laag is en iteratiesnelheid meer uitmaakt dan architecturale zuiverheid.

Waar het faalt

De faalmode waar mensen niet genoeg over praten: modellen produceren code die draait maar subtiel fout is op manieren die pas later opvallen. Een gegenereerde SQL query werkt misschien voor het happy path maar is kwetsbaar voor injection omdat string concatenatie goed leek voor het model. Een gegenereerde auth check slaagt misschien tests maar slaat een role check over op één route. Als je de code niet leest, zul je dat niet zien — je ziet gewoon de tests slagen en ship het.

Dit speelt meer mee in beveiligingsgevoelige code dan bijna overal anders. Simon Willison en anderen hebben erop gewezen dat vibe-coded projecten met echte gebruikersdata dezelfde review rigor nodig hebben als andere code, eigenlijk meer, omdat degene die het "schreef" mogelijk niet kan uitleggen wat het doet regel voor regel.

Complexe systemen met veel impliciete toestand — gelijktijdigheid, gedistribueerde transacties, alles met subtiele timing bugs — zijn ook slecht geschikt. Modellen genereren meestal plausibel ogende code voor deze gevallen die faalt op manieren die moeilijk te debuggen zijn, precies omdat niemand, mens noch model, de edge cases van tevoren volledig gemodelleerd heeft.

De vaardigheid die nu echt uitmaakt

Als je vibe coding doet, is de waardevolle vaardigheid niet typsnelheid, maar specificatie. Vage prompts geven vage, buggy code. Specifieke prompts — met exacte bibliotheekna men, verwachtingen voor foutafhandeling, en edge cases aangegeven — geven veel betere output. De tweede meest waardevolle vaardigheid is code snel genoeg lezen om te zien wat fout is, wat betekent dat je de taal en het domein nog steeds moet begrijpen, ook al typ je niet elke character.

Behandel AI-gegenereerde code zoals je een pull request van een junior dev zou behandelen die snel is maar soms overconfident: nuttig, vaak correct, maar het waard om werkelijk te reviewen voordat het production aanraakt.

Wil je dieper gaan in het schrijven van code met AI-tools zonder de controle op kwaliteit kwijt te raken? Check Korra Studio's AI en Python segmenten voor hands-on walkthroughs.