Wat is vibe coding? Definitie, hoe het werkt – en het hoofdstuk dat de gidsen overslaan

Elk vibe coding-tool, wat de marketing ook zegt, draait een versie van dezelfde loop: beschrijven → genereren → uitvoeren → reageren. Je typt "een takenlijst gesorteerd op deadline"; de agent plant de wijziging, schrijft de code in alle bestanden die nodig zijn, bouwt het project, ziet dezelfde fouten die een programmeur zou zien, lost ze op en laat je een werkend resultaat zien. De volgende zin – "verlopen taken moeten rood zijn" – draait de loop opnieuw, bovenop alles wat er al staat.

Drie dingen aan de binnenkant bepalen of die loop iets goeds oplevert, en ze zijn de moeite waard om te kennen omdat ze elk kwaliteitsverschil tussen tools verklaren:

Context. De agent kan alleen rekening houden met wat hij ziet – je eerdere beslissingen, de bestaande code, het designsysteem. Tools verschillen enorm in hoeveel ze onthouden en hoe ze kiezen waar ze naar kijken.

Structuur. Vraag functies één voor één zonder plan, en de agent improviseert per prompt een architectuur – prima voor een demo, slecht op een manier die zich opstapelt tot functie twintig. Tools die de structuur vooraf bepalen (of jou laten bepalen) leveren code die bruikbaar blijft.

Verificatie. De beste tools leveren geen code die zou moeten werken: ze bouwen hem, voeren hem uit, testen hem en corrigeren hun eigen fouten voordat jij iets ziet. Het verschil tussen "genereert code" en "levert software" zit bijna helemaal hier. Zelfs Apple heeft agents in Xcode ingebouwd die tussen bouwen en corrigeren itereren.

Let op wat er in die lijst ontbreekt: jouw vermogen om te programmeren. Wat de loop echt verbruikt is je vermogen om precies te beschrijven en eerlijk te reageren – en daarom pakten productmensen het sneller op dan wie ook. Opschrijven wat er moet bestaan, scenario voor scenario, was al hun werk.

Goed in, vandaag: van idee naar werkende software in één sessie; goedkoop itereren (het "probeer nog eens" dat een middag van een developer kostte, kost nu één zin); de standaardonderdelen van een product – schermen, formulieren, lijsten, accounts, betalingen op beheerde backends; en de persoon met productinzicht direct laten bouwen in plaats van de boodschap door lagen te sturen.

Schiet nog tekort, eerlijk: werk zonder beschrijfbare specificatie (als jij niet kunt zeggen hoe "goed" eruitziet, kan de agent dat ook niet weten); echt nieuwe algoritmes en zeldzame systeemprogrammering; een grote, oude codebase redden die hij niet zelf bouwde; en het ontbreken van productdenken compenseren – een agent versterkt de kwaliteit van beslissingen in beide richtingen.

En één manier om te falen ligt bij de gebruiker, niet bij de tools: een demo verwarren met een product. Elk tool op deze pagina geeft je in een middag een indrukwekkende demo. Een product heeft daarnaast een structuur nodig die functie twintig overleeft, accounts die werken, data die blijft, updates die uitgaan en code die van jou is. Tools verschillen veel meer in die tweede helft dan in demosnelheid – en dat brengt ons bij de kaart.

De meeste lijstjes sorteren op snelheid en afwerking. Sorteer in plaats daarvan op resultaat – wat datgene wat je beschrijft daadwerkelijk wordt – en de hele markt valt uiteen in vijf groepen. (Geen prijzen hier: die veranderen, en elk tool publiceert zijn eigen. De vraag die je stelt is altijd dezelfde: in welk abonnement kan ik publiceren en de code meenemen?)

Webbouwers – resultaat: webapp. Lovable is de referentie: apps in React, GitHub-synchronisatie, backend op Supabase; de eigen documentatie zegt "Lovable does not generate React Native projects". v0 van Vercel en Bolt spelen dezelfde wedstrijd. Voor webproducten publiceren ze echt; voor het prototypen van wat dan ook zijn ze uitstekend.

Prototypetools – resultaat: klikbare wegwerpdemo's. Figma Make leeft in het designecosysteem en is eerlijk over wat het is: gemaakt om te verkennen, niet om te publiceren.

Code-agents met je eigen AI – resultaat: wat je weet aan te sturen. Claude Code, Cline, Aider: agents die in een echte codebase werken met jouw abonnement of jouw API-sleutel. Maximale vrijheid, geen vangrails – uitstekend voor developers, en de route waar productmensen de structuur van de volgende groep het hardst nodig hebben.

Mobiele bouwers – resultaat: mobiele app, met een splitsing binnen de groep die bijna geen lijst noemt. Vibecode, Newly en Bolt met Expo genereren React Native/Expo – cross-platform JavaScript dat via een brug op de telefoon draait, met dezelfde schermen op beide systemen. FlutterFlow zet Flutter-apps visueel in elkaar. Rork is in 2026 overgestapt op native code – Swift voor iPhone, Kotlin voor Android – als twee aparte apps in één project: volgens de eigen docs "each app has its own code". En Modaal (het onze) genereert echte native code per platform – Swift/SwiftUI voor iPhone, Kotlin/Jetpack Compose voor Android – uit één project, met de logica van elke functie één keer geschreven en één native scherm per platform, met een plan dat je goedkeurt vóór elke functie, de code op je Mac en onbeperkt prompts in het gratis abonnement. Waarom die splitsing ertoe doet is het volgende hoofdstuk – want het is het deel van vibe coding dat de gidsen blijven overslaan. (De tien bouwers, gesorteerd op wat ze opleveren, staan in onze vergelijking in het Engels.)

Dit is het vreemde gat in alle vibe coding-gidsen tot nu toe, in het Nederlands net als in het Engels: ze leggen de loop uit, sommen de tools op, laten een webdemo zien – en stoppen bij de telefoon. "Voor mobiel" verschijnt, als het al verschijnt, als "je webapp werkt ook in de browser van je telefoon". Voor wie een product heeft dat op het beginscherm van een telefoon thuishoort, verbergt die zin de drie feiten die het meest tellen:

1. Een website op de telefoon is geen app. Pushmeldingen, offline gebruik, camera en sensoren, widgets, horloge en aankopen in de winkels horen bij echte apps. De snelle test: komen je gebruikers binnen door op een link te tikken of door een icoon te openen? De volledige vergelijking staat in onze gids in het Engels.

2. Je ge-vibe-code webapp inpakken overbrugt de kloof niet. De voor de hand liggende sluiproute – de webapp in een schil stoppen die op een app lijkt – botst met de beoordeling van Apple, die dunne schillen rond een website regelmatig afwijst, en met alle beperkingen hierboven, omdat de app nog steeds een vermomde website is.

3. De kloof wordt nu met dezelfde vaardigheid overbrugd. Dit is wat er veranderd is en wat de gidsen nog niet hebben opgepikt: de loop beschrijven-en-itereren levert nu echte native code op. In de versie van Modaal is de loop bewust gestructureerder dan web-vibe coding – een productdocument bij de start van het project en, voor elke functie, schrijft de agent eerst een plan dat je kunt lezen (scenario's, aanpak, risico's, tests) en bouwt hij pas nadat je het hebt goedgekeurd; het resultaat is Swift en Kotlin die een platformdeveloper herkent, gebouwd en getest, op je Mac. Vibe coding met de improvisatie vervangen door specificaties – precies de correctie die een productieresultaat mogelijk maakt.

Het praktische gevolg: de webroute en de mobiele route beginnen nu hetzelfde – met een beschrijving – en hoeven niet meer te eindigen met een herschrijving. Heb je iets in Lovable gevalideerd dat een app bleek te zijn? De backend overleeft meestal de verhuizing; de voorkant wordt een echte native app, beschreven in dezelfde taal als het prototype. En als het product naar beide winkels moet, wordt de logica één keer geschreven en krijgt elk platform zijn eigen native scherm – zonder iets opnieuw te bouwen voor Android. Wil je liever laten bouwen? Een app laten maken zet de routes en de kosten naast elkaar.

De oprit van één sessie, in de volgorde die de klassieke fouten vermijdt:

1. Kies iets echts maar kleins. Niet het paradepaardje van je bedrijf – een tool die je zelf wilt. Het leren zit in de loop, en kleine dingen draaien sneller.

2. Schrijf vijf zinnen voordat je een tool aanraakt. Wat het doet; drie scenario's "de gebruiker doet X, ziet Y"; wat de eerste versie bewust weglaat. Dat is het verschil tussen sturen en drijven – en het is de gewoonte die later meeschaalt tot productie.

3. Kies het tool op het resultaat, niet op de demo. Webproduct → webbouwer. Mobiel product → tool met mobiel resultaat (en kies bewust tussen native en cross-platform). Alleen aan het verkennen → maakt niet uit, zonder schuldgevoel.

4. Reageer precies. "Fout" leert de agent niets; "de knop moet naar beneden, waar de duim komt" lost het in één stap op. Geef de agent instructies zoals je die aan een heel letterlijke en heel snelle developer zou geven – een vaardigheid die productmensen al hebben.

5. Itereer vroeg op een echte telefoon, als het product mobiel is – de simulator is beleefd, de duim is eerlijk.

Beginnen kost niets wat ertoe doet: de webbouwers hebben gratis abonnementen, en het gratis abonnement van Modaal is een volledig project met onbeperkt prompts; Pro kost € 9 per maand bij jaarlijkse betaling – de details staan op de prijzenpagina. De schaarse grondstof is de gebruikelijke – weten wat je moet bouwen. De tools zijn er alleen mee gestopt dat te verbergen.