2026: An AI Odyssey — De kater van Vibe-Coding in 2025

In 2025 werd ‘vibe coding’ een reële werkwijze, met alle voor- en nadelen van dien: het idee was dat ik beschreef wat ik wilde, accepteerde wat het model mij gaf, de volgende foutmelding plakte, en dat steeds opnieuw. De code “werkte”, maar ik had hem vaak eigenlijk niet gelezen of begrepen (vooral als het in een taal was die ik niet ken).

De term ‘vibe coding’ is bedacht door Andrej Karpathy in een artikel dat viraal ging en waarin hij een modus beschreef waarin je ‘vergeet dat de code überhaupt bestaat. Simon Willison gaf later de duidelijkste definitie die teams kunnen gebruiken voor beleid en code review: Vibe coding is “code genereren met AI zonder je te bekommeren om de code die eruit komt.

Die houding kan volkomen logisch zijn voor prototypes en eenmalige tools. Denk aan kleine black-box-modules die eenvoudige taken uitvoeren en die taken correct lijken uit te voeren, zo van ‘ik heb het alleen nodig om dit ene ding voor mij te doen’ dat is prima voor makers en hobbyisten.

De ontnuchtering komt wanneer die ‘wegwerp’-artefacten afhankelijkheden, inkomstenbronnen of ingebouwde firmware worden die jarenlang moeten worden onderhouden, gecontroleerd en beveiligd. Als 2025 het jaar was waarin iedereen sneller leverde, dan is 2026 het jaar waarin veel teams ontdekken wat ze hebben geleverd.

Wat bedoelen we met “Vibe Coding” en wat niet

Heel veel technici gebruikten AI in 2025 zonder aan vibe coding te doen: standaardcode genereren, tests schrijven, onbekende API's uitleggen, of een eerste opzet maken die daarna gewoon werd gereviewd. Dat is gewoon AI-ondersteund ontwikkelen.

Vibe coding is de “niemand is verantwoordelijk voor de binnenkant”-modus. Op dat punt gaan we verder dan de tool en kijken we naar houding. Zien we AI-output als onbetrouwbare code die net als elke andere bijdrage getest, gereviewd en doorgelicht moet worden? Of beschouwen we het als een manier om deze beperkingen te omzeilen?

In de praktijk rollen teams langzaam vibe coding in via kleine, logische stappen: een snel scriptje hier, een verbindingslaagje daar, een “tijdelijke” automatisering, een gegenereerde migratie, een gegenereerde CI workflow, een gegenereerde Terraform module. Elk onderdeel is op zichzelf logisch. Het resultaat op systeemniveau is een codebase met meer oppervlakte, meer afhankelijkheden, en minder mensen die écht snappen waarom het werkt.

Snelheid gaat omhoog, stabiliteit niet

Het meest opvallende datapunt dat ik heb gezien is DORA’s onderzoek naar generatieve AI. In de DORA rapportage van 2024 gaf Google aan dat, naarmate AI meer werd gebruikt, de stabiliteit van opleveringen met naar schatting 7,2 % daalde en de doorvoersnelheid met 1,5 % afnam .

In het rapport van DORA over 2025 werden deze cijfers gepresenteerd als geschatte verandering per 25% toename in AI-toepassing, en werd de nadruk gelegd op de kloof tussen hoe snel ontwikkelaars denken te werken en wat de leveringsprestaties laten zien .

Dat patroon past precies bij waar vibe coding op optimaliseert: lokale snelheid (iets aan de praat krijgen) in plaats van wereldwijde betrouwbaarheid (een systeem stabiel houden als het groeit). AI maakt veranderingen goedkoper, wat grotere wijzigingen en vaker wijzigingen aanmoedigt. Als je release-management al niet geweldig is, dan versterkt AI dat probleem alleen maar.

Er is nog een minder comfortabele mogelijkheid: soms bespaart AI geen tijd voor ervaren ontwikkelaars in vertrouwde codebases, zelfs als dat zo voelt. Een gecontroleerd onderzoek van METR vond dat ervaren open-source ontwikkelaars met AI-tools van begin 2025 ongeveer 19% langer bezig waren dan zonder, terwijl ze dachten dat ze sneller waren . De boodschap is niet “AI is slecht”, maar: “Je gevoel klopt niet altijd.” Als een workflow het begrip verlaagt of het checkwerk verhoogt, kan snelheid juist tegenvallen.

Kwaliteitsproblemen die in een demo niet opvallen

Vibe-code slaagt vaak in oppervlakkige tests, omdat die code is geoptimaliseerd op plausibiliteit (“zo plausibel dat ik het niet geloof!”). De fouten komen later, en zijn dan duur om uit te zoeken:

• Te veel compromissen: kwetsbare code die helemaal uitgaat van de huidige input, API’s of HTML, zonder contracten of versiebeheer.
• Verborgen complexiteit: Kleine scripts met één bestand die geleidelijk herhalingslogica, caching, gelijktijdigheid en afhandeling van uitzonderingsgevallen toevoegen, totdat deze scripts complete systemen worden.
• Niet-zo-duidelijk prestatieverlies: N+1 queries, kwadratische loops, onbeperkte wachtrijen, eager loading of “even caching erbij” patronen die echte oorzaken verhullen.
• Configuratiegevaren: CI/CD-workflows, cloud IAM-regels, Kubernetes-manifests en Terraform-modules die “werken” maar gevaarlijke standaardinstellingen bevatten.
• Testtheater: gegenereerde tests die het huidige gedrag checken in plaats van het bedoelde gedrag, of die echte risico’s verbergen.

Het patroon: de intentie ontbreekt. Handgeschreven systemen hebben meestal nog wel ergens een spoor van waarom. Vibe-code heeft alleen wat: het doet dit nu, dus daar testen we op.

Beveiliging: “Het compileert” is geen beveiligingseigenschap

Vibe coding optimaliseert vaak voor “werkt op mijn machine” in plaats van “veilig onder alle omstandigheden”. Dat is niet alleen theorie. Een empirisch onderzoek naar AI-gegenereerde codefragmenten vond een “grote kans op veiligheidsproblemen”, waaronder veel Python- en JavaScript-voorbeelden met issues volgens de Common Weakness Enumeration in echte GitHub-projecten .

Dit soort onderzoeken zijn geen oordeel over een tool; statische analyse geeft ook valse positieven, en “gevonden zwakke plek” is niet altijd “echt exploiteerbaar”. Maar de trend is duidelijk: plausibele code is niet altijd veilige code, en security is precies het soort niet-functionele eis waar vibe coding aan voorbijgaat.

De veiligheidsrisico's die het vaakst voorkomen in AI-intensieve codebases zijn ook de bekende klassiekers:

• Injectie en onveilige constructie: SQL-injectie, command-injectie, onveilige deserialisatie, templateproblemen en zwakke inputvalidatie.
• Geheimen lekken: sleutels in “tijdelijke” scripts, logs met tokens, en debug endpoints die per ongeluk live gaan.
• Auth- en sessiefouten: zelfgemaakte authenticatie, ontbrekende authorisatiechecks en verkeerde aannames over identiteiten tussen diensten.
• Crypto valkuilen: zelfgebouwde random-functies, verkeerde modi, foute sleutelopslag, onveilige standaardinstellingen die alsnog door tests komen.

Vibe-codering is niet per definitie onveilig; het is onveilig op een zeer specifieke manier: het maakt het eenvoudig om veel code te produceren zonder het inzicht dat nodig is om de beveiligingsaannames te herkennen die men onbedoeld maakt.
 

Risico's in de supply chain: pakket-hallucinaties en ‘afhankelijkheidsgerichte’ aanvallen

Als je AI-output overneemt zonder het te lezen, worden afhankelijkheden de belangrijkste aanvalsvector. Eén risico is “package hallucination”: het model stelt een dependency voor die niet bestaat. Een aanvaller kan een pakket onder die naam publiceren en wachten tot iemand het installeert. USENIX analyseerde dit fenomeen en noemde het een variant van package-confusion risico in de software supply chain .

Het belangrijkste punt is dat AI ervoor zorgt dat ‘probeer deze bibliotheek’ een standaardhandeling wordt. In een vibe-coding-loop voelt het toevoegen van afhankelijkheden minder belastend dan het begrijpen van de code die u al heeft. Dat zorgt voor:

• het aantal transitieve afhankelijkheden dat u onbewust vertrouwt,
• de snelheid waarmee onbekende pakketten in uw build terechtkomen, en
• de moeilijkheid van auditing en patchen wanneer zich een incident in de supply chain voordoet.

Voor embedded en industriële code worden de fouten minder vergevingsgezind

Websoftware kan vaak ‘zacht’ falen, wat betekent dat ze kan verslechteren zonder onmiddellijke fysieke schade of permanente schade te veroorzaken: een eindpunt retourneert 500s, een functie wordt tijdelijk uitgeschakeld, verkeer wordt omgeleid, er vindt een rollback plaats, gebruikers proberen het later opnieuw. Embedded systemen daarentegen hebben de neiging om uit te vallen in de vorm van tijdelijke storingen, timingfouten, veiligheidsincidenten of onherstelbare bricking. Vibe-gecodeerde firmware is hier bijzonder gevoelig voor:

• Onjuiste hardwaregegevens: registernamen, bitvelden, timingwaarden en ‘magische getallen’ die aannemelijk maar onjuist zijn.
• Concurrency- en interruptproblemen: onderlinge concurrentie rond ISR's, DMA, RTOS-primitieven en gedeelde buffers die alleen onder belasting optreden.
• HAL-misbruik: het combineren van HAL-aanroepen van leveranciers met directe registerbewerkingen op een manier die in strijd is met de aannames (en niet-reproduceerbare bugs veroorzaakt).
• Protocol-randgevallen: I²C/SPI/UART drivers die rooktests halen, maar falen bij clock stretching, ruis, busconflicten of gewoon langere kabels.
• Watchdog- en recoverygaten: code die “werkt” in het lab, maar geen degelijke brownout-afhandeling, safe boot of recovery heeft.

Niets hiervan is nieuw. Wat verandert door vibe coding is hoe makkelijk code met weinig begrip in de codebase belandt en daar blijft zolang het “meestal werkt”.

De menselijke factor: wantrouwen, overmatig vertrouwen en vaardigheidstekort

Zelfs op het hoogtepunt van de hype vertrouwden ontwikkelaars AI-output niet massaal. Uit de Stack Overflow-enquête van 2025 bleek ook dat meer ontwikkelaars AI niet vertrouwden dan wel, en slechts een klein deel had “veel” vertrouwen .

Het probleem is dat een laag vertrouwen niet automatisch leidt tot een zorgvuldige beoordeling. In de praktijk leidt het vaak tot “blijf gewoon vragen stellen totdat de tests positief zijn” wat kan leiden tot een oppervlakkige verificatie, vooral als de tests onvolledig zijn, ontbreken of zelf zijn gegenereerd op basis van het huidige gedrag.

Op lange termijn leidt dat tot technische- én vaardigheids-tekorten. Als code iets wordt wat je bestuurt in plaats van maakt, hou je minder mensen over die kunnen debuggen op hardware, edge-cases doorzien, systemen vereenvoudigen en het “saaie” werk van robuuste interfaces doen. Dat merk je pas als het systeem buiten het stukje werkelijkheid valt waar je tests op letten.

Regelgeving haalt zijn achterstand in: behandel AI als een onbetrouwbare medewerker

De praktische reactie die zich in de periode 2025-2026 aftekent, is ‘beleid + werkwijze’, geen verbod op het instrument AI. Het NIST SSDF communityprofiel voor generatieve AI is helder: alle broncode moet worden beoordeeld op kwetsbaarheden en andere issues voordat je het gebruikt, ongeacht of het door mensen of AI is geschreven .

Dat is de enige aanpak die schaalbaar is. De vraag is niet “heeft een model dit geschreven?”, maar “zou je dit van een externe bijdrager accepteren?”

Het minimale veiligheidsnet voor AI-teams

Als je wel de snelheid van AI wilt, maar niet de kater van vibe coding, heb je een harde ondergrens nodig. De tools verschillen, maar de principes zijn hetzelfde.

Houd verschillen beperkt. AI maakt het eenvoudig om grote wijzigingen door te voeren. Betrouwbaarheid vereist echter een andere aanpak. Maak gebruik van limieten voor pull-verzoeken, gefaseerde implementaties en feature flags.

Eis zinvolle tests. Unittests zijn niet genoeg als interfaces de pijnpunten zijn. Voeg contracttests, fuzzing (waar relevant) en regressietests toe die gekoppeld zijn aan incidenten.

Laat scanners standaard blokkeren. Statische analyse, geheime scanning, afhankelijkheids-scanning en container/IaC-scanning moeten standaard worden uitgevoerd, en “alleen waarschuwen” moet tijdelijk zijn.

Vergrendel afhankelijkheden en hou herkomst bij. Maak gebruik van lockfiles, vergrendelde versies, reproduceerbare builds, SBOM's en ondertekende artefacten. “Installeer gewoon het voorgestelde pakket” is geen werkwijze.

Beoordeel de intentie, niet de syntaxis. Vraag om een korte designnotitie of PR-beschrijving waarin staat waarom de wijziging bestaat, wat de risico’s zijn en hoe het getest is.

Meet productie goed uit. AI verschuift werk van code schrijven naar systemen debuggen. Observability is geen luxe: logs, metrics, tracing en expliciete SLO’s zijn nodig om snelheid te houden zonder chaos.

Dat is niet nieuw. Het punt is: AI vergroot de druk op die basics, omdat het de kosten van een wijziging verlaagt.

Juridische en nalevingskwesties: vragen over herkomst blijven bestaan

Vibe coding botst ook met compliance, omdat het herkomst vertroebelt: welke data hebben de output beïnvloed, welke licenties zijn van toepassing en wie is er verantwoordelijk voor het eindresultaat? Regelgevende instanties ondernemen actie, hoewel dit niet overal gelijkmatig gebeurt. De Europese Commissie publiceerde op 10 juli 2025 een General-Purpose AI Code of Practice als vrijwillig instrument om aanbieders te helpen aan de AI-wet te voldoen, die per 2 augustus 2025 geldt a>.

In het VK werd copyright en AI-training expliciet besproken als actueel beleidsprobleem; de consultatie liep van 17 december 2024 tot 25 februari 2025 .

De praktische les: als je organisatie licentie- of compliancebeperkingen heeft, omzeilt AI-code dat niet magisch. Behandel herkomst als een operationele eis, niet als een filosofisch vraagstuk voor later.

De echte les van 2025

2025 maakte software maken goedkoper. Het bezit van software werd niet goedkoper.

Teams die vibe coding in de prototype-fase hielden, kregen een enorme snelheidsboost. Teams die het in de productie lieten doorsijpelen, kregen te maken met een driedelige kater:

• Meer instabiliteit, want veranderingen gingen sneller dan release discipline a>.
• Meer veiligheidsrisico, want plausibele code is geen veilige code, en fouten in dependencies worden makkelijker op schaal geïntroduceerd. a>
• Meer vaagheid over verantwoordelijkheid, want vragen over herkomst, review en licenties komen later, meestal als er geld op het spel staat.

Natuurlijk is dit geen pleidooi om AI-tools te laten staan. Het is een pleidooi voor de nuchtere aanpak: AI versnelt ontwikkeling, maar vervangt het niet.

Vragen of opmerkingen?

Heeft u vragen of opmerkingen over dit artikel? Ik hoor graag uw ervaringen. U kunt mij schrijven via brian.williams@elektor.com of mij vinden op X via @briantw.

Noot van de redactie: dit artikel (230181-R-01) is verschenen in Elektor maart/april 2026.