Wat is vibe coding? De uitleg, in gewone taal

Vibe coding is software bouwen door in gewone taal te omschrijven wat je wilt, waarna een AI-tool de code voor je schrijft. Jij typt geen regel code: je beschrijft het resultaat, zoals een aanvraagformulier of een planningsapp, en tools als Lovable, bolt.new, Replit of Cursor bouwen het voor je. De term komt van Andrej Karpathy, die hem begin 2025 introduceerde, en werd nog datzelfde jaar door Collins Dictionary uitgeroepen tot woord van het jaar. Inmiddels draaien er bij Nederlandse bedrijven van elke omvang apps op vibe coding, vaak gebouwd door iemand zonder ontwikkelachtergrond.

Hoe werkt vibe coding in de praktijk?

Het proces is steeds hetzelfde. Je beschrijft in een paar zinnen wat de app moet doen, de AI genereert werkende code, en jij test het resultaat. Werkt iets niet zoals bedoeld, dan stuur je bij met een nieuwe prompt, net zolang tot het klopt. Voor een simpel dashboard of formulier gaat dat razendsnel: waar een developer er vroeger dagen mee bezig was, staat er nu binnen een middag een werkende versie.

Dat tempo is precies waarom vibe coding zo aantrekkelijk is voor mensen zonder programmeerachtergrond. Een projectleider die een verlofrooster wil, een marketeer die een leadformulier nodig heeft: die hoeven niet meer te wachten op IT-capaciteit. Ze bouwen het zelf, dezelfde middag nog.

Wat kun je er wel en niet mee bouwen?

Voor prototypes, interne tools en eenvoudige apps is vibe coding sterk. Een idee testen, een omslachtig Excel-proces vervangen door een simpel formulier, een proof-of-concept voor een klant: dat soort dingen bouw je in uren in plaats van weken.

Lastiger wordt het bij alles wat op schaal moet draaien of gevoelige gegevens verwerkt. De AI optimaliseert voor "het werkt", niet voor "het blijft werken bij honderd gebruikers tegelijk" of "het voldoet aan de AVG". Dat verschil merk je meestal pas als het al te laat is.

Wat zijn de risico's van vibe coding?

De code die een AI-tool genereert, is zelden kwaadaardig bedoeld maar vaak wel onvolledig. Denk aan een wachtwoord dat in platte tekst wordt opgeslagen, een API-sleutel die per ongeluk zichtbaar in de broncode staat, of een formulier zonder enige validatie. Iemand zonder ontwikkelachtergrond ziet dat niet, want de app werkt gewoon.

Daar komt bij dat er vaak geen versiebeheer, geen back-up en geen deployproces is. Alles staat op één laptop, aangepast met de volgende prompt, zonder dat iemand kan teruggaan naar een werkende versie als het misgaat. Voor een tool die drie collega's gebruiken is dat vervelend. Voor een app waar het halve bedrijf op draait, is het een risico dat op een gegeven moment toeslaat.

Wat gebeurt er als je vibe-coded app al bedrijfskritisch is?

Dit is het stuk dat de meeste uitleg over vibe coding overslaat: wat als de app er al is, en gewoon in gebruik? Dat gebeurt vaker dan je denkt. Een app die begon als weekendproject van een enthousiaste collega draait binnen een jaar het orderproces, de planning of de klantcommunicatie.

De signalen zijn steeds hetzelfde. De bouwer is vertrokken en niemand anders snapt de code. Niemand durft nog te deployen, want een verkeerde wijziging is niet terug te draaien. Elke update is spannend omdat de app op onverwachte momenten omvalt. Of er is simpelweg geen back-up: alles staat op één laptop of één server, en één keer pech is het weg.

Herken je een van die situaties, dan is het probleem niet "moet ik stoppen met vibe coding". Het probleem is dat een app die met losse prompts is gebouwd, nooit de basis kreeg die een bedrijfskritische applicatie nodig heeft: fatsoenlijk versiebeheer, back-ups, monitoring en iemand die weet hoe de boel in elkaar zit.

Wanneer schakel je een professional in?

Niet elke vibe-coded app heeft hulp nodig. Een intern testtool die drie mensen gebruiken, kan prima blijven draaien zoals-ie is. Zodra een app bedrijfskritisch wordt, gevoelige gegevens verwerkt, of de oorspronkelijke bouwer weg is, is het tijd om iemand te laten meekijken die de code kan lezen en de risico's in kaart brengt.

Dat hoeft geen herbouw te zijn. Bij Vibekite beginnen we met een scan: een developer leest de code, brengt risico's in kaart, en je krijgt binnen een week een concreet plan van aanpak, in gewone taal. Vaak is de uitkomst dat de app blijft zoals hij is, maar met versiebeheer, back-ups en monitoring erbij: precies de basis die er nooit kwam.