Wat is vibe coding?
Vibe coding is software bouwen door een AI-tool te vertellen wat je wilt en de code te accepteren die de tool schrijft, meestal zonder die te lezen of te controleren. Je klikt door de app om te zien of hij lijkt te werken. Gaat er iets mis, dan beschrijf je het probleem en laat je de AI het opnieuw proberen.
De term verspreidde zich begin 2025. Tools voor vibe coding, zoals chatassistenten, AI-code-editors en app-builders in de browser, konden toen met een paar prompts een werkende app maken.
Dit artikel is voor oprichters, productleads en operationeel managers die een app uit vibe coding hebben zien werken, of er zelf een bouwden. Ze vragen zich af of zo'n app een deel van het bedrijf kan dragen, of dat de belofte van een leverancier over software die met AI is gebouwd veilig is. We gebruiken zelf elke dag coding agents (AI-codeerassistenten). De vraag hier is dus wat er rond de AI gebeurt: wie de code leest, wat de code controleert en wie er eigenaar van is.
Waar vibe coding een verstandige keuze is
Vibe coding is verstandig als de software klein is, er weinig op het spel staat en alleen de maker zelf ervan afhankelijk is. Gaat het stuk, dan ben je een middag kwijt, en er zijn geen klantgegevens of geld bij betrokken. Daar valt best veel nuttig werk onder:
- Persoonlijke tools, zoals een tracker voor je eigen taken of een rekenhulp voor een offerte die je elke week maakt.
- Interne experimenten die een paar collega's een week uitproberen, met verzonnen of openbare data.
- Een idee dat je wilt uitproberen voordat je erin investeert. Een eerste werkende versie voor jezelf laat zien wat het idee nodig heeft, en dan kun je het later makkelijker uitleggen aan een ontwikkelaar of leverancier.
- Wegwerpscripts: een eenmalige opschoning van data, een omzetting tussen twee bestandsformaten, een controle die je één keer draait en weggooit.
- Leren hoe software in elkaar zit, door de AI te vragen uit te leggen wat hij schreef.
Dat verandert zodra andere mensen van de tool afhankelijk zijn: collega's die hem elke dag gebruiken, klanten die inloggen, of persoonsgegevens van iemand anders dan jijzelf. Tools komen vaak geleidelijk op dat punt, zonder dat iemand dat heeft besloten.
Risico's van vibe coding bij echte gebruikers en data
Apps uit vibe coding gaan meestal mis in de delen die je niet ziet als je erdoorheen klikt: ontbrekende tests, beveiligingslekken, slordige omgang met persoonsgegevens en code die niemand begrijpt als er iets misgaat. Een app kan er af uitzien en toch al deze problemen hebben, want geen ervan is op het scherm te zien.
Geen tests
Niemand heeft opgeschreven wat de app moet doen, dus niets controleert of hij dat nog steeds doet. Elke wijziging test iemand door rond te klikken. De paden waar niemand op klikt, zoals een geannuleerde order, een datum aan het eind van de maand of een formulier dat twee keer wordt verstuurd, blijven ongecontroleerd tot een gebruiker erop stuit.
Beveiligingslekken
Drie problemen komen vaak voor in code die niemand heeft gecontroleerd, en je kunt ze alle drie nakijken:
- Blootgestelde sleutels: API-sleutels of databasewachtwoorden in code die in de browser draait, waar iedereen ze kan lezen, of vastgelegd in een coderepository.
- Ontbrekende toegangscontroles: het scherm verbergt de records van een andere klant, maar de server geeft ze terug aan iedereen die een id in het verzoek aanpast. Een gehoste database waarvan de toegangsregels nooit zijn aangezet, heeft hetzelfde probleem.
- Injectie: tekst die een gebruiker typt, gaat rechtstreeks een databasequery of een prompt in. Met slim opgestelde input kan iemand dan data lezen of wijzigen waar die input nooit bij had mogen komen.
Persoonsgegevens en de AVG
Slaat de app namen, e-mailadressen of klantrecords op, dan geldt de AVG (GDPR). Je moet weten welke persoonsgegevens de app bevat, waar die gegevens worden verwerkt, welke leveranciers ermee werken en onder welke overeenkomst, en hoe je iemands gegevens verwijdert als die persoon daarom vraagt. In een app uit vibe coding kunnen persoonsgegevens terechtkomen in logs, in prompts naar een AI-aanbieder of in een hostingregio die niemand heeft gekozen. Dit is algemene informatie en geen juridisch advies. Leg je situatie dus voor aan je privacyfunctionaris of juridisch adviseur.
Code die niemand begrijpt
Gaat er op maandagochtend iets stuk, dan moet iemand de oorzaak vinden. Heeft niemand de code gelezen, dan kun je alleen de AI opnieuw vragen, en die lost misschien het symptoom op terwijl hij iets anders verandert. Wie de app bouwde, is misschien vertrokken of wist nooit hoe hij vanbinnen werkt.
Afhankelijkheden die niemand bijhoudt
AI-tools voegen zonder aarzelen packages toe. Elk package is code van iemand anders die een update nodig heeft als er een beveiligingsprobleem in wordt gevonden, en sommige worden niet meer onderhouden. AI-tools kunnen ook namen van packages voorstellen die niet bestaan. Een aanvaller kan zo'n naam registreren en er kwaadaardige code in zetten. Zonder lijst van afhankelijkheden weet niemand wanneer een update ertoe doet.
Lopende kosten
Code die werkt met honderd records, kan traag en duur zijn met honderdduizend. Typische oorzaken zijn een query die een hele tabel laadt om één rij te tonen, een databaseaanroep voor elk item in een lijst en een modelaanroep bij elke paginaweergave waar één per dag volstaat. De rekeningen groeien mee met het gebruik, vaak zonder ingestelde bestedingslimiet.
Wijzigingen die andere functies breken
Vraag de AI de opmaak van de factuur te veranderen, en misschien herschrijft hij ook de datumverwerking waar het maandrapport op leunt. Zonder tests meldt een gebruiker de fout pas dagen later. Elke fix brengt hetzelfde risico mee, dus hoe langer de app draait, hoe moeilijker hij aan te passen is.
Hoe agentic engineering verschilt
Bij agentic engineering bouwen ervaren ontwikkelaars software met coding agents. De ontwikkelaar deelt het werk op in afgebakende taken, schrijft een specificatie en tests, laat de agent de code schrijven en controleert elke wijziging voordat die wordt gemerged. De ontwikkelaar is eigenaar van de architectuur en staat in voor wat er live gaat.
Bij beide aanpakken schrijft AI de code, en allebei kunnen ze op de eerste dag snel zijn. We werken zo aan onze eigen projecten en aan klantprojecten. Ons artikel over hoe we SaaS bouwen met coding agents gaat dieper in op de scope bepalen, eerst tests schrijven en review.
Zegt een leverancier dat zijn software met AI is gebouwd, dan zegt dat weinig over de kwaliteit, in welke richting ook. Vraag wie elke wijziging controleert voordat die wordt gemerged, welke tests automatisch draaien en of de coderepository en de hostingaccounts op jouw naam staan.
Vibe coding of agentic engineering: de verschillen
Het grootste verschil is wie de verantwoordelijkheid voor de code neemt. Bij vibe coding accepteer je wat de AI maakt zodra de app lijkt te werken. Bij agentic engineering controleert een ontwikkelaar de code, controleren tests die en houdt het team een ontwerp aan dat het begrijpt. Dat kost aan het begin wat snelheid, en later kun je de software veilig blijven aanpassen.
| Aspect | Vibe coding | Agentic engineering |
|---|---|---|
| Wie de code controleert | Meestal niemand; wie de app beoordeelt, klikt erdoorheen | Een ervaren ontwikkelaar controleert elke wijziging voordat die wordt gemerged |
| Tests | Zelden geschreven, dus problemen komen pas boven als gebruikers erop stuiten | Geschreven voor de belangrijke processen, vaak vóór de code, en gedraaid bij elke wijziging |
| Beveiliging | Hangt af van wat de AI toevallig schreef | Toegangscontroles, secrets en afhankelijkheden gecontroleerd in de review en met automatische scans |
| Wie het systeem begrijpt | Vaak niemand, ook niet wie de prompts schreef | De ontwikkelaars die de architectuur ontwierpen, met notities en documentatie in de repository |
| Snelheid op dag één | Heel snel tot een eerste werkende versie | Snel, met tijd vooraf voor scope, specificaties en tests |
| Snelheid na zes maanden | Neemt af, omdat elke wijziging iets anders kan breken | Blijft op peil, omdat tests fouten vangen en de code leesbaar blijft |
| Past bij | Persoonlijke tools, snelle experimenten, wegwerpscripts en leren | Software waar klanten, collega's of auditors jarenlang op vertrouwen |
De twee kunnen elkaar opvolgen. Een oprichter kan een idee met vibe coding bouwen om te zien of het standhoudt, en het daarna met review en tests opnieuw laten bouwen zodra mensen ervan afhankelijk zijn. De eerste versie laat dan nog steeds zien welke schermen, data en regels het echte systeem nodig heeft.
Wat te doen als je bedrijf draait op een app uit vibe coding
Draait je bedrijf al op een app uit vibe coding, dan hoef je die zelden weg te gooien. Zoek uit wat de app doet en waar hij bij kan, beveilig de data en sleutels, zet tests rond de belangrijke processen en beslis daarna per onderdeel wat je houdt, herstructureert of opnieuw bouwt. Doorloop de stappen in deze volgorde:
- 01Schrijf op wat de app doet en wie hem gebruikt. Noteer elke functie, wie ervan afhankelijk is en wat er gebeurt als die functie een dag uitvalt. Dan zie je waar je begint.
- 02Controleer waar data en sleutels staan. Zoek elke API-sleutel, elk wachtwoord en elke databaseverbinding op, haal ze uit de code naar een secrets store en vervang elke sleutel die is uitgelekt. Noteer welke persoonsgegevens de app bevat, waar hij wordt gehost en welke aanbieders gegevens ontvangen.
- 03Zet tests rond de belangrijke processen. Begin bij de paden voor geld, orders of klantgegevens. Met tests die vastleggen hoe de app zich nu gedraagt, kun je hem aanpassen zonder die processen ongemerkt te breken.
- 04Voer een beveiligingsreview uit. Controleer of de server op elk scherm en elke API-route toegangsregels afdwingt, zoek naar injectie in formulieren en prompts, werk kwetsbare packages bij of verwijder ze, en controleer of de logs geen persoonsgegevens bevatten die er niet in horen.
- 05Beslis per onderdeel: houden, herstructureren of opnieuw bouwen. Onderdelen die hun tests en de review doorstaan, kunnen blijven. Onderdelen die werken en die niemand kan volgen, herstructureer je. Onderdelen met een kapot datamodel of zonder toegangscontrole zijn vaak sneller opnieuw te bouwen dan veilig te repareren. Sommige kun je beter vervangen door standaardsoftware, en onze gids over zelf bouwen of kopen helpt bij die keuze.
- 06Zet de code in een repository die van jou is, met deployment en monitoring. Verhuis de code naar een repository onder het account van je organisatie, met automatische deployment, back-ups, foutmeldingen en meer dan één persoon met toegang. Dan hangt de app niet meer af van één laptop of van het AI-account van één persoon.
Is de app een tool die alleen jij gebruikt, dan kost het meeste hiervan meer moeite dan het oplevert. Vertrouwen klanten of collega's erop, dan kan een eigen ontwikkelaar deze stappen doorlopen, of geef je ze aan een bureau voor maatwerksoftware. Voor een product dat je verkoopt, beschrijft onze pagina over SaaS-ontwikkeling welke basis je eerst controleert: de scheiding tussen klanten (tenant isolation), rollen en rechten, en facturatie.
Vragen over code die AI schrijft
Is vibe coding veilig?
Vibe coding is veilig genoeg voor tools die alleen jij gebruikt, zonder persoonsgegevens, geld of toegang voor klanten. Zijn andere mensen of hun gegevens van de app afhankelijk, behandel hem dan als software die niemand heeft gecontroleerd. Laat iemand de code lezen, voeg tests toe en controleer op blootgestelde sleutels, ontbrekende toegangscontroles en injectie voordat je erop vertrouwt.
Kan een app uit vibe coding live gaan?
Soms, na review, tests en een beveiligingscontrole. Sommige apps uit vibe coding doen de juiste dingen en hebben alleen werk nodig aan wat het scherm niet laat zien: secrets, toegangsregels, omgang met data, afhankelijkheden en monitoring. Andere hebben een datamodel of structuur waardoor opnieuw bouwen sneller is.
Live gaan betekent ook dat iemand daarna verantwoordelijk is voor updates, back-ups en fixes. Spreek af wie dat is voordat klanten de app gaan gebruiken.
Gebruiken professionele ontwikkelaars AI om code te schrijven?
Ja. Veel professionele ontwikkelaars gebruiken elke dag AI-tools, van suggesties in de code-editor tot coding agents die een hele taak oppakken en een wijziging ter controle teruggeven. Het verschil met vibe coding is dat de ontwikkelaar leest en test wat de AI maakt, en er verantwoordelijk voor blijft.
Is agentic engineering gewoon vibe coding met extra stappen?
Het AI-deel lijkt op elkaar: iemand beschrijft een taak en een agent schrijft de code. De extra stappen zijn een specificatie, tests, review van elke wijziging en eigenaarschap van de architectuur. Die stappen bepalen of je de software over een jaar nog veilig kunt aanpassen.