We moeten stoppen met alles Vibe Coding te noemen

Ik ben na een lange pauze weer gaan programmeren, en Lovable was de plek waar ik het oppakte. De apps zagen er geweldig uit, werkten op het eerste gezicht, en kwamen binnen een paar uur tot stand. In het begin voelde dat opmerkelijk. Maar het was niet meer genoeg op het moment dat ik wilde weten wat de code deed – en waarom. Dat was het moment waarop mijn aanpak begon te veranderen.

Het verschil gaat niet over het hulpmiddel, of hoeveel van de code AI voor je schrijft. Het gaat over het contract dat je aangaat met je output: of je kunt uitleggen wat je net in de wereld hebt vrijgegeven, al dan niet.

Vibe coding betekent in de oorspronkelijke betekenis dat je AI‑gegenereerde software accepteert zonder deze goed te onderzoeken of te begrijpen wat eronder zit. AI‑ondersteunde ontwikkeling is anders. Het model kan nog steeds het grootste deel van de code schrijven, maar de persoon die het systeem bouwt blijft verantwoordelijk voor het begrijpen van het gedrag, het testen van de aannames en het bepalen of het klaar is om te worden uitgebracht.

Voor een wegwerpexperiment dat nooit jouw eigen machine verlaat, kan het onderscheid weinig gevolgen hebben. Zodra de software wordt uitgerold, door anderen wordt gebruikt of wordt gekoppeld aan echte data, is het enorm belangrijk.

Hoe “Vibe Coding” zijn betekenis verloor

De term “vibe coding” werd in februari 2025 bedacht door Andrej Karpathy, mede‑oprichter van OpenAI. Zijn voorbeeld was bewust nonchalant: een “wegwerkwkendproject” dat werd gebouwd door automatisch op “Accept All” te klikken, de verschillen te negeren en de code te laten groeien voorbij zijn begrip.

Enkele weken later merkte ontwikkelaar en tool‑maker Simon Willison op dat de term heel anders werd gebruikt: als een synoniem voor elke vorm van AI‑ondersteunde programmering, wat volgens hem de term verwatert en een vals beeld schetst van wat verantwoord AI‑ondersteund ontwikkelen kan bereiken.

Wat opvallend is, is dat Karpathy uiteindelijk instemde. Een jaar later introduceerde hij een andere term voor meer gedisciplineerd werk met code‑agents. Hij beschreef “agentic engineering” als een werkwijze waarbij ontwikkelaars agents aansturen en toezien in plaats van simpelweg te accepteren wat ze produceren. Het onderscheid is cruciaal: professionele AI‑ondersteunde ontwikkeling vereist planning, nauwkeurige controle en verantwoording, iets wat casual vibe coding niet biedt.

De lijn is verantwoordelijkheid

Willison’s regel is simpel, en hij werkt als een test voor iedereen: commit geen code die je niet aan een ander kunt uitleggen. Dat betekent niet dat je elke enkele regel moet lezen: met agents die honderden regels tegelijk genereren, doen zelfs ervaren ontwikkelaars dat niet meer. Het betekent de kernlogica begrijpen en kunnen verantwoorden waarom de code precies doet wat hij doet. Als je dat kunt, maakt het niet uit of een model het heeft geschreven of jij: dat is geen vibe coding, maar een hulpmiddel om software te bouwen.

Onderzoek gepubliceerd in december 2025 ondersteunt dat onderscheid. Op basis van veldobservaties en een kwalitatieve enquête onder professionele ontwikkelaars ontdekten de onderzoekers dat ervaren beoefenaars controle behielden over software‑ontwerp en implementatie in plaats van het volledige proces aan AI over te dragen. Ze behandelden agents als medearbeiders, planden hun werk zorgvuldig en bleven betrokken bij het toezicht.

Ervaring alleen verklaart het dus niet. Het gaat erom of je bereid bent verantwoordelijkheid te nemen voor wat AI heeft gegenereerd. Dat is een beslissing die elke ontwikkelaar steeds opnieuw moet nemen bij elk project.

Wat er gebeurt als controle ontbreekt

De gevolgen van het uitbrengen van software zonder de beveiliging te begrijpen of te verifiëren zijn niet abstract. Tea, een app die vrouwen veilig moet houden tijdens het daten, lekte tienduizenden ID‑foto’s en meer dan een miljoen privé‑berichten in twee beveiligingsincidenten. De fouten omvatten een onbeveiligde opslag‑bucket en een aparte database die zonder authenticatie toegankelijk was.

Hetzelfde onderliggende probleem – software die lijkt te werken terwijl de autorisatielogica gevaarlijk fout is – kwam naar voren in een applicatie gebouwd op het Lovable‑platform: beveiligingsonderzoek ontdekte dat de autorisatielogica omgekeerd was, waardoor ingelogde gebruikers werden buitengesloten terwijl ongeauthenticeerde aanvallers vrij toegang kregen, met meer dan 18.000 getroffen gebruikers, waaronder studenten.

Dit zijn geen geïsoleerde gevallen die alleen bij “slechte” projecten voorkomen. Volgens Google’s DORA‑rapport 2025 gebruikt 90 % van de ontwikkelaars nu AI op het werk, terwijl ongeveer een derde weinig of geen vertrouwen heeft in wat het genereert.

AI‑gebruik is nu wijdverspreid, hoewel het vertrouwen beperkt blijft. En dat maakt zorgvuldige controle des te belangrijker wanneer gegenereerde code authenticatie, permissies of gevoelige gegevens behandelt.

Controle wordt laag voor laag opgebouwd, niet in één keer

In mijn geval begon ik niet met een formele beveiligingsaudit. Ik weigerde simpelweg door te gaan telkens wanneer ik niet kon uitleggen waarom iets zich gedroeg zoals het deed – een natuurlijk instinct dat ik als analist meeneem. Ik geef minder om de syntaxis dan om te weten of het resultaat overeenkomt met wat we oorspronkelijk nodig hadden. Als dat niet zo is, graaf ik verder.

Mijn werkwijze werd gestructureerder naarmate de projecten serieuzer werden. In plaats van alleen op prompts te vertrouwen, begon ik specificaties op te stellen voordat ik iets genereerde. Ik documenteerde de bedrijfsvereisten, de tech‑stack en integraties. Daarna kwamen unit‑tests en Playwright‑tests voor de belangrijkste gebruikersreizen.

Beveiligingscontroles werden op vergelijkbare wijze toegevoegd. Ik bekeek de bibliotheken die de AI selecteerde en introduceerde malware‑scanning voor geüploade bestanden. Elke controle kwam voort uit de vraag wat er vervolgens mis kon gaan, in plaats van een vooraf opgestelde controellijst te volgen.

Die gewoonte ving een probleem op één project. De AI introduceerde een bibliotheek die niet compatibel was met de versie van het framework die ik gebruikte. De applicatie was niet direct gecrasht, dus de incompatibiliteit had gemakkelijk onopgemerkt kunnen blijven. Het later ontdekken zou de oorzaak veel moeilijker identificeerbaar hebben gemaakt.

In vergelijking met de Tea‑ en Lovable‑gevallen was dit een alledaags probleem. Ik vond het vroeg, repareerde het en ging verder. Dat is hoe review er in de praktijk meestal uitziet. Meestal voorkomt het dat kleine problemen uitgroeien tot grotere.

Ik wantrouw code niet alleen omdat AI het heeft geproduceerd. Ik vertrouw het ook niet alleen omdat de applicatie draait. Tests en review zijn hoe ik bepaal of het zich gedraagt zoals bedoeld.

Van Vibe Coding naar Agentic Engineering

Karpathy’s eigen verschuiving van “vibe coding” naar “agentic engineering” is niet alleen een verandering in woordenschat. “Agentic engineering” geeft ons een bruikbaarder naam voor de richting die professionele ontwikkeling opgaat. Ontwikkelaars schrijven misschien minder regels zelf, maar dat vermindert hun verantwoordelijkheid niet. Het verlegt hun werk naar het specificeren van wat het systeem moet doen, het aansturen van agents, het testen van hun output en het bepalen wat veilig kan worden uitgebracht.

Het gevaar is niet dat AI code snel genereert. Het is dat de generatie sneller kan gaan dan het begrip. Wanneer dat gebeurt, verbergt schijnbare productiviteit risico’s die niemand goed heeft onderzocht.

Een regel die het waard is om te behouden

Stop met het label “vibe coding” te gebruiken voor elke vorm van AI‑ondersteunde ontwikkeling – het verwatert de term en wist een onderscheid in controle dat van belang is. Stel een eenvoudige regel: lever niets op wat je niet kunt uitleggen. En bouw controle in het project terwijl het groeit, laag voor laag, en voeg controles toe in stap met de risico’s die zich voordoen.

AI kan het grootste deel van de code schrijven. Het kan echter geen verantwoordelijkheid nemen voor het uitbrengen ervan. Dat blijft onze taak.