Waarom AI-gegenereerde code zo moeilijk te reviewen is

Je ontwikkelteam gebruikt Copilot, Cursor, Claude Code of een van de vele andere AI-tools. De productiviteit lijkt omhoog te schieten: meer features, meer pull requests, kortere doorlooptijden. Volgens onderzoek van DX over meer dan 400 bedrijven wordt intussen ongeveer de helft van alle nieuwe code door AI geschreven.

Maar er is een stap in het proces die niet is meegegroeid: de code review. Faros AI analyseerde de data van meer dan 10.000 ontwikkelaars en vond dat teams met hoge AI-adoptie 98% meer pull requests mergen, terwijl de tijd per review met 91% steeg. De flessenhals is verschoven van het schrijven van code naar het beoordelen ervan.

En dat is niet alleen een kwestie van volume. AI-gegenereerde code is om een aantal structurele redenen moeilijker te reviewen dan code van een menselijke collega. Dit artikel legt uit waarom, en wat je eraan kunt doen.

Code review is gebouwd op een aanname die niet meer klopt

Het klassieke reviewproces steunt op een stilzwijgende afspraak: de auteur begrijpt wat hij heeft geschreven. De reviewer hoeft niet elke regel te ontleden, want hij kan vragen stellen. "Waarom deze aanpak?" "Heb je aan het geval gedacht waarin de lijst leeg is?" De review is een gesprek tussen twee mensen die de code allebei kennen.

Met AI-gegenereerde code valt die aanname weg. De ontwikkelaar die de pull request opent, heeft de code vaak maar vluchtig gelezen. Hij kan de vraag "waarom?" niet beantwoorden, want hij heeft de beslissing niet genomen. De reviewer wordt zo de eerste persoon die de code écht leest. Dat is een fundamenteel andere, en veel zwaardere, taak.

Zes redenen waarom AI-code moeilijker te reviewen is

1. Het ziet er goed uit

AI-code is netjes geformatteerd, gebruikt duidelijke namen en bevat vaak commentaar. Precies de signalen die reviewers al jaren gebruiken als graadmeter voor zorgvuldigheid. Bij een menselijke auteur zegt een schone codestijl iets over de aandacht die eraan is besteed. Bij AI zegt het niets: de stijl is altijd schoon, ook als de logica fout is.

Dat effect is gemeten. Onderzoekers van Stanford lieten ontwikkelaars beveiligingsgevoelige taken uitvoeren met en zonder AI-assistent. De groep mét AI schreef minder veilige code, en was tegelijk meer overtuigd dat hun code veilig was. CodeRabbit analyseerde 470 open-source pull requests en vond in AI-geschreven code 1,7 keer zoveel problemen als in menselijke code, met 75% meer logica- en correctheidsfouten. Fouten die er op het eerste gezicht niet uitzien als fouten.

2. De pull requests worden groter en talrijker

AI schrijft meer regels dan een mens voor hetzelfde probleem. DX zag de mediane pull request in één jaar bijna verdubbelen, van 44 naar 72 regels. Salesforce rapporteerde gemiddelde pull requests van meer dan 1.000 regels en 20 bestanden. Uit onderzoek naar code review is al lang bekend dat de aandacht van reviewers boven de 400 regels sterk afneemt. Wat er daarna gebeurt, is geen review meer maar een formaliteit.

Tel daar het aantal pull requests bij op. Meer code, in grotere brokken, van dezelfde reviewers die er ook al voor de AI-golf te weinig tijd voor hadden.

3. Niemand kent het "waarom" meer

Addy Osmani noemt het comprehension debt: de groeiende kloof tussen hoeveel code er in je systeem zit en hoeveel ervan een mens werkelijk begrijpt. Anders dan klassieke technical debt kondigt die schuld zich niet aan met wrijving. De code werkt, tot iemand ze moet aanpassen.

Ook dat is gemeten. In een gerandomiseerd experiment van Anthropic leerden 52 ontwikkelaars een nieuwe library, de helft met AI-hulp. Beide groepen waren ongeveer even snel klaar, maar de AI-groep scoorde 17% lager op een begripstest over code die ze enkele minuten eerder zelf hadden ingediend. Het grootste verlies zat bij debugging. Uitgerekend de vaardigheid die je nodig hebt om AI-fouten te vinden.

Voor een reviewer betekent dit: de auteur is geen betrouwbare bron meer over zijn eigen wijziging. Elke vraag moet je zelf beantwoorden door de code te lezen.

4. De fouten zijn van een ander soort

Ervaren reviewers weten waar menselijke fouten zitten: een vergeten null-check, een off-by-one, een copy-paste die niet volledig is aangepast. AI maakt andere fouten, op andere plaatsen:

  • Plausibele maar verkeerde logica. Een bedrijfsregel die nét anders is geïmplementeerd dan bedoeld, in code die perfect compileert en waarvoor de tests (ook door AI geschreven) groen zijn.
  • Verzonnen afhankelijkheden. Een studie gepresenteerd op USENIX Security 2025 vond dat 19,7% van de packages die code-genererende modellen voorstellen niet bestaat. Aanvallers registreren die namen en vullen ze met malware, een techniek die "slopsquatting" heet. Een reviewer die niet elke nieuwe import controleert, ziet dit niet.
  • Verzwegen fouten. GitClear meet sinds 2023 een stijging van 47% in constructies die fouten wegslikken, zoals lege catch-blokken. De code faalt niet luid; ze faalt stil, in productie.
  • Beveiligingslekken. Veracode testte meer dan 100 modellen op 80 taken: in 45% van de gevallen bevatte de gegenereerde code een kwetsbaarheid uit de OWASP Top 10. Bij cross-site scripting faalde 86%. Opvallend: nieuwere en grotere modellen schrijven betere werkende code, maar niet veiligere code.

5. Elke wijziging klopt, het geheel niet

AI optimaliseert voor de prompt, niet voor het systeem. Het weet niet dat er al een helperfunctie bestaat die precies dit doet, dus schrijft het een nieuwe. Het kent de conventies van je team niet, dus kiest het zijn eigen. GitClear analyseerde 623 miljoen codewijzigingen en zag het aandeel gekopieerde code stijgen van 9,4% naar 15,7%, terwijl gerefactorde code daalde van 21% naar 3,8%. Ontwikkelaars kopiëren nu vijf keer vaker dan ze herstructureren.

Een review per pull request kan dit niet zien. Elke wijziging is op zichzelf verdedigbaar. Pas op het niveau van de hele codebase wordt zichtbaar dat er drie manieren zijn om hetzelfde te doen, dat de architectuur langzaam verwatert, en dat elke volgende wijziging daardoor duurder wordt.

6. Reviewers geven het op

Zet de vorige vijf punten samen en het resultaat is voorspelbaar. Meer pull requests, groter, zonder auteur die uitleg kan geven, met fouten op onverwachte plaatsen. Op een gegeven moment wordt het goedkeuren van de pull request een automatisme. CodeRabbit zag de reviewtijd van de grootste pull requests afvlakken: reviewers lezen niet meer, ze klikken door.

Het DORA-rapport van 2025 over AI-ondersteunde softwareontwikkeling bevestigt het effect op organisatieniveau: AI-adoptie verhoogt de doorvoer, maar heeft een negatief verband met de stabiliteit van software delivery. De waarschijnlijke oorzaak volgens de onderzoekers: code wordt sneller gegenereerd dan de review- en deploymentprocessen kunnen absorberen. Een studie van Uplevel bij bijna 800 ontwikkelaars vond 41% meer bugs in het werk van de groep met Copilot-toegang.

Wat dit betekent voor je bedrijf

Op korte termijn merk je weinig. Features komen sneller, het team is enthousiast, de demo's zien er goed uit. De rekening komt later, en ze komt sneller dan bij klassieke technical debt, omdat de code sneller wordt geschreven.

  • Bugs die in productie opduiken in plaats van in de review, met klanten als testers.
  • Beveiligingsincidenten via kwetsbaarheden of afhankelijkheden die niemand heeft gecontroleerd.
  • Een codebase die niemand in het team nog volledig begrijpt, waardoor elke wijziging riskanter wordt en nieuwe ontwikkelaars langer nodig hebben.
  • Duplicatie en architectuurdrift die je pas ziet als een "kleine aanpassing" ineens drie weken kost.

AI heeft code review niet minder belangrijk gemaakt. Het heeft van code review de laatste verdedigingslinie gemaakt, en tegelijk de flessenhals.

Wat je eraan kunt doen

Zes maatregelen die werken

  1. Houd pull requests klein, ongeacht wie of wat ze schreef. Een limiet van een paar honderd regels dwingt ontwikkelaars om AI-output op te splitsen in stukken die een mens nog kan beoordelen.
  2. De auteur moet elke regel kunnen uitleggen. Maak het een teamregel: wie een pull request opent, staat in voor de inhoud, ook als AI ze schreef. Vraag in de beschrijving om het "waarom", niet alleen het "wat".
  3. Review de tests apart. AI-gegenereerde tests testen vaak de implementatie in plaats van het gewenste gedrag. Groene tests bewijzen dan alleen dat de code doet wat ze doet.
  4. Automatiseer wat een machine kan vinden. Statische analyse, security scanning en een controle op nieuwe afhankelijkheden (bestaat dit package, wie onderhoudt het?) horen in de pipeline, zodat menselijke aandacht naar logica en ontwerp kan gaan.
  5. Gebruik een checklist. Bij AI-code werken gewoontes en intuïtie niet meer, want de fouten zitten op andere plaatsen. Een expliciete checklist dwingt de reviewer om te kijken waar hij anders niet kijkt.
  6. Bekijk regelmatig het geheel. Duplicatie, architectuurdrift en verwaterde conventies zijn onzichtbaar per pull request. Plan periodiek een review op codebase-niveau, door iemand die niet dagelijks in de code zit.

Weet je nog wat er in je codebase zit?

De eerlijke vraag voor elk team dat met AI werkt, is niet óf de code wordt gereviewd. Dat gebeurt meestal wel, op papier. De vraag is of die review nog iets vangt. En of er iemand is die het geheel nog overziet, nu de helft van de code niet meer door een mens is geschreven.

Als je daar niet zeker van bent, is een onafhankelijke source code audit de snelste manier om het te weten te komen. Niet om AI af te schaffen, maar om te meten wat de snelheidswinst je werkelijk heeft gekost, waar de risico's zitten, en welke van bovenstaande maatregelen bij jouw team het meeste opleveren.

Bronnen

Ontwikkelt je team met AI?
Laat ons meten wat dat je codebase heeft gekost.

Vrijblijvend gesprek?

Contacteer ons