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 rest van de codebase, een ontbrekende null-check. Nuttig. 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 een stijlkwestie en een variabelenaam. De kern van de wijziging — klopt deze businessregel met hoe het proces werkelijk werkt? — 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 de edge case die logisch volgt uit de implementatie overslaat. Dit zijn patroonherkenningsproblemen — en AI-reviewers zijn goed in patroonherkenning.

Ze zien ook afwijkingen binnen de diff zelf: een variabele die twee 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 even van dichtbij kijkt, maar die je mist als je haast hebt of de context al kent.

Het directe gevolg: 80% van de repetitieve reviewcommentaren — de stijlkwesties, de voor de hand liggende fouten, de naamgevingsproblemen — wordt automatisch gevlagd voor je menselijke reviewers er naar kijken. 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 zes maanden problemen geeft bij schaal of bij een volgende feature. Die beoordeling vraagt context buiten de diff: hoe is de rest van het systeem opgebouwd, waar gaan we naartoe, wat zijn de impliciete afspraken die dit team al gemaakt heeft? AI-reviewers hebben die context niet.

Context buiten de diff. Waarom is deze code zo gebouwd? Wat was de tijdsdruk? Welke technische schuld is hier bewust geaccepteerd? Een AI-reviewer ziet de wijziging, niet de beslisgeschiedenis. Een menselijke reviewer die bij de oorspronkelijke keuze betrokken was, beoordeelt de wijziging in dat licht.

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

Een reviewproces dat beide gebruikt

Het praktische model is een twee-passes aanpak.

Eerste pass: AI. Laat de AI-reviewer de diff scannen voor je menselijke reviewers er naar kijken. Stijl, bekende patronen, voor de hand liggende fouten — dat is opgelost voor de menselijke review begint. Je menselijke reviewers hoeven geen tijd te besteden aan een vergeten puntkomma of een testcase die al in de code stond.

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 de juiste vraag stelt maar het antwoord niet weet — “is dit de juiste naam voor dit concept in jullie domein?” — beantwoord dan de vraag zelf. Als de reviewer een fout aanwijst die je direct herkent, fix hem zonder extra review-ronde.

Het veiligheidsaspect

AI-reviewers detecteren bekende beveiligingspatronen goed. Hardcoded credentials, onveilige deserialisatie, directe user-input in queries — dit zijn patroonherkenningsproblemen, en ze worden systematisch gevlagd.

De grens: bekende patronen, niet onbekende. Een kwetsbaarheid die specifiek is voor jouw domein, jouw datamodel, of jouw integratie met een extern systeem, ligt buiten de trainingsdata. En een zero-day is per definitie nog niet in trainingsdata opgenomen.

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 twee fouten: klakkeloos accepteren, of systematisch negeren. Beide verspillen de waarde van de tool.

Leg vast welke categorieën commentaar automatisch worden afgehandeld — stijl, formatting, naamgeving volgens de codebase-conventie — en welke menselijke beoordeling vragen. Dat onderscheid maakt de eerste pass efficiënt en voorkomt dat reviewers tijd besteden aan vragen die de tool al heeft opgelost.

De meest gemaakte fout is AI-review inzetten als vervanging van peer review voor complexe wijzigingen. De op één na meest gemaakte fout is peer review inzetten voor stijlcontroles die een tool in tien seconden afhandelt. Beide zijn een slechte besteding van menselijke aandacht.

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.