Vibe coding: wanneer heb je een echte developer nodig?

Wat is vibe coding?

De term vibe coding komt van AI-onderzoeker Andrej Karpathy. In februari 2025 beschreef hij een manier van programmeren waarbij je de AI het werk laat doen, de voorgestelde wijzigingen accepteert zonder ze te lezen en foutmeldingen gewoon terugplakt in de chat. Je beschrijft wat je wilt en vergeet min of meer dat er code bestaat.

Tools als Lovable, Bolt.new, v0, Replit, Cursor en Claude maken dat voor iedereen bereikbaar. Je hoeft niet te kunnen programmeren om een werkende app met inlogscherm, database en betalingen te bouwen. Dat is echt nieuw, en ik vind het een goede ontwikkeling: meer mensen kunnen hun idee uitproberen zonder eerst een flink budget uit te geven.

Karpathy zei er zelf bij dat het vooral goed genoeg is voor weekendprojecten die je daarna weggooit. Die grens zie ik in de praktijk ook. Het lastige is dat veel apps niet worden weggegooid, maar ineens klanten krijgen.

Waar vibe coding goed in is

Voor een prototype is vibe coding moeilijk te verslaan. In een paar dagen heb je iets wat je aan klanten kunt laten zien, en hun reactie leert je meer dan een plan op papier. Je ontdekt welke functies mensen echt gebruiken voordat je er veel geld in steekt.

Het werkt ook goed voor interne tools met weinig gebruikers en weinig risico: een planningsoverzicht voor je eigen team, een formulier dat gegevens in een spreadsheet zet of een dashboard met cijfers die toch al openbaar zijn. Gaat daar iets mis, dan blijft de schade beperkt.

Het probleem begint als een app die als experiment begon, ongemerkt een bedrijfskritisch systeem wordt. Dan gelden er andere eisen voor veiligheid, betrouwbaarheid en onderhoud, terwijl de code nog precies dezelfde is.

Signalen dat je een developer nodig hebt

Er is geen vaste grens, maar founders kloppen meestal op dezelfde momenten bij me aan. Herken je er één of meer, dan is het tijd om iemand mee te laten kijken.

• Je hebt betalende gebruikers. Een storing kost je nu omzet en vertrouwen.
• Je app slaat persoonsgegevens of betaalgegevens op. Dan geldt de AVG en is een datalek een echt probleem.
• De AI lost één bug op en veroorzaakt er twee nieuwe. Je draait rondjes en elke wijziging voelt als een gok.
• Je begrijpt je eigen code niet meer. Je weet niet waar iets staat of waarom het werkt.
• Je app wordt traag naarmate er meer gebruikers of meer data bijkomen.
• Een investeerder of grote klant wil weten hoe je app in elkaar zit en hoe veilig hij is.
• Je krijgt vragen over compliance, zoals een verwerkersovereenkomst, een beveiligingsvragenlijst of een audit.

Wat een developer dan eigenlijk doet

Een goede developer gooit je app niet weg om hem opnieuw te bouwen. Het eerste wat ik doe, is lezen: hoe zit de app in elkaar, waar staan de gegevens, wie kan wat zien en welke onderdelen zijn kwetsbaar. Daar maak ik een overzicht van, met wat dringend is en wat kan wachten.

Daarna gaat het om de dingen die een AI-tool zelden uit zichzelf doet. Tests schrijven, zodat een wijziging niet ongemerkt iets anders breekt. De beveiliging controleren, zoals wie bij welke data mag en of er sleutels in de code staan. Structuur aanbrengen, zodat de app over een jaar nog te begrijpen is. En monitoring inrichten, zodat je weet dat er iets misgaat voordat je klant het merkt.

Die beveiliging is geen detail. Veracode testte in 2025 meer dan 100 AI-modellen op 80 programmeertaken. In 45 procent van de gevallen bevatte de code een kwetsbaarheid uit de OWASP Top 10, de bekende lijst met de meest voorkomende beveiligingsrisico’s van webapplicaties. Werkende code is dus nog geen veilige code.

Tot slot houdt een developer de app bij. De pakketten waar je app op draait, krijgen regelmatig updates, ook om beveiligingslekken te dichten. Wie die niet bijhoudt, loopt na een paar maanden achter.

Samenwerken zonder je app weg te gooien

Je hoeft niet te kiezen tussen AI en een developer. De combinatie werkt het best: jij blijft met je AI-tool nieuwe dingen bouwen en uitproberen, en een developer kijkt mee, ruimt op wat nodig is en houdt de basis gezond.

Spreek daarvoor een paar dingen af. Werk via GitHub, zodat elke wijziging zichtbaar is en terug te draaien. Laat grote wijzigingen eerst in een testomgeving landen. En vraag bij twijfel of iets veilig is voordat het live gaat, in plaats van achteraf.

Zo houd je de snelheid van vibe coding, zonder dat je app een zwarte doos wordt waar niemand meer aan durft te komen.

Zo draag je je app over

Of je nu met mij werkt of met iemand anders: een goede overdracht scheelt uren uitzoekwerk, en dus geld. Dit heeft een developer nodig om te kunnen beginnen.

• Toegang tot de code, bij voorkeur in een GitHub-account van je eigen bedrijf.
• Toegang als teamlid tot je database, hosting en andere diensten, zoals Supabase, Firebase, Vercel of Stripe.
• Een overzicht van de omgevingsvariabelen en sleutels die je app gebruikt, veilig gedeeld via bijvoorbeeld een wachtwoordmanager en niet via gewone e-mail.
• Een korte beschrijving van wat de app doet: de belangrijkste schermen, de soorten gebruikers en de koppelingen met andere diensten.
• De problemen die je nu ziet, met een voorbeeld of schermafbeelding.

Hoe ik daarbij help

Ik ben Patrick Willemsen, eigenaar van BugFyx in ’s-Hertogenbosch. Ik heb meer dan 8 jaar ervaring als software engineer, voor klanten als ING, ABN AMRO, de Volksbank, VodafoneZiggo en TCS. Ik neem apps aan die met Lovable, Bolt.new, v0, Replit, Cursor of Claude zijn gebouwd, in onder meer React, Next.js, TypeScript, Supabase, Firebase, Node.js, Python, Java, Spring Boot, PostgreSQL en Vue.

Meestal begin ik met een App Check. Voor €600 excl. btw bekijk ik een app tot 15 schermen, met één database en maximaal 3 koppelingen. Binnen 5 werkdagen krijg je een rapport in gewone taal, met de risico’s gerangschikt van rood via oranje naar groen, en een gesprek van 30 minuten waarin ik alles uitleg.

Wil je daarna dat ik de app blijf onderhouden, dan kan dat in een onderhoudsplan vanaf €600 per maand. Start je dat binnen 30 dagen, dan verreken ik de €600 van de App Check volledig.