Wat is vibe coding? Zo bouw je met AI, en zo beoordeel je het resultaatLeestijd: maximaal 11 minuten
Je hebt een idee voor een handige app, maar tussen dat idee en werkende software ligt een wereld van code. Wat is vibe coding, en maakt het die stap werkelijk kleiner? Met deze manier van bouwen beschrijf je in gewone taal wat je nodig hebt. AI maakt een eerste versie; jij probeert die uit en stuurt bij. Dat kan verrassend snel iets bruikbaars opleveren. Maar een scherm dat werkt, is nog niet automatisch een app die je veilig aan anderen kunt geven.
Wat is vibe coding, en welk probleem lost het op?
Stel: je wilt een overzicht waarin een klein team verkoopkansen kan bijhouden. Je weet welke informatie je wilt zien, maar niet hoe je een database, formulier en zoekfunctie programmeert. Voorheen moest je dat eerst leren of laten bouwen. Nu kun je beginnen met een beschrijving van het gewenste resultaat.
Vibe coding is software maken door AI in gewone taal opdrachten te geven, het resultaat te bekijken en met feedback te verbeteren. Je schrijft dus niet zelf elke regel code. De AI doet een groot deel van het bouwwerk.
Dat verlaagt vooral de drempel tussen“ik weet wat ik nodig heb” en“ik kan laten zien hoe het zou werken”. Het neemt een andere drempel niet weg: bepalen of de software onder alle relevante omstandigheden doet wat ze moet doen.
De term wordt niet altijd even strikt gebruikt. Oorspronkelijk hoort bij vibe coding ook dat iemand de code grotendeels laat voor wat die is en vooral op het zichtbare resultaat afgaat. Wie AI veel code laat schrijven, maar alles zorgvuldig laat nakijken, werkt óók met AI, alleen op een meer gecontroleerde manier.
Vibe coding of AI-assisted coding: wie houdt het stuur vast?
Bij AI-assisted coding programmeert een ontwikkelaar zelf en gebruikt die AI als hulp. Bijvoorbeeld om een fout te zoeken of een stuk code voor te stellen. Bij vibe coding begint het werk vaker met de gewenste uitkomst: “Maak een overzicht met deze functies.” AI vult vervolgens veel keuzes zelf in.
In de praktijk loopt dat door elkaar. Je kunt een eerste scherm laten maken zonder code te lezen en later een ontwikkelaar vragen de onderliggende werking te controleren. De relevante vraag is daarom niet welk etiket je gebruikt. De vraag is: welke beslissingen heb je aan AI overgelaten, en wie controleert ze voordat de app echt wordt gebruikt?
Daar zit ook een veelvoorkomend misverstand.“Ik hoef niet te kunnen programmeren” betekent niet“ik hoef niet te begrijpen wat de app moet doen”. Juist als je de code niet leest, moet je scherp kunnen beschrijven welke uitkomst goed of fout is.
Wat gebeurt er tussen jouw opdracht en een werkende app?
Aan de voorkant voelt het als een gesprek. Je schrijft een opdracht, krijgt een scherm te zien en vraagt om een wijziging. Achter dat eenvoudige gesprek moeten keuzes worden gemaakt: welke informatie wordt opgeslagen, hoe werken de knoppen samen en wat gebeurt er als iemand iets verkeerd invult?
De route ziet er grofweg zo uit:
Idee → opdracht → gegenereerde code → eerste versie → testen → fout of feedback → aangepaste versie.
Neem deze opdracht:“Maak een simpele webshop voor een kledingwinkel, met een productoverzicht, winkelwagen en betaalpagina.” Voor jou is dat één zin. Voor de bouwer zitten er veel open vragen in. Zijn maten per product verschillend? Wanneer raakt een artikel uitverkocht? Wat gebeurt er als een betaling mislukt?
AI moet ontbrekende antwoorden aannemen of om verduidelijking vragen. Daarom kan een eerste versie er overtuigend uitzien en toch een essentieel onderdeel missen. Zeg je daarna“Maak de productkaarten groter en voeg een filter op maat toe”, dan kan AI de zichtbare pagina aanpassen. Dat bewijst nog niet dat voorraad, bestellingen en betalingen achter de schermen kloppen.
Waarom kan een beginner ineens een app bouwen?
Veel apps bevatten herkenbare onderdelen: een formulier, een overzicht, een zoekveld of een knop om een status te wijzigen. AI kan voor zulke onderdelen een eerste opzet maken. Daardoor hoeft een beginner niet met een leeg scherm en een programmeertaal te beginnen.
Bovendien kun je feedback geven in woorden die je al kent.“Ik kan de open aanvragen niet vinden” is bruikbare feedback, ook als je niet weet hoe een filter technisch wordt gebouwd. Dat maakt het proces toegankelijker.
Toch schuilt hier een tegenintuïtief inzicht: hoe makkelijker het wordt om een eerste versie te maken, hoe belangrijker het wordt om goede vragen te stellen. Een fraaie app bouwen voor het verkeerde probleem is nog steeds verspilde moeite.
Wie vooral inspiratie zoekt voor kleine, concrete toepassingen, kan verder lezen bij onze voorbeelden van apps die je met Base44 kunt bouwen. Dat artikel gaat over ideeën voor die specifieke tool; hier kijken we naar de bredere werkwijze.
Een fictieve praktijkcase: van één zin naar een leadsoverzicht
Een medewerker van een klein Nederlands bedrijf wil af van een spreadsheet met verkoopkansen. Collega’s vullen statussen verschillend in en niemand ziet meteen welke aanvraag opvolging nodig heeft. Het idee is geen groot nieuw softwaresysteem. Het is een overzicht dat één dagelijkse vraag beantwoordt: wie moet vandaag iets doen?
De eerste opdracht luidt:
Maak een intern overzicht waarin ons team verkoopkansen kan toevoegen, filteren en opvolgen. Toon per kans de bedrijfsnaam, status, verantwoordelijke en volgende actie. Gebruik voorlopig alleen fictieve gegevens.
AI maakt een eerste scherm. De medewerker ziet een nette lijst, maar merkt dat twee collega’s dezelfde kans kunnen aanpassen zonder dat duidelijk is wie verantwoordelijk is. De volgende opdracht wordt specifieker:
Voeg één verantwoordelijke per verkoopkans toe. Laat kansen zonder volgende actie apart zien. Verander de bestaande velden niet.
Nu wordt de app nuttiger. Daarna komt de belangrijke test: wat gebeurt er als iemand een kans verwijdert, een veld leeg laat of een andere collega probeert te wijzigen? Op dat moment verandert de vraag van“Ziet het er goed uit?” naar“Kunnen we erop vertrouwen?”
Deze case is fictief. Het is een voorbeeld van een werkproces, geen verslag van een uitgevoerde WegwijsAI-test.
Het verborgen risico: een goede demo kan een slechte app zijn
Een scherm kan rustig ogen. De knoppen kunnen reageren. Zelfs een demonstratie kan vlekkeloos verlopen. Toch kunnen er problemen onder zitten die je tijdens één rondje klikken niet ziet.
Denk aan:
- gegevens die zichtbaar zijn voor de verkeerde gebruiker;
- dezelfde informatie die op meerdere plekken anders wordt opgeslagen;
- een foutmelding die verschijnt zonder dat duidelijk is wat er misging;
- wijzigingen die een eerder werkende functie kapotmaken;
- onderdelen die later moeilijk aan te passen zijn.
Dit is het tweede tegenintuïtieve inzicht: een app die minder indrukwekkend oogt, maar duidelijk begrensd en goed getest is, kan waardevoller zijn dan een complete demo. De demo toont wat mogelijk lijkt. De test laat zien waarop je kunt rekenen.
Een bruikbare controle is om niet alleen de ideale route te proberen. Test ook een leeg veld, een dubbele invoer en een gebruiker die iets níét mag zien. Vraag vervolgens iemand anders om dezelfde handelingen uit te voeren. Die persoon merkt vaak andere onduidelijkheden op.
Wanneer is vibe coding verstandig, en wanneer niet?
Het antwoord hangt minder af van de naam van het project dan van de gevolgen van een fout. Een eenvoudige pagina met fictieve gegevens vraagt om een andere controle dan een app met klantinformatie of betalingen.
| Project | Waarvoor AI-gestuurd bouwen kan helpen | Wat je extra moet beoordelen |
|---|---|---|
| Eenvoudige website | Snel een indeling en eerste versie maken | Inhoud, formulieren en toegankelijkheid |
| Prototype | Een idee zichtbaar maken en bespreken | Of de demo niet voor een afgerond product wordt gehouden |
| Interne tool | Een klein werkproces verkennen | Toegang, gegevens en afhankelijkheid van de tool |
| SaaS-app voor klanten | Functies en schermen uitproberen | Betrouwbaarheid, onderhoud en beveiliging |
| Financiële of medische toepassing | Hooguit een afgeschermd concept verkennen | Specialistische beoordeling vóór werkelijk gebruik |
| Complex bedrijfssysteem | Ideeën of losse onderdelen verkennen | Samenhang met bestaande systemen en professioneel beheer |
Dit is geen absoluut oordeel over wat AI wel of niet kan. Het is een beslisroute voor menselijke controle. Hoe gevoeliger de gegevens, hoe groter de gevolgen van een fout en hoe langer de app mee moet gaan, hoe minder verstandig het is om alleen op het zichtbare resultaat af te gaan.
Zo begin je klein, zonder de controle kwijt te raken
Wil je de werkwijze proberen? Kies dan niet meteen een webshop met echte betalingen of een klantportaal met echte dossiers. Begin met een klein probleem en fictieve gegevens.
- Kies één taak. Bijvoorbeeld: openstaande aanvragen overzichtelijk tonen.
- Beschrijf de gebruiker. Wie bekijkt het overzicht en wat wil die persoon ermee doen?
- Noem de grens. Geef aan wat de eerste versie juist níét hoeft te kunnen.
- Laat een eerste versie maken. Beoordeel of de hoofdtaak logisch werkt.
- Test afwijkingen. Probeer lege velden, dubbele invoer en onverwachte keuzes.
- Laat belangrijke onderdelen nakijken. Zeker voordat echte gegevens of andere gebruikers toegang krijgen.
Een heldere opdracht is belangrijker dan een lange opdracht. Wil je zien hoe je een appbouwer gerichter aanstuurt, dan vind je in ons artikel over Base44-prompts voor betere apps voorbeelden voor die tool. De les is breder toepasbaar: vertel niet alleen wat er op het scherm moet staan, maar ook voor wie het is en wanneer het resultaat goed genoeg is.
Wat verandert er voor ontwikkelaars?
Als AI standaardonderdelen kan voorstellen, verschuift een deel van het werk. Minder tijd hoeft naar het eerste lege scherm. Meer aandacht kan gaan naar de vraag of onderdelen bij elkaar passen, of uitzonderingen goed zijn afgehandeld en of iemand de app later nog kan onderhouden.
Dat betekent niet dat programmeerkennis waardeloos wordt. Integendeel: kennis kan minder nodig zijn om iets te produceren, maar juist belangrijker worden om te beoordelen wat er is geproduceerd. Bij een serieus product blijft iemand nodig die verantwoordelijkheid neemt voor de werking achter het scherm.
Wil je begrijpen hoe zo’n gecontroleerde aanpak eruitziet in een bestaande programmeeromgeving? Ons artikel over wat Cursor AI is gaat specifiek over die editor. Daarmee blijft dit artikel gericht op vibe coding als werkwijze, zonder een tweede Cursor-handleiding te worden.
De visie van WegwijsAI: maak het idee zichtbaar, niet het risico onzichtbaar
Bij WegwijsAI zouden we vibe coding niet afrekenen op de vraag of de eerste versie meteen perfect is. De waarde zit erin dat iemand een idee kan laten zien, erop kan reageren en sneller ontdekt welke vragen nog openstaan.
Maar dat voordeel verdwijnt zodra“het ziet er goed uit” wordt verward met“het is klaar voor gebruik”. Begin dus vrijmoedig met een klein prototype. Word strenger zodra anderen erop vertrouwen, gegevens invoeren of afhankelijk worden van de uitkomst.
De beslisvraag is uiteindelijk simpel: wil je een idee verkennen, of moet de software betrouwbaar werk overnemen? Voor het eerste kan vibe coding een prettig begin zijn. Voor het tweede heb je aantoonbare controle en, afhankelijk van het risico, professionele softwareontwikkeling nodig.
Veelgestelde vragen
Heb je programmeerkennis nodig voor vibe coding?
Niet om een eerste opdracht te schrijven of een prototype te beoordelen. Zodra een app echte gegevens verwerkt of door anderen wordt gebruikt, is technische controle wel belangrijk.
Is vibe coding hetzelfde als een app bouwen met Base44?
Nee. Vibe coding is een manier van werken. Base44 is een tool waarmee je die manier van werken kunt toepassen. Ook andere AI-hulpmiddelen kunnen bij het bouwen helpen.
Wanneer is een prototype klaar voor echt gebruik?
Niet zodra het er goed uitziet. Controleer eerst of belangrijke handelingen, uitzonderingen, toegang en gegevensverwerking kloppen. Hoe groter de gevolgen van fouten, hoe zwaarder die controle moet zijn.
Over de auteur
