Wat is vibe coding? Van prompt naar werkende app

Vibe coding is software maken door in gewone taal te beschrijven wat je wilt en AI de code te laten schrijven. Je probeert het resultaat uit en vraagt om aanpassingen, vaak zonder iedere wijziging in de code te begrijpen. Binnen onze gids voor AI-automatisering gaat dit over de manier van bouwen; voor de keuze tussen bestaande bouwblokken en eigen ontwikkeling is er de uitleg over no-code versus maatwerk.

Wat is vibe coding precies?

Het woord wordt voor verschillende werkwijzen gebruikt. In de strikte betekenis volg je vooral of de software doet wat je verwacht, terwijl de code grotendeels buiten beeld blijft. Bij beoordeelde AI-ondersteunde ontwikkeling leest en test iemand de wijzigingen en begrijpt diegene wat er wordt opgeleverd. Google Cloud maakt dit onderscheid ook in zijn uitleg.

Daarom zegt “gebouwd met AI” weinig over de kwaliteit. Een ontwikkelaar kan AI gebruiken en iedere wijziging zorgvuldig beoordelen. Iemand anders kan in dezelfde tool alles accepteren zodra de knop op het scherm werkt. De verantwoordelijkheid verschilt, ook als de software waarmee ze bouwen dezelfde naam heeft.

Je hoeft het woord niet te verbieden om er verstandig mee om te gaan. Spreek af wat je maakt: een demonstratie om een idee te bespreken, een afgebakende proef of software waarop collega’s dagelijks moeten kunnen rekenen.

Hoe maak je van een beschrijving een prototype?

Neem een denkbeeldige uitleenapp voor gereedschap. Je wilt zien welk materiaal beschikbaar is en wie iets gereserveerd heeft. Begin met nepgegevens en een beperkte opdracht, bijvoorbeeld:

Maak een prototype waarin een medewerker gereedschap kan bekijken en een reserveringsverzoek kan indienen. Een beheerder accepteert of weigert dat verzoek. Gebruik alleen verzonnen gegevens en verstuur geen echte berichten.

Dat is een beter vertrekpunt dan “maak een compleet bedrijfsplatform”. Je kunt nu beoordelen of de schermen begrijpelijk zijn en of de volgorde past bij het werk. Misschien blijkt een reservering pas bruikbaar als iemand de afhaallocatie ziet. Dat ontdek je door een collega de taak te laten uitvoeren, zonder zelf naast ieder veld uitleg te geven.

Verander vervolgens gericht iets en probeer dezelfde taak opnieuw. Een nieuwe knop kan een oude route beïnvloeden. Bewaar daarom een bruikbare versie voordat je grotere wijzigingen laat doen en noteer welke afspraken moeten blijven gelden.

Het prototype mag onvolledig zijn. Zolang je duidelijk houdt wat het wel en niet aantoont, hoeft dat geen verspilde bouwtijd te zijn. De schermen en gesprekken kunnen later helpen om een kleinere, beter omschreven eerste versie te kiezen. Onze uitleg over een MVP laten bouwen gaat over die afbakening.

Welke rol hebben Lovable, Bolt en Cursor?

De namen komen vaak samen terug bij vibe coding tools, maar de werkomgeving verschilt. Lovable en Bolt kunnen vanuit een beschrijving een applicatie opbouwen. Cursor is een omgeving waarin je met code werkt en een AI-assistent wijzigingen laat uitvoeren. Geen van die beschrijvingen is een kwaliteitskeurmerk voor de uiteindelijke app.

Tool	Gedocumenteerd vertrekpunt	Vraag bij je keuze
Lovable	Webapp bouwen met natuurlijke taal, met bewerkbare code en Git-synchronisatie	Hoe controleer je code, gegevens en gekoppelde diensten buiten de bouwomgeving?
Bolt	Apps genereren vanuit prompts, met ondersteuning voor JavaScript-webtechnologie	Past de gebruikte techniek bij wie de app straks beheert?
Cursor	Een AI-assistent die code doorzoekt, bestanden wijzigt en opdrachten uitvoert	Wie beoordeelt de wijzigingen en kan een fout onderzoeken?

Bronnen: Lovable-documentatie, Bolt-documentatie en Cursor Agent. Functies gecontroleerd in september 2026; controleer de actuele documentatie voordat je kiest.

Voor een ondernemer kan een directe app-preview prettig zijn. Een technisch team wil misschien vooral de bestaande code gericht aanpassen. Kies daarom niet op de mooiste eerste demo. Probeer ook een wijziging, een mislukte stap en de overdracht aan iemand die niet bij het eerste gesprek met de AI was.

Waarom is een geslaagde demo nog geen productietest?

Onze gereedschapsapp lijkt klaar als je een reservering kunt indienen en goedkeuren. Maar wat gebeurt er als twee collega’s vrijwel tegelijk hetzelfde materiaal aanvragen? Of als iemand de reservering van een ander probeert te veranderen?

Die vragen horen bij het gedrag van jouw applicatie. Een test moet vastleggen wat er in zo’n situatie hoort te gebeuren. “De AI zegt dat het is opgelost” is geen testresultaat. Laat de handeling uitvoeren en controleer het gevolg in de opgeslagen gegevens, ook na opnieuw inloggen.

Wat moet je controleren voordat er echte gegevens in gaan?

Begin met toegangsrechten. Inloggen bewijst wie iemand is; het bepaalt niet automatisch welke reserveringen die persoon mag bekijken of wijzigen. OWASP adviseert om rechten bij ieder verzoek te controleren en niet alleen op beperkingen in het scherm te vertrouwen. Een verborgen knop is geen toegangsregel.

Voor de uitleenapp betekent dit bijvoorbeeld dat een medewerker niet via een andere route alsnog de beheerfunctie kan uitvoeren. Laat die scheiding controleren in de techniek die gegevens leest en schrijft. Test daarbij met verschillende rollen, niet alleen met het account waarmee de app is gebouwd.

Bouwplatforms kunnen helpen. Lovable beschrijft beveiligingscontroles op onder meer databasebeleid en applicatiecode, met een verschillend bereik voor zijn scans. Zie de uitkomst als informatie voor je beoordeling. Een lege lijst met waarschuwingen toont niet aan dat jouw eigen reserveringsregels correct zijn.

Leg verder vast welke gegevens werkelijk nodig zijn, wie ze kan verwijderen en waar fouten terechtkomen. Gebruik voor de proef geen kopie van een klantenbestand als verzonnen records dezelfde vraag kunnen beantwoorden. En bepaal wie stopt met de proef als gegevens onbedoeld zichtbaar worden of een bewerking verkeerd uitpakt.

Heb je met geëxporteerde code ook de hele applicatie?

Nee. Code, opgeslagen gegevens en externe diensten zijn verschillende onderdelen. Lovable vermeldt bij Git-synchronisatie expliciet dat een kopie van de code niet de gebruikte diensten meeneemt. De database-inhoud zit niet in die codekopie, en lokaal draaien kan nog steeds dezelfde backend aanspreken als de gepubliceerde app.

Dat heeft een praktische consequentie: een testversie met een andere URL is niet automatisch een aparte testomgeving. Laat vaststellen naar welke database en diensten ze verbinding maakt voordat iemand proefrecords wijzigt of verwijdert.

Vraag bij een overdracht daarom om meer dan een download. Je wilt weten hoe de app wordt gestart, welke instellingen nodig zijn, waar gegevens staan en welke abonnementen blijven lopen. Een ander moet de afgesproken werkwijze kunnen uitvoeren zonder de oorspronkelijke promptgeschiedenis te raden.

Ook codebezit en technische onafhankelijkheid zijn verschillende vragen. In onze uitleg over code-eigendom en afhankelijkheid van leveranciers lees je waarom toegang tot de broncode niet alle andere afhankelijkheden oplost.

Kun je het prototype doorontwikkelen of moet het opnieuw?

Dat volgt uit een beoordeling van wat er ligt. De gebruikte tool is op zichzelf geen reden om alles weg te gooien. Een duidelijke codeopbouw en aantoonbaar werkende functies kunnen een bruikbare basis zijn. Omgekeerd kan veel herstelwerk nodig zijn als veranderingen op elkaar zijn gestapeld zonder dat iemand de samenhang begrijpt.

Laat de beoordelaar uitleggen welke delen behouden kunnen blijven en waarom. Vraag ook wat nog onbekend is. Een aanbod om “het even productiegeschikt te maken” zegt weinig zolang niemand de gegevensstructuur, rollen en belangrijkste routes heeft bekeken.

Een bruikbare overdracht beschrijft bijvoorbeeld:

• Welke taak gebruikers ermee kunnen uitvoeren en welke gevallen bewust buiten scope vallen.
• Welke onderdelen zijn getest, inclusief de gevonden problemen en wat ermee is gedaan.
• Wie wijzigingen beoordeelt en wie bereikbaar is als de app niet werkt.
• Hoe je een versie terugzet en gegevens herstelt, met onderscheid tussen die twee.

Als wij zo’n prototype verder ontwikkelen, begint dat bij die beoordeling. Voor maatwerk software laten maken moet de opdracht beschrijven wat er opgeleverd en beheerd wordt. De code is en blijft van jou. Bestaande licenties en diensten nemen we mee in de afweging, zodat een overdracht meer inhoudt dan bestanden verplaatsen.

Wat kost werken met vibe coding tools echt?

De kosten beginnen bij het gebruik van de bouwtool, maar eindigen daar niet. Ook hosting, opslag, externe API’s en onderhoud horen bij een draaiende applicatie. Een gratis instap of proefaccount kan geschikt zijn om een idee te verkennen; controleer de limieten voordat je een team afhankelijk maakt van dat aanbod.

Het aantal prompts is geen goede maat voor de kosten van een eindproduct. Soms is een extra aanpassing eenvoudig. Soms verandert ze de gegevensstructuur en moeten bestaande records mee veranderen. Laat daarom naast het abonnement ook het resterende werk beoordelen: wat is nog nodig voor het gebruik dat jij voor ogen hebt?

Tel leren en opleveren apart. Een prototype dat duidelijk maakt dat een idee niet helpt, heeft een ander doel dan een applicatie die elke werkdag beschikbaar moet zijn. Als je die twee budgetten door elkaar haalt, lijkt iedere snelle demo goedkoop en iedere noodzakelijke controle achteraf duur.

Hoe begin je concreet?

Kies een vraag die je met een prototype wilt beantwoorden, bijvoorbeeld of medewerkers zonder uitleg een reservering kunnen aanvragen. Beschrijf het gewenste gedrag, gebruik verzonnen gegevens en laat iemand de taak uitvoeren. Verzamel wat er onduidelijk blijft, niet alleen wat er mooi uitziet.

Beslis daarna of je verder wilt. Vóór dagelijks gebruik laat je vaststellen wie de code begrijpt, hoe rechten en gegevens zijn geregeld en wie onderhoud uitvoert. Daarmee krijgt het experiment een duidelijke volgende stap.

Wil je weten wat er nodig is om jouw prototype verder te brengen? Plan een gesprek en laat zien welke taak het al aankan.