Vibe coding betekent software schrijven door in natuurlijke taal te beschrijven wat je wilt en te accepteren wat het model produceert, met weinig of geen inspectie van de onderliggende code. De engineer stuurt op gevoel in plaats van op het lezen en redeneren over de output.
Waar de term vandaan komt
Andrej Karpathy introduceerde de term begin 2025 om een manier van werken te beschrijven waarbij je "volledig meegaat in de vibes" en stopt met nadenken over de code zelf. De bedoeling was deels beschrijvend, deels ironisch. De term sloeg aan omdat hij iets benoemde dat al gaande was.
Hoe het er in de praktijk uitziet
Een developer geeft een model een prompt, voert de output uit, beschrijft de fout als iets stukgaat en itereert. Geen diff lezen. Geen vragen waarom het model een bepaalde keuze heeft gemaakt. De code wordt behandeld als een ondoorzichtig artefact. Het werkt totdat het niet meer werkt.
Dit is iets anders dan agentic coding, waarbij een coding agent meerstaps acties uitvoert in een codebase en een mens het resultaat nog steeds beoordeelt. Vibe coding draait om de afwezigheid van die beoordeling, niet om de aanwezigheid van automatisering.
Waarom het snel prototypes oplevert
Voor een wegwerp proof of concept werkt de aanpak snel. Het model pakt boilerplate, koppelingen en de voor de hand liggende structuur op. De mens let alleen op de vraag of het ding zich gedraagt zoals beschreven. De feedbackloops zijn kort.
Voor dat gebruik is de afweging vaak de moeite waard.
Waarom het prototype zelden de stap naar productie overleeft
Problemen stapelen zich op in de delen die niet zijn gecontroleerd.
Beveiliging. Modellen reproduceren gangbare patronen, inclusief gangbare kwetsbaarheden. Als je de code niet hebt gelezen, weet je niet of invoer wordt gevalideerd, secrets correct worden beheerd of toegangscontroles aanwezig zijn. Prompt injection is één specifiek risico; er zijn er veel meer.
Onderhoudbaarheid. Code die niemand begreep op het moment dat die werd geschreven, is later moeilijk te wijzigen. De volgende engineer, of dezelfde engineer drie maanden later, heeft geen mentaal model om op voort te bouwen.
Correctheid aan de randen. Modellen zijn zelfverzekerd. Ze produceren code die er goed uitziet en de voor de hand liggende gevallen afhandelt. Randgevallen, domeinspecifieke beperkingen en interacties tussen componenten zijn de plekken waar fouten zich verbergen. Dat zijn precies de dingen die niet naar boven komen in een snelle demo.
Debuggen. Als iets stukgaat in productie, moet je kunnen redeneren over de code. Als je die nooit hebt gelezen, heb je niets om op te redeneren.
Het transitieprobleem
Een vibe-gecodeerd prototype naar productie brengen is geen kwestie van "het even opschonen". Het betekent doorgaans elke regel lezen, begrijpen wat de code werkelijk doet in plaats van wat je bedoelde, de plekken vinden waar het model een plausibele maar verkeerde keuze heeft gemaakt, en beslissen wat je herschrijft. In de praktijk kost dat vaak meer tijd dan het vanaf het begin goed doen.
Dit is geen kritiek op het gebruik van AI om ontwikkeling te versnellen. Het is een beschrijving van wat genereren zonder review je later kost.
Hoe competente AI-native ontwikkeling er in plaats daarvan uitziet
Een senior engineer die AI-tools goed gebruikt, leest de output nog steeds. Ze behandelen gegenereerde code als een bekwame eerste versie, niet als een afgerond product. Ze herkennen de plekken waar het model zelfverzekerd maar fout was. Ze begrijpen het contextvenster waarbinnen het model werkte en waar het de mist in kan zijn gegaan.
Dat is een andere vaardigheid dan zowel vibe coding als traditioneel regel-voor-regel schrijven. Het is ook de vaardigheid die AI-ondersteunde ontwikkeling veilig maakt voor gebruikers. Zie hoe je AI-gegenereerde code beoordeelt voor wat dat proces inhoudt.
Waar we op testen
Vibe coding-gedrag is precies wat onze beoordeling is ontworpen om zichtbaar te maken. In de AI-native assessment werken kandidaten tickets af met de tools die ze normaal gebruiken, en wij kijken of ze daadwerkelijk lezen wat er terugkomt. De scorecardcriteria die hier het meest direct op aansluiten zijn AI-outputverificatie, dat toetst of iemand gehallusineerde API's of subtiel onjuiste logica opspoort voordat die live gaat, en oordeelsvermogen op basis van risico, dat toetst of gegenereerde code dezelfde aandacht krijgt ongeacht hoe zeker de tool klinkt. Volledige details staan bij hoe we vetten.
Korte antwoorden
Is vibe coding altijd slechte praktijk?
Niet altijd. Voor een wegwerpprototype of een persoonlijk script dat je nooit wilt onderhouden, zijn de afwegingen redelijk. Het probleem is vibe-gecodeerde output als productieklaar behandelen zonder de reviewstap die dat zou moeten waarmaken.
Hoe maak ik van een vibe-gecodeerd prototype productiecode?
Lees elke regel met dezelfde kritische blik die je zou toepassen op code van een onbekende bron. Controleer beveiligingsaannames, randgevallen en onderhoudbaarheid. Reken erop dat je aanzienlijke delen herschrijft. Het is zelden een snelle polijstklus.
Wat is het verschil tussen vibe coding en het gebruik van AI-codeertools?
Het verschil is beoordeling. AI-tools goed gebruiken betekent de output lezen en erover nadenken. Vibe coding betekent die op gevoel accepteren. De tools kunnen identiek zijn; het gedrag en de resultaten verschillen aanzienlijk.
