"Met AI bouw je exact wat je vraagt. De kunst is vragen wat je nodig hebt."

Een app ontwikkelen kost dankzij AI tegenwoordig een paar dagen, niet een kwartaal. En dat is precies de reden waarom het Jarno Eggink, CEO en oprichter van BOLD Digital, steeds vaker overkomt. Een collega, een opdrachtgever of een mede-ondernemer laat enthousiast iets zien dat hij zelf bouwde met Lovable, Base44 of Replit. Het werkt. De knoppen doen wat ze beloven, het dashboard oogt verzorgd, en de trots is terecht: een paar jaar geleden had dit een ontwikkelteam en weken gekost.

In dit blog vertelt Jarno in eigen persoon over de voor- en nadelen van een app ontwikkelen met AI, en welke vragen hij stelt waar niemand aan denkt.

App ontwikkelen met AI: waarom vibe coding zo aantrekkelijk is

Vibe coding is de naam geworden voor het fenomeen van zelf een app maken met AI, zonder diepgaande programmeerkennis. Je beschrijft wat je voor ogen hebt, en tools als  Lovable, Base44 of Replit schrijven de code. Je hoeft niet eerst een ontwikkelaar te overtuigen; je begint gewoon.

Vergelijk het met een schets op een bierviltje: in een paar seconden zie je wat iemand bedoelt, maar niemand bouwt op basis daarvan zomaar een nieuw centraal station. Vibe coding is zo'n schets, alleen kun je er al in klikken en doorheen lopen.

Wij doen het zelf ook, en niet onder de radar. Voor twee eigen producten die nu in een testfase zitten, bouwden we het prootype met behulp van AI, op basis van een goed doordacht en uitgeschreven briefing. Binnen een week stond er iets waar gebruikers echt mee aan de slag gingen. Geen wekenlang voortraject, maar een werkend systeem om gebruikersfeedback op te halen.

Dat is de kracht van vibe coding: het maakt een idee tastbaar voordat iemand er een mening over heeft gevormd. En met een gevibecodete applicatie voorkom je misinterpretatie over wat er gebouwd moet worden. Eerder schreven we het idee uit in documentatie. Nu is het concreet zichtbaar en tastbaar, waardoor elkaar verkeerd begrijpen minder voor de hand liggend is. En juist daarom is het zo verleidelijk om te denken dat je er met vibe coden al bent.

Het echte risico zit vóór het bouwen

AI bouwt precies wat je vraagt. Dat klinkt als een oplossing, maar het is eigenlijk het probleem. Een taalmodel stelt geen wedervraag over of je wel het juiste probleem op de juiste wijze aanpakt, het voert gewoon uit. Vraag je om een boekingssysteem, dan krijg je een boekingssysteem. Of dat ook het systeem is dat je klanten daadwerkelijk verder helpt, dat checkt niemand.

Dat risico zit niet in de techniek. Het zit in de vraag die je stelt voordat je begint met vibe coden. Welk probleem lost dit op, en voor wie precies? Is dit het eerste idee dat opkwam, of het juiste idee? Wat levert het op, en weegt dat op tegen de tijd die erin gaat zitten? En wat gebeurt er als het aanslaat: werkt het dan nog of piept en kraakt de applicatie al snel? En hoe zit het met de veiligheid? De ernstige kwetsbaarheden in PHP die in oktober 2026 werden onthuld laten nog maar eens zien hoe belangrijk een goed afgeschermde applicatie is.

Het gebeurt ook steeds vaker dat zo'n app na een paar weken alweer verandert: een extra schermpje hier, een nieuwe koppeling daar. Elke aanpassing voelt klein, want AI ontwikkelt het in een paar minuten. Maar de optelsom van tien kleine, ongestuurde keuzes is zelden hetzelfde als één doordachte richting.

Dat zijn geen technische vragen. Het zijn strategische vragen, en ze krijgen zelden evenveel aandacht als de bouw zelf. Begrijpelijk: een prototype is tastbaar en snel, een goed gesprek over de vraag erachter kost tijd en discipline. Maar wie die vraag overslaat, bouwt met evenveel gemak het verkeerde als het goede. Alleen ziet het verkeerde er, dankzij AI, inmiddels net zo overtuigend uit als het goede. 

Een prototype is een vraag, geen product

Een prototype hoeft geen productiesoftware te worden. Het hoeft maar één ding te doen: de juiste vraag beantwoorden. Werkt dit idee zoals ik dacht dat het zou werken? Voelt de gebruiker wat ik beoogde? Is dit de juiste eerste stap, of ontdek ik nu pas wat de echte vraag had moeten zijn?

Dat is een ander verhaal dan het verhaal dat je overal hoort: van vibe coden naar productie, alsof de weg daartussen een kwestie van lanceren is. Dat is het niet. Een prototype dat in een avond is gebouwd, test aannames. Productiesoftware draagt verantwoordelijkheid: voor gebruikers, voor data, voor doorontwikkelbaarheid en connectiviteit. Dat zijn vier verschillende opgaven, en ze lopen zelden toevallig in elkaar over.

Precies daarom is een prototype zo waardevol. Je kunt het gebruiken, ervaren en voelen en laten zien aan de mensen voor wie het bedoeld is. Dat levert een scherper gesprek op dan welk requirements-document ook. De eerste vraag die daarna volgt, is niet hoe we dit productieklaar maken, maar: welke aannames hebben we inmiddels bevestigd, wat moet nog worden uitgezocht en is het idee goed genoeg om verder te ontwikkelen?

Niet elke app heeft een vakman nodig

Niet elke zelfgebouwde app heeft daarna een vakman nodig. Een intern hulpmiddel voor drie collega's, zonder persoonsgegevens, zonder koppelingen: dat mag best blijven zoals het is. 

Maar zodra de app klanten bedient, persoonsgegevens verwerkt, koppelt met andere systemen of bedrijfskritisch wordt, dan wordt het een ander verhaal en komt er meer bij kijken dan de code zelf: de applicatie die blijft werken onder echte belasting, het live plaatsen in de App Store of Google Play, de AVG zodra er persoonsgegevens in het spel zijn, en doorontwikkeling.

Veiligheid verdient daarbij aparte aandacht: AI laat in gegenereerde code geregeld wachtwoorden en sleutels zichtbaar staan. Wij werken daarom ISO 27001-gecertificeerd en onderwerpen onze applicaties op gezette tijden aan geautomatiseerde tests om de juiste werking te garanderen en voeren penetratietests uit om de veiligheid te waarborgen.

Strategie vóór code. Ook bij vibe coding

Met AI bouw je exact wat je vraagt. De kunst is te weten wat je echt nodig hebt om de gewenste impact te maken. Dat vraagt geen wantrouwen tegenover vibe coding, eerder het tegenovergestelde: bouw gerust, bouw snel, en gebruik wat je bouwt als het scherpste gesprek dat je kunt voeren over wat je eigenlijk wilt bereiken.

Als iemand mij zijn app laat zien, stel ik twee vragen: lost dit het juiste probleem op, en wat is er nodig om het in productie te nemen? Laat het me zien, dan vertel ik je eerlijk wat er nog nodig is.

Het antwoord op die laatste vraag is zelden alleen technisch. Het eerste gesprek daarover duurt meestal langer dan je verwacht, en gaat over iets anders dan je denkt. Daarover volgende keer meer.

Strategy before code, sinds 1998.

Jarno Eggink, oprichter van BOLD Digital

‍

‍