Vibe coding is in korte tijd van een grapje op X naar het woord van het jaar gegaan. Als je erover leest wil je meestal twee dingen weten: wat is het precies, en kun je er iets mee dat je ook echt durft te gebruiken.

Wij bouwen software, en we krijgen steeds vaker projecten op ons bureau die zo gemaakt zijn. Daarom hieronder niet alleen de uitleg, maar ook wat we er in de praktijk van terugzien.

De definitie

De term komt van Andrej Karpathy, die hem in februari 2025 introduceerde. Collins English Dictionary koos vibe coding tot woord van het jaar 2025.

De kern zit in wat je niet doet. Je beschrijft in gewone taal wat je wilt, een taalmodel schrijft de code, en je leest die code niet kritisch na. Werkt het? Door. Werkt het niet? Je beschrijft het probleem en laat het opnieuw proberen. Je stuurt op het resultaat, niet op de code.

Dat is echt iets anders dan AI gebruiken bij het programmeren. Een ontwikkelaar die met Claude Code of Cursor werkt en elke wijziging nakijkt, doet niet aan vibe coding. Die gebruikt een gereedschap. Bij vibe coding is het gereedschap de bouwer.

Waar het echt goed in is

Onderschat dit niet, want het is de reden dat iedereen erover praat.

Wil je in een middag uitproberen of een idee werkt, wil je een intern hulpmiddeltje dat alleen jij gebruikt, of wil je aan iemand laten zien wat je bedoelt in plaats van het uit te tekenen: dan is dit ongelooflijk snel. Je hoeft niemand in te huren, je hoeft geen kaders te kiezen, je begint gewoon.

Voor een wegwerpversie is dat precies goed. Het gaat wringen zodra dat wegwerpding blijft.

Wat er misgaat zodra het echt gebruikt wordt

Er is een concreet voorbeeld dat het probleem beter uitlegt dan wij kunnen.

Op 29 mei 2025 werd CVE-2025-48757 gepubliceerd, een lek in applicaties gebouwd met Lovable. Van 1.645 onderzochte apps bleken er 170 zo in elkaar te zitten dat willekeurige bezoekers persoonsgegevens konden opvragen: e-mailadressen, telefoonnummers, adressen, betaalgegevens en API-sleutels. De oorzaak was geen exotische hack maar een niet ingestelde beveiligingsregel op de database, waardoor je met een publieke sleutel gewoon de tabellen kon uitlezen.

Dat is precies het soort ding dat je niet ziet als je alleen op het resultaat stuurt. De app werkte. Er stond niets fout op het scherm. Alleen stond de achterdeur open, en dat merk je pas als iemand erdoor loopt.

Wat wij in dit soort projecten het vaakst tegenkomen, in deze volgorde:

  • Beveiliging. Geen of half ingestelde toegangsregels, sleutels die in de voorkant van de app staan, formulieren die alles accepteren wat je erin stopt.
  • De database. Structuur die werkt bij tien rijen en instort bij tienduizend, ontbrekende relaties, gegevens die op drie plekken tegelijk staan.
  • Structuur. Dezelfde logica vijf keer opnieuw geschreven, want het model wist niet meer dat het dat al ergens had staan.
  • Snelheid. Werkt prima met jouw testgegevens, wordt traag met echte.
  • Onderhoudbaarheid. De vervelendste: niemand kan uitleggen waarom iets zo werkt, ook de bouwer niet, want die heeft het niet geschreven.

Het onderzoek dat je moet kennen, met de nuance erbij

In juli 2025 publiceerde onderzoeksinstituut METR een gerandomiseerd experiment onder zestien ervaren opensource-ontwikkelaars, verdeeld over 246 echte taken in projecten die ze zelf al jaren kenden.

De uitkomst was contra-intuïtief. Met AI-hulp waren ze 19 procent langzamer. Vooraf verwachtten ze 24 procent sneller te zijn, en achteraf dachten ze nog steeds dat ze 20 procent sneller waren geweest. Ze hadden dus niet alleen ongelijk, ze merkten het ook niet.

En nu de nuance, want die wordt bijna nooit meegeleverd. Dit onderzoek ging over ervaren ontwikkelaars in een codebase die ze op hun duimpje kenden. Dat is zowat de slechtst denkbare situatie voor AI-hulp: het model moet worden bijgepraat over iets wat die mensen al in hun hoofd hadden. Bouw je iets nieuws, of ken je de code niet, dan ligt het heel anders.

Wij werken zelf dagelijks met Claude Code en zijn daar sneller mee, maar wel op onze manier: het model schrijft, wij lezen elke wijziging na, en niets gaat live zonder dat een mens het heeft begrepen. Dat is het verschil met vibe coding, en dat verschil is precies waar dit onderzoek over gaat.

Wanneer moet je er iemand naar laten kijken?

Niet altijd. Blijft het bij jezelf en zit er niets in wat je kwijt zou willen raken, laat het lekker zoals het is.

Wel als een van deze dingen speelt:

  • Er komen gegevens van andere mensen in: klanten, leden, aanmeldingen, wat dan ook.
  • Er gaat geld doorheen, of het hangt aan een betaaldienst.
  • Je wilt het aan klanten laten zien of ermee naar buiten.
  • Je wilt erop verder bouwen en je merkt dat elke wijziging iets anders sloopt.

In die gevallen is de vraag niet of het werkt, maar of het houdbaar is. Wij doen daar een vaste code review op een AI-project voor: we kijken het na op beveiliging, database, structuur, snelheid en onderhoudbaarheid, en je krijgt een rapport waar in gewone taal in staat wat er moet gebeuren en wat kan wachten.

Kort samengevat

Vibe coding is code laten maken zonder hem na te kijken. Voor iets wat je weggooit is dat een uitkomst. Voor iets wat blijft draaien is het uitstel: de vragen die je overslaat komen later terug, en dan meestal op het moment dat je er het minst zin in hebt.

Het punt is niet dat AI geen code mag schrijven. Wij laten dat zelf de hele dag doen. Het punt is dat iemand hem moet lezen.

Bronnen, gecontroleerd op 24 augustus 2026: de term en het woord van het jaar via de Wikipedia-pagina over vibe coding, het lek in Lovable-applicaties via CVE-2025-48757 (gepubliceerd 29 mei 2025), en het productiviteitsonderzoek van METR uit juli 2025 onder zestien ervaren opensource-ontwikkelaars en 246 taken.