Vibe coding en stille bugs: wat werkt is nog geen software

We bouwden een eigen content engine met AI-ondersteuning: snel, iteratief, en grotendeels gestuurd op gevoel en directe feedback. Dat is de kern van vibe coding. Je prompts, je bekijkt het resultaat, je stuurt bij. Het prototype stond er razendsnel. Maar toen we er goed naar keken, bleken drie onderdelen er volmaakt uit te zien en toch stiekem niets te doen. Geen foutmeldingen, geen crashes, gewoon stilte.

Wat is vibe coding precies?

Vibe coding is een aanpak waarbij je software bouwt door in gewone taal instructies te geven aan een AI-assistent, zoals GitHub Copilot, Cursor of ChatGPT, en de uitkomst direct beoordeelt op gevoel en visueel resultaat. De term werd begin 2025 gepopulariseerd door Andrej Karpathy, voormalig hoofd AI bij Tesla en mede-oprichter van OpenAI. Hij omschreef het als: “volledig meegaan in de vibe, exponentieel meer bouwen en vergeten dat er überhaupt code bestaat.”

Dat klinkt aantrekkelijk, en in de praktijk klopt het ook deels. Je kunt in een paar uur een werkende interface neerzetten die vroeger dagen kostte. Prototypes, intern gereedschap, snelle experimenten: vibe coding verlaagt de drempel fors. Maar “werkt op het oog” en “werkt betrouwbaar” zijn twee verschillende dingen.

Bug 1: de sla-functie die niets opsloeg

De knop was er, de bevestigingsmelding verscheen, de interface klikte vrolijk door. Maar de data verdween. De AI had een opslagfunctie gegenereerd die syntactisch correct was, maar waarbij de asynchrone aanroep niet werd afgewacht. Het resultaat: de gebruikersinterface deed alsof er opgeslagen was, terwijl de data al weg was voor de schrijfoperatie klaar was. Geen fout in de console, geen melding, niets. Je zag het pas terug als je de pagina herlaadde en constateerde dat alles weg was.

Bug 2: de validatie die altijd doorliet

Er was een veld waarvan de inhoud verplicht was voor de verdere verwerking van content. De AI bouwde een mooie validatieregel, inclusief foutmelding in het juiste rood. Maar de validatie zat aan de verkeerde kant van de logica: de controle vond plaats ná de verzending, niet ervoor. Lege invoer ging gewoon door het systeem, terwijl de foutmelding pas verscheen als het al te laat was. Visueel onberispelijk, functioneel waardeloos.

Bug 3: de API-koppeling die altijd succesvol leek

We koppelden de engine aan een externe dienst. De integratie zag er netjes uit: request, response, statusmelding. Alleen bleek de foutafhandeling zo geschreven te zijn dat ook een mislukte aanroep als succes werd teruggegeven. De externe dienst gaf een 422-foutcode terug; de eigen code interpreteerde elke response als geslaagd. Resultaat: de gebruiker dacht dat de actie werkte, terwijl er aan de andere kant niets was aangekomen. Dit ontdek je niet zonder bewust testen van foutsituaties, iets wat bij vibe coding zelden spontaan gebeurt.

Het verschil tussen iets dat werkt en iets waar een bedrijf op kan draaien

Software die “werkt” betekent in de praktijk: de happy path klopt. Klik door het systeem zonder iets raars te doen, en alles lijkt in orde. Bedrijfssoftware moet meer dan dat aankunnen. Medewerkers klikken op onverwachte momenten op de verkeerde knop. Externe systemen geven soms geen antwoord. Data komt soms in het verkeerde formaat binnen. Verbindingen vallen weg.

Dat zijn geen uitzonderingen, dat is de dagelijkse realiteit van een logistiek bedrijf, een automotive dealer of een productiebedrijf met tientallen medewerkers en meerdere systemen die op elkaar inhaken. De software moet bij al die situaties het juiste doen: duidelijke foutmeldingen geven, data integer houden, processen niet stilleggen.

Vibe coding optimaliseert standaard voor de happy path, omdat de AI reageert op wat je vraagt en je vragen volgen logischerwijs de logica die je zelf al voor ogen hebt. De edge cases, de foutsituaties, de randgevallen: die bedenk je niet altijd spontaan, en een AI vraagt er niet vanzelf naar.

Wanneer is vibe coding dan wél zinvol?

Eerlijk antwoord: vaker dan sceptici denken, en minder breed dan enthousiastelingen beweren.

Vibe coding is waardevol voor:

• Snelle prototypes om een idee te toetsen bij een klant of stakeholder, voordat je echt gaat bouwen.
• Intern gereedschap met lage risicoprofielen, waarbij een bug vervelend is maar geen klantschade veroorzaakt.
• Verkenning van technische haalbaarheid: kan dit systeem überhaupt wat we denken dat het kan?
• Snelle iteratie op de interface, waarbij de kernlogica al stevig staat.

Vibe coding is riskant zodra:

• Klantdata of financiële data in het spel is.
• Medewerkers dagelijks op de software vertrouwen voor hun werk.
• Koppelingen met externe systemen betrouwbaar moeten zijn.
• Fouten directe operationele of financiële gevolgen hebben.

Wij gebruiken vibe coding als vertrekpunt, niet als eindpunt. Het prototype helpt om snel te laten zien wat iets kan worden. Daarna begint het echte werk: structuur aanbrengen, foutafhandeling bouwen, testen op de gevallen die je niet wilt meemaken en de code reviewen alsof er een bedrijfsproces van afhangt, want dat is ook zo.