AI-code review: wat het ziet en wat het mist

Voor wie? Developers en teams die AI-reviewers hebben ingezet of overwegen in te zetten, en willen weten wat ze daar realistisch van kunnen verwachten.

Kort: Een AI-reviewer ziet andere dingen dan een menselijke reviewer, niet betere of slechtere. Een goed reviewproces combineert beide lagen, maar vraagt dat je begrijpt wat elke reviewer bijdraagt. De workshop Werkwijze werkt dit uit aan de hand van concrete toolkeuzes en procesafspraken.

Je hebt CodeRabbit of een GitHub Copilot review-integratie aangezet. De eerste pull request levert commentaar op: een hardcoded string, een functienaam die afwijkt van de codebase, een ontbrekende null-check. Je accepteert de suggesties, mergt de PR.

De tweede PR is een refactor van de domeinlogica. Je hebt een businessregel aangepast die bepaalt wanneer een order als geverifieerd geldt. De AI-reviewer meldt stijlkwesties en naamgeving. De kern van de wijziging—of deze businessregel met het werkelijke proces klopt—wordt niet aangeraakt.

Dat is geen fout van de tool. Dat is precies wat je moet begrijpen voor je het proces inricht.

Wat AI-reviewers wel zien

AI-reviewers zijn getraind op grote hoeveelheden publieke code. Dat geeft ze een sterk signaal op alles wat terugkomt in die trainingsdata: stijlinconsistenties, bekende beveiligingspatronen, afwijkingen van gangbare conventies.

Concreet: een hardcoded secret in een configuratiebestand, een SQL-query die user input zonder escaping verwerkt, een functienaam die niet aansluit bij wat de functie doet, een test die de happy path afdekt maar edge cases overslaat. Dit zijn patroonherkenningsproblemen; AI-reviewers zijn goed daarin.

Ze zien ook afwijkingen binnen de diff zelf: een variabele die 2 keer gedeclareerd wordt, een return statement dat onbereikbaar is, een exception die gecatcht maar niet gelogd wordt. Dingen die je zelf ook ziet als je van dichtbij kijkt, maar die je mist onder tijdsdruk.

Het directe gevolg: repetitieve commentaren—stijlkwesties, voor de hand liggende fouten, naamgevingsproblemen—worden automatisch gevlagd voordat menselijke reviewers eraan beginnen. Dat is de waarde.

Wat AI-reviewers niet zien

De grenzen van een AI-reviewer zijn de grenzen van zijn trainingsdata en zijn contextvenster.

Domeinlogica. Een AI-reviewer ziet of de code syntactisch correct is en of het patroon gangbaar is. Hij ziet niet of de businessregel die je implementeert klopt met hoe het proces in jouw organisatie werkt. Een order die als geverifieerd geldt als de betaling ontvangen is — of als de betaling geboekt is? Dat onderscheid zit niet in de code, dat zit in kennis over het domein. Een menselijke reviewer die dat domein kent, ziet het direct.

Architectuurimplicaties. Een wijziging die nu logisch lijkt, kan een patroon introduceren dat over 6 maanden problemen geeft. Die beoordeling vraagt context buiten de diff: systeemopbouw, richting, impliciete teamafspraken. AI-reviewers hebben die context niet.

Context buiten de diff. Waarom deze opbouw? Welke technische schuld is bewust geaccepteerd? Een AI-reviewer ziet de wijziging, niet de beslisgeschiedenis. Een menselijke reviewer die bij de oorspronkelijke keuze betrokken was, plaatst de wijziging in dat licht.

Bewuste afwijkingen. Een codebase met architectuurkeuzes die bewust van gangbare patronen afwijken zal AI-reviewers commentaar opleveren dat je kunt negeren. Als je een ander foutafhandelingspatroon gebruikt, zal de reviewer dat consequent flaggen. Stel je tool in op je eigen codebase, of geef hem expliciet context.

Een reviewproces dat beide gebruikt

Het praktische model is een 2-passes aanpak.

Eerste pass: AI. Laat de AI-reviewer de diff scannen voordat menselijke reviewers eraan beginnen. Stijl, bekende patronen, voor de hand liggende fouten: dat is al afgehandeld. Je menselijke reviewers hoeven geen tijd te besteden aan vergeten puntkomma’s of testcases die al bestaan.

Tweede pass: developer. Concentreer de menselijke review op wat AI niet kan beoordelen. Klopt de domeinlogica? Past deze wijziging in de architectuurrichting die het team heeft gekozen? Is er context buiten de diff die de beoordeling verandert? Dit zijn de vragen die echte beoordelingscapaciteit vragen — en dat is schaars.

De beslisregel voor AI-commentaar: als de reviewer een juiste vraag stelt—“is dit de juiste naam in jouw domein?”—beantwoord hem zelf. Als de reviewer een fout aanwijst die je erkent, fix hem zonder extra ronde.

Het veiligheidsaspect

AI-reviewers detecteren bekende beveiligingspatronen goed: hardcoded credentials, onveilige deserialisatie, user-input in queries. Dit zijn patroonherkenningsproblemen en worden systematisch gevlagd.

De grens ligt bij bekende patronen. Een kwetsbaarheid specifiek voor jouw domein, datamodel of externe integraties ligt buiten trainingsdata. Een zero-day is per definitie nog niet in trainingsdata.

Gebruik AI-review als eerste laag voor beveiligingsproblemen. Vervang er geen security review door voor kritieke systemen.

Teamafspraken

Een AI-reviewer zonder procesafspraken leidt tot 2 fouten: klakkeloos accepteren of systematisch negeren. Beide verspillen waarde.

Leg vast welke categorieën automatisch gaan: stijl, formatting, naamgeving. En welke menselijke beoordeling vragen. Dat onderscheid maakt de eerste pass efficiënt en spaart review-tijd.

De meest gemaakte fout is AI-review gebruiken als vervanging van peer review voor complexe wijzigingen. De tweede fout is peer review gebruiken voor stijlcontroles die een tool in seconden afhandelt. Beide verspillen menselijke capaciteit.

De workshop Werkwijze werkt dit soort procesafspraken uit aan de hand van concrete toolkeuzes en echte codebase-context — geen theorie, maar een werkwijze die je direct kunt inzetten.