AI-gegenereerde code in 2026: vertrouwen, kwetsbaarheden en het governance-gat

Vraag een engineering director of AI-gegenereerde code veilig is om te releasen, en het eerlijke antwoord is: "hangt af of je reviewproces is meegeschaald met het volume." Geen comfortabel antwoord, maar wel het antwoord dat de data van 2025-2026 ondersteunt. Adoptie is niet langer de vraag - AI-ondersteund programmeren is inmiddels de standaard bij de meeste engineeringorganisaties. De vraag die de uitkomst echt bepaalt, is wat er gebeurt tussen genereren en mergen, en op die vraag is het bewijs specifiek genoeg om op te handelen.

Close-up van broncode op een computerscherm, ter illustratie van AI-gegenereerde code die op menselijke review wacht — Foto: Sai Kiran Anagani, CC0, via Wikimedia Commons

Is AI-gegenereerde code eigenlijk veilig om te releasen?

Niet standaard. Veracode's 2025 GenAI Code Security Report, gepubliceerd op 30 juli 2025, testte meer dan 100 large language models op 80 zorgvuldig samengestelde codeertaken en vond dat gegenereerde code in 45% van de gevallen een beveiligingskwetsbaarheid introduceerde - dus wanneer een model kon kiezen tussen een veilige en een onveilige manier om iets te schrijven, koos het bijna de helft van de tijd voor het onveilige pad. Het faalpercentage was niet gelijk verdeeld: Java-code faalde beveiligingscontroles in 72% van de taken, het hoogste van alle geteste talen, terwijl verdediging tegen cross-site scripting in 86% van de relevante voorbeelden faalde. Modelgrootte en recentheid losten dit niet op - nieuwere, grotere modellen lieten geen wezenlijke verbetering in beveiliging zien ten opzichte van oudere modellen, ondanks dat ze functioneel betere code schreven. De conclusie voor een platform- of securityverantwoordelijke is bot: functionele correctheid en veilig-by-default gedrag zijn losse eigenschappen, en AI-modellen zijn geoptimaliseerd voor de eerste.

Waarom vertrouwen engineers AI-gegenereerde code nog steeds niet, ondanks stijgende adoptie?

Omdat de vertrouwenskloof rationeel is, geen kwestie van culturele weerstand. DORA's onderzoek uit 2025, samengevat in "Balancing AI tensions" en gebaseerd op ongeveer 1.110 open antwoorden van engineers verzameld in Q3 2025, vond dat 90% van de professionals nu AI gebruikt op het werk en meer dan 80% een productiviteitswinst rapporteert - maar toch geeft 30% nog steeds weinig tot geen vertrouwen aan in de code die AI voor hen produceert. DORA duidt dit als een structurele asymmetrie, geen generatiekwestie: de auteur van een AI-gegenereerde wijziging kan suggesties interactief accepteren of afwijzen tijdens het schrijven, maar de reviewer erft een afgeronde diff zonder die context en moet de intentie helemaal opnieuw reconstrueren. Een engineer, geciteerd in het onderzoek, verwoordde het treffend: "Andermans code reviewen is zoveel moeilijker dan zelf schrijven. AI-tools verhogen het tempo waarin mensen code kunnen produceren die vervolgens gereviewd moet worden." De veelgeciteerde framing van het rapport is dat AI "de grote versterker" is - het verbetert de discipline van een team niet, het vergroot wat er al is, goed of slecht.

Houdt code review het volume aan AI-gegenereerde pull requests eigenlijk bij?

Het duidelijkste bewijs zegt van niet. GitHub's Octoverse 2025-rapport (gepubliceerd op 28 oktober 2025) registreerde dat de Copilot coding agent alleen al meer dan 1 miljoen pull requests schreef tussen mei en september 2025, tegenover een platformbreed gemiddelde van 43,2 miljoen gemergede pull requests per maand, een stijging van 23% jaar-op-jaar. De reviewactiviteit schaalde niet mee: comments op pull requests en issues bleven vrijwel gelijk (+0,35%), terwijl comments op commits - de meer gedetailleerde, regel-voor-regel feedback die subtiele bugs opvangt - met 27% daalden. GitHub benadrukt terecht dat dit "observationele signalen zijn, geen causale claims", maar de richting komt overeen met wat DORA en Veracode onafhankelijk van elkaar beschrijven: er stroomt meer code door de pipeline, en de diepgang van menselijke controle per wijziging groeit niet mee. Die combinatie - een basiskwetsbaarheidspercentage van 45% in gegenereerde code, een vertrouwenstekort bij reviewers, en afnemende review-diepgang per commit - is precies de opzet die het patroon van "hoge doorlooptijd, dalende stabiliteit" oplevert dat DORA nu twee opeenvolgende jaarrapporten op rij heeft gemeten.

Wat vereist AI-codegovernance eigenlijk in 2026?

Geen verbod, en geen schouderophalen. Drie zaken die je al terugziet bij volwassen engineeringorganisaties:

Risico-geschaalde review, geen uniforme review. Behandel AI-geschreven diffs zoals je een pull request van een capabele maar ongetoetste junior engineer zou behandelen: inspecteer de diff, draai de tests, controleer edge cases, en eis een tweede goedkeuring bij alles wat authenticatie, betalingen, dataToegang of infrastructure-as-code raakt. Laagrisico, goed geteste interne tooling hoeft niet dezelfde lat te halen als een wijziging aan een klantgerichte API.
Securityscanning in de loop, niet erna. Met een basiskwetsbaarheidspercentage van 45% en een faalpercentage van 72% in een van de meest gebruikte enterprise-talen, moeten statische analyse en dependency-scanning draaien op elke AI-ondersteunde wijziging vóór de merge, niet als periodieke audit. Behandel AI-output als niet-vertrouwde input voor je bestaande supply chain-controles - dezelfde houding die gereguleerde teams al toepassen op third-party dependencies.
Een inventaris van waar AI daadwerkelijk wordt gebruikt. Je kunt niet sturen op wat je niet ziet. Weten welke repositories, welke agents, en welke secrets en codepaden blootgesteld zijn aan AI-tooling is de voorwaarde voor elk beleid dat daarop volgt - goedgekeurde tools, beperkte use cases, en regels voor wat een agent onbeheerd mag aanraken.

Niets hiervan is exotisch. Het is dezelfde discipline die DORA al een decennium documenteert - snelle feedback, kleine batches, geautomatiseerde controles vóór de merge - toegepast op een nieuwe bron van verandering. De organisaties die DORA als sterke performers classificeert, zijn niet de organisaties die AI vermijden; het zijn de organisaties waarvan de bestaande review- en testdiscipline sterk genoeg was om een twintigvoudige toename in het tempo waarmee code om review vraagt, op te vangen.

De praktische lat voor 2026

Als jouw team AI-codeassistenten of agents heeft geadopteerd zonder ook opnieuw te bekijken wie de output reviewt, op welke diepte, en met welke securitytooling vóór de mergeknop - dan draai je precies de configuratie waarvan de data zegt dat die meer doorlooptijd en minder stabiliteit oplevert. De oplossing is niet AI-adoptie afremmen. Het is ervoor zorgen dat reviewcapaciteit, securityscanning en een accurate inventaris van waar AI je codebase raakt, in hetzelfde tempo meegroeien als de pull requests.