De code komt sneller, het lek reist gewoon mee

Een developer zet in een weekend een complete SaaS in elkaar. Nauwelijks frameworkkennis, geen serieuze security-achtergrond, geen code review. De app draait, de demo oogt strak en iedereen voelt die typische opwinding van iets dat ineens snel af is. Pas daarna blijkt wat niemand echt heeft gecontroleerd: de API-sleutels liggen open op internet.

Daar zit de paradox van vibe coding in 2026. Het is nog nooit zo makkelijk geweest om software snel te shippen. Het is ook nog nooit zo makkelijk geweest om tegelijk kwetsbaarheden mee te shippen.

Wat werkt, is nog lang niet wat veilig is

De scherpste cijfers komen van Veracode. Daar werden meer dan 100 grote taalmodellen getest op 80 realistische programmeertaken. De uitkomst was hard: 45% van de AI-gegenereerde code zakte voor securitytests en bracht kwetsbaarheden uit de OWASP Top 10 rechtstreeks richting productie. Java was de slechtste categorie, met meer dan 70% failrate. Python, C# en JavaScript zaten tussen 38% en 45%.

Wat dit extra ongemakkelijk maakt, is het contrast met bruikbaarheid. Twee jaar geleden werkte minder dan 20% van zulke codevoorbeelden überhaupt. Inmiddels compileert ongeveer 90% bij de eerste poging. Modellen zijn dus veel beter geworden in code schrijven die ogenschijnlijk af is. Maar op security is die vooruitgang nauwelijks zichtbaar. Dat is ook de kern van de samenvatting bij Help Net Security van het Veracode-rapport: modellen worden beter in correct coderen, niet in veilig coderen.

Meer modelgrootte lost dat niet automatisch op. Nieuwere LLMs blijken niet merkbaar veiliger te schrijven dan kleinere voorgangers.

Elke extra prompt maakt de basis een beetje brozer

Dat is precies waar veel teams zichzelf onderschatten. Eerst maak je een basisversie. Daarna vraag je om nog een kleine aanpassing. Dan nog een feature. Dan permissies, randgevallen, een koppeling, een nette uitzondering. Het voelt als normaal itereren, maar het systeem wordt er aantoonbaar riskanter van. Volgens Kaspersky bevatte code na vijf prompt-iteraties al 37% meer kritieke kwetsbaarheden dan de eerste generatie. In de testset leverden featuregerichte prompts 158 nieuwe kwetsbaarheden op, waarvan 29 kritiek.

De logica daarachter is vrij nuchter. Elke iteratie voegt complexiteit toe zonder dat het model een echt architectuurbeeld heeft. Het optimaliseert voor “werkt dit nu”, niet voor “blijft het systeem als geheel veilig en logisch”. Zo ontstaan risico's die lijken op beveiligingslekken in AI-agentinfrastructuur: losse onderdelen lijken verdedigbaar, maar samen maken ze het systeem zwakker.

Dat is ook waarom snelheid misleidend kan zijn. Het product voelt rijker, terwijl de fundering juist slechter wordt.

Het gevaar zit vaak niet meer in de klassieke fouten

Een interessante nuance komt uit een onderzoek van december 2025, opgepakt door CSO Online op basis van Tenzai. Vijf grote codingtools, waaronder Claude Code, Codex, Cursor, Replit en Devin, werden getest door met elk drie identieke applicaties te bouwen. Over die 15 applicaties werden 69 kwetsbaarheden gevonden.

Opvallend genoeg draaide het niet vooral om klassieke SQL injection of cross-site scripting. Die bekende patronen zijn zo vaak beschreven dat modellen ze deels hebben afgeleerd. Het echte risico zat in businesslogicafouten.

Een checkout waar gebruikers zelf hun prijs kunnen invullen. Een API-endpoint dat client-side autorisatie vertrouwt. Een systeem dat technisch klopt, maar functioneel op de verkeerde plek vertrouwt. Dat zijn precies de gaten die bedrijven zonder echte verdediging tegen AI-exploits vaak missen, omdat je daarvoor context en bedoeling moet begrijpen, niet alleen syntax.

81% sneller kan later een dure grap blijken

Dat AI je op korte termijn sneller laat voelen, is niet verzonnen. Alleen zegt dat weinig over de totale rekening. InfoQ beschreef op basis van Ox Security AI-code als hoog functioneel maar structureel zwak in architectonisch oordeel. In 80% tot 90% van de onderzochte projecten doken steeds dezelfde anti-patronen op: te veel comments, refactors die worden vermeden, overspecificatie en bugs die steeds terugkomen.

Analist Ana Bildea noemde dat exponentiële technische schuld. Gewone tech debt bouwt lineair op. AI-tech debt stapelt zich samen. Eerst lijkt de velocity omhoog te schieten. Daarna slokken patches, herbouw en incident response de winst op. Dat lijkt sterk op AI-productiviteitswinst die later in herwerk verdwijnt.

De METR-studie uit het bronartikel laat dat gevoel scherp zien. Developers dachten 20% sneller te zijn, maar werden in echte codebases 19% trager gemeten. De snelheid voelt dus echt in het moment. De prijs komt alleen later.

De oplossing werkt, maar haalt de romantiek uit vibe coding

Daarmee kom je bij de minst populaire conclusie. Securitygericht prompten helpt wel degelijk. Volgens Kaspersky halveerde zelfs een algemene instructie over secure coding best practices de kwetsbaarheidsratio. Nog specifiekere beveiligingsinstructies per taal hielpen verder.

Alleen botst dat precies met de aantrekkingskracht van vibe coding. “Bouw een betaalsysteem” is makkelijk. “Bouw een betaalsysteem met server-side autorisatie, inputsanitatie, rate limiting en OWASP-richtlijnen” vraagt ongeveer dezelfde concentratie als het probleem zelf goed begrijpen.

Daarom doen teams die dit verstandig aanpakken iets minder magisch en veel effectiever. Zij behandelen AI-code als een eerste versie, niet als eindproduct. Dat lijkt op de reden waarom de meeste bedrijven AI wel gebruiken maar er nauwelijks echt aan verdienen: de tool versnelt, maar oordeel en verantwoordelijkheid blijven menselijk.

Vibe coding shipt snel. De serieuze vraag is alleen of je later ook nog kunt betalen voor wat er vandaag zo soepel is gebouwd.