Vibe coding: wat AI goed kan en waar ervaring telt

Ron Aarnink

Tweede blog in de serie over AI in softwareontwikkeling. Lees ook de introblog waarin we onze houding rond AI uitleggen.

Eind 2024 was vibe coding een term die nog niemand kende. Een jaar later koos Collins Dictionary hem als woord van het jaar. Het idee erachter is simpel: je beschrijft in gewone taal wat je wilt, AI bouwt de software, jij accepteert wat eruit komt zonder er heel diep naar te kijken.

Wie de term bedacht? Andrej Karpathy, een vooraanstaande AI-onderzoeker en mede-oprichter van OpenAI. Hij plaatste begin 2025 een berichtje op X waarin hij zijn manier van werken beschreef, en dat berichtje sloeg in als een bom.

Inmiddels gebruikt iedereen het. Van product managers die zonder hulp van een ontwikkelaar een werkende app willen, tot bedrijven die complete bedrijfssoftware op deze manier laten bouwen. En precies daar, tussen waar de term voor bedoeld was en waar hij nu voor wordt gebruikt, zien wij als softwareontwikkelaars iets fout gaan. In deze blog leggen we uit wat, waarom, en wat je er als bedrijf mee zou moeten.

Waar Karpathy het zelf voor bedoelde

In zijn oorspronkelijke bericht zei Karpathy iets dat de afgelopen maanden vaak wordt vergeten. Hij gebruikte vibe coding voor “throwaway weekend projects”. Wegwerp-experimenten. Hobby-werk. Een zaterdagmiddag iets in elkaar tikken om een idee te testen.

Niet voor de software die een bedrijf draaiende houdt.

Ook Simon Willison, een andere bekende stem in deze hoek, was duidelijk: vibe coding gebruiken om een productie-systeem te bouwen is duidelijk riskant. Tussen waar de term voor bedoeld is en waar hij nu voor wordt gebruikt, zit een groot gat. En precies in dat gat kunnen problemen ontstaan.

Wat er in de praktijk fout kan gaan

De fouten van AI-code zijn zelden spectaculair. Ze halen meestal het nieuws niet. Wat ze gemeen hebben, is dat ze pas zichtbaar worden als het te laat is. Bij groei, bij druk, bij een aanvaller die nét even kijkt. Een paar patronen die we tegenkomen:

Sleutels en wachtwoorden die in de code blijven staan.

AI heeft een soms een handige gewoonte om bij wijze van voorbeeld een API-sleutel of wachtwoord in de code te zetten. Werkt prima, totdat die code ergens belandt waar derden hem kunnen lezen. Een publiek GitHub-repository, een verkeerd gedeelde back-up, een nieuwe ontwikkelaar die meekijkt of een bezoeker die in de code kijkt. Onderzoek van securitybedrijf Apiiro liet zien dat AI-assisted code 40% vaker dit soort sleutels per ongeluk in de code achterlaat dan code die door mensen is geschreven.

Een formulier dat te veel slikt.

Een eenvoudig contactformulier, door AI gebouwd. Het werkt, de mails komen binnen. Maar zonder controle staat het formulier open voor van alles: iemand die kwaad wil, kan via dat formulier code uitvoeren of mails versturen vanuit jouw domein. Pas weken later, als jouw e-mails op spamlijsten belanden, ontdek je dat er iets niet klopte.

Library-keuzes die over een jaar problemen geven.

AI stelt regelmatig externe pakketten voor die op het oog werken, maar al jaren niet meer worden onderhouden. Of pakketten met een licentie die niet past bij commercieel gebruik. Of pakketten met bekende beveiligingslekken. Daar is een aparte blog voor, die komt later in deze serie.

Een pagina die traag wordt zodra je groeit.

Een veelvoorkomend voorbeeld: je vraagt AI om een overzicht van klanten met openstaande facturen. AI levert nette code op. In de testomgeving, met tien klanten, laadt de pagina razendsnel. Een halfjaar later, bij vijfduizend klanten, is dezelfde pagina opeens onbruikbaar traag. AI heeft voor elke klant een aparte vraag naar de database gemaakt. Tien vragen merk je niet, vijfduizend wel. Een ervaren ontwikkelaar had die in één keer geschreven.

Een klant die per ongeluk data van een andere klant ziet.

Misschien wel het stilste, en daardoor onaangenaamste, type fout. AI bouwt een functie waarbij klant A zijn eigen bestellingen kan opvragen. Werkt perfect, totdat blijkt dat als klant A een bestel-ID in de URL aanpast, hij ook de bestellingen van klant B kan zien. AI heeft de check op “is dit jouw eigen bestelling” overgeslagen, of niet eens overwogen, omdat hij de context van een multi-tenant systeem niet kende. Niet onbelangrijk: dit is precies het soort fout dat onder de AVG meldingsplichtig is.

Wat onderzoek inmiddels laat zien

Deze patronen zijn geen losse incidenten. Ze komen breed terug in onderzoek. In 2025 en 2026 verschenen meerdere studies die hetzelfde beeld laten zien.
Veracode, een onafhankelijk securitybedrijf, testte meer dan honderd verschillende AI-modellen op tachtig coderingstaken. De uitkomst: in 45% van de gevallen bevat de gegenereerde code een beveiligingslek. En dat verbetert niet snel, een vervolgrapport uit oktober 2025 liet zien dat zelfs nieuwere modellen op vrijwel hetzelfde niveau bleven hangen.

Apiiro, een ander securitybedrijf, vond dat code die met AI-assistentie wordt geschreven drie keer zo veel wegen openlaat waarlangs aanvallers extra rechten kunnen krijgen. Daarnaast: 40% meer “secrets” zoals wachtwoorden en API-sleutels, die per ongeluk in de code worden achtergelaten. CodeRabbit, een tool die code reviewt, vond in een eigen onderzoek dat AI-gegenereerde code 1,75 keer vaker logica-fouten bevat en 1,42 keer vaker performance-problemen dan code die door mensen is geschreven.

Het is niet dat AI geen goede code kan schrijven. Het is dat de fouten die het maakt, vaak pas zichtbaar worden als het te laat is. In het rapport van Lightrun uit april 2026 stond dat 43% van AI-gegenereerde codewijzigingen achteraf gedebugd moest worden in productie. Niet tijdens de ontwikkeling, maar nadat klanten er last van kregen.

Maar AI wordt steeds beter en dat verandert het verhaal

Wat hierboven staat, klinkt misschien somber. Dat is het niet bedoeld te zijn. AI wordt in een hoog tempo beter, en de meeste van deze patronen zijn met de juiste aanpak prima te ondervangen. Maar daar zit precies het verschil tussen vibe coding en serieuze AI-ondersteunde ontwikkeling.

Moderne AI-tools werken op basis van wat je hem meegeeft. Niet alleen de opdracht zelf, maar ook de context daaromheen: welke frameworks worden gebruikt, welke afspraken gelden in dit project, welke fouten je in een vorig project bent tegengekomen, welke beveiligingseisen vanzelfsprekend zijn. Dat kun je vastleggen in wat in de praktijk “skills”, “system prompts” of “context-bestanden” heten, een soort handleiding voor de AI, die hij bij elke opdracht raadpleegt.

Iemand die “Maak even een order-tool voor mij” in een AI typt en op enter drukt, krijgt iets terug dat werkt. Voor tien orders. Iemand die diezelfde tool laat bouwen met een goed uitgewerkte set aan instructies, over hoe klantdata wordt gescheiden, hoe input wordt gevalideerd, hoe wachtwoorden worden opgeslagen, hoe de tool zich gedraagt bij piekverkeer, krijgt iets terug dat veel dichter bij productieklaar zit. De AI is in beide gevallen dezelfde. Het verschil zit in het plan eromheen.

En dat is precies waar de kennis van een ervaren ontwikkelaar bij komt kijken. Niet zozeer in het tikken van code, daar is AI hard op aan het inhalen. Maar in het weten welke instructies je vooraf moet meegeven. Welke fouten je hebt gezien gebeuren. Welke scenario’s je vastlegt voordat AI ook maar één regel code schrijft. Dat is geen tovenarij, het is vakmanschap. Het zit in dingen die je niet leert door een paar prompts te schrijven, maar door jarenlang software in productie te zien werken.

De AI van vandaag is dus al een stuk beter dan die van een jaar geleden. Maar hij is alleen zo goed als de mens die hem instructies geeft.

Waarom dit voor jouw bedrijf relevant is, ook als je geen miljoen klanten hebt

We snappen het bezwaar al. “Wij hebben geen miljoen gebruikers. Wat boeit het ons of AI-code op die schaal vastloopt?” Het boeit, om twee redenen.

Ten eerste: de problemen die op schaal zichtbaar worden, zijn er ook bij kleine systemen. Ze zijn alleen minder dramatisch. Een AI-gegenereerde database-query die op tien klanten in een halve seconde antwoordt, kan bij honderdduizend records minuten gaan duren. Op kleine schaal merk je dat niet. Tot je groeit, en je opeens een traag systeem hebt waarvan niemand weet waarom het traag is, want niemand heeft de code ooit echt gelezen.

Ten tweede: de “tien versus een miljoen”-verhouding gaat niet alleen over aantal gebruikers. Het gaat over alle situaties waarin code onder druk komt te staan. Vakantieperiode met piekverkeer. Een grote klant die in één keer duizend bestellingen plaatst in plaats van vijf. Een koppeling met een ander systeem die honderd keer per minuut wordt aangeroepen in plaats van één keer per uur. Allemaal momenten waarop “code die werkt” in de testomgeving plotseling “code die crasht” wordt in productie.

Ervaren ontwikkelaars hebben deze situaties meegemaakt. Ze hebben gezien hoe een onschuldige query een hele server kan platleggen, hoe een ontbrekende controle op input een security-lek wordt zodra een aanvaller het ontdekt, hoe een library die toevallig één jaar geleden werd voorgesteld inmiddels niet meer wordt onderhouden. Dat soort patroonherkenning bouw je niet op door AI te prompten. Die bouw je op door jarenlang software in productie te zien werken…. en falen.

Hoe wij ermee omgaan

Wij gebruiken AI. Volop, ook bij werk dat in productie komt. Het bespaart enorm veel tijd op repetitief werk, op het schetsen van eerste versies, op het opzoeken van patronen. Het zou onverstandig zijn om dat niet te benutten.

Maar we gebruiken het ánders dan vibe coding. Het verschil zit niet zozeer in of we AI inzetten, maar in wat er omheen gebeurt. Voor, tijdens en na.

Voor we beginnen, denken we mee. Dit is waar in de vorige sectie de skills en instructies langskwamen, en in de praktijk doen we dat ook zo. Wij denken vooraf na over de scenario’s waar de software mee te maken gaat krijgen: wat als er piekverkeer is, wat als een gebruiker iets onverwachts invoert, wat als er over een jaar een koppeling bijkomt, hoe moet klantdata gescheiden blijven, welke afspraken gelden binnen dit project. Die scenario’s en afspraken leggen we vast zodat AI er bij elke opdracht rekening mee houdt. Daar zit de eerste, en grootste, stap in het voorkomen van de fouten die we hierboven beschreven.

Tijdens het werk houden we de regie. Welke frameworks en technieken we gebruiken, is een bewuste keuze, niet wat AI op dat moment toevallig voorstelt. We kiezen wat past bij het project en wat wij — ook zonder AI — kunnen onderhouden en bijsturen. Dat klinkt vanzelfsprekend, maar het is precies waar bij snelle AI-gedreven ontwikkeling soms misloopt: code die werkt, in een framework dat niemand in het team echt doorgrondt.

Na het werk controleren we alles. Iedere oplevering wordt door een ontwikkelaar bekeken. We controleren wat AI heeft geschreven, of we het zelf hadden geschreven, en of het past bij wat het project op de lange termijn nodig heeft. We testen op meer dan “werkt het”. We testen op wat er gebeurt bij volume, bij vreemde input, bij situaties die je niet meteen verzint. Zo komen we niet voor verrassingen te staan. En jij ook niet.

Het verschil met vibe coding is niet dat wij AI op afstand houden. Het verschil is dat we niet vibrieren. We bouwen.

Wat dit voor jou betekent

ls je software laat ontwikkelen, ga je tegenwoordig vrijwel zeker met AI te maken krijgen. Iedere serieuze partij gebruikt het inmiddels in zijn proces. De vraag is niet of AI in jouw project zit, maar hoe het wordt ingezet en hoe het wordt gecontroleerd.

Een paar vragen die je kunt stellen aan de partij waarmee je werkt:

  • Wie kijkt naar de code die AI heeft geproduceerd, en met welke blik?
  • Hoe zorgen jullie dat de gebruikte frameworks en libraries onderhouden zijn?
  • Wat gebeurt er als ons systeem opeens veel meer gebruikt wordt dan nu?
  • Wie is er over vijf jaar nog in staat om dit systeem aan te passen, ook als AI tegen die tijd anders werkt?

Voor ons is dat het uitgangspunt: AI helpt ons sneller bouwen, maar de software moet werken voor jouw bedrijf, vandaag, en over jaren. Bij ons zit AI naast de ontwikkelaar, niet in zijn plaats. Dat is geen marketingkreet, dat is hoe we werken.

In de komende blogs werken we de andere onderwerpen uit deze serie verder uit. Over externe pakketten en het verborgen risico in moderne software. Over beveiliging die net niet helemaal klopt. En over software die over vijf jaar nog meegroeit met je bedrijf.

Benieuwd wat wij voor jou kunnen betekenen?

Een gesprek is zo gemaakt. We kijken samen naar waar je nu staat, waar het knelpunt zit, en of wij de juiste partij zijn. Ook als dat betekent dat we doorverwijzen. Neem gerust contact met ons op.