Het reviewen van AI-gegenereerde code volgt dezelfde principes als het reviewen van gewone code, maar bepaalde faalpatronen komen vaker voor en vereisen bewuste aandacht. Zelfverzekerde, aannemelijk uitziende fouten zijn frequenter; de taak van de reviewer is om te vertragen waar menselijke reviewers instinctief versnellen.
Waarom AI-gegenereerde code makkelijker te accorderen voelt
AI-gegenereerde code is doorgaans goed opgemaakt, consistent benoemd en voorzien van inline commentaar. Die oppervlakkige kwaliteit kan de waakzaamheid van een reviewer verlagen. De code leest alsof een competent persoon hem heeft geschreven, wat druk creëert om snel te accorderen. Die druk is het eerste dat je moet weerstaan.
Het onderliggende probleem is dat een taalmodel optimaliseert voor aannemelijkheid, niet voor correctheid. Het heeft geen belang bij de uitkomst. Het kan de code niet uitvoeren voordat het hem voorstelt, en het weet niet wat er vorige week dinsdag in je codebase is veranderd.
Wat er verandert in de review
Neem minder aan over de bedoeling. Als een collega een functie schrijft, kun je vragen waarom ze een bepaalde keuze hebben gemaakt. AI-gegenereerde code heeft geen auteur om op aan te spreken. Als de bedoeling niet duidelijk is uit de code en de context, is dat een leemte die je moet opvullen vóór je accordeert, niet erna.
Controleer de raakvlakken. AI-tools werken met een contextvenster. Ze zien alleen wat hen is meegegeven, niets meer. Fouten concentreren zich op de grenzen: waar de gegenereerde code aansluit op de rest van het systeem, waar types worden aangenomen in plaats van geïmporteerd, waar een API-aanroep overeenkomt met de trainingsdata van het model in plaats van de versie die je daadwerkelijk gebruikt. Zie wat is een contextvenster voor meer over deze beperking.
Wees extra kritisch op tests. Modellen genereren tests die slagen op de code die ze net zelf hebben geschreven. Dat is niet hetzelfde als tests die een regressie zouden opvangen. Controleer of de tests het gedrag testen dat jou interesseert, of dat ze simpelweg bevestigen dat de functie iets teruggeeft.
Let op gehallucineerde afhankelijkheden. Modellen verwijzen soms naar libraries, methoden of configuratiesleutels die niet bestaan, of die bestaan in een andere versie dan je gebruikt. Een snelle controle van imports en versies van afhankelijkheden kost weinig. Het probleem ontdekken in productie kost veel meer.
Lees foutafhandeling aandachtig. Door AI gegenereerde foutafhandeling is doorgaans generiek. Stille catches, kale except-blokken, fouten die worden weggeschreven naar een logregel die niemand bekijkt. Deze passeren een vluchtige review omdat ze eruitzien als foutafhandeling. Lees elk geval en vraag jezelf af wat er feitelijk gebeurt als dit pad wordt gevolgd.
Wat niet verandert
De standaard reviewchecklist geldt nog steeds: correctheid, beveiliging, performance, leesbaarheid, testdekking, aansluiting op de bestaande architectuur. AI-generatie maakt deze overwegingen niet minder relevant. Het verandert waar fouten zich verbergen, niet of ze bestaan.
Beveiligingsreview mag in het bijzonder niet worden ingekort. Prompt injection is één categorie van risico's specifiek voor AI-ondersteunde systemen, maar de bredere set aandachtspunten, injection, onveilige standaardinstellingen, onjuiste toegangscontrole, geldt voor door AI gegenereerde code net zo goed als voor andere code.
Praktische gewoontes
- Lees de diff als code, niet als samenvatting. Weersta de neiging om er snel overheen te gaan omdat het er netjes uitziet.
- Als een blok lang is, splits de review dan op in rondes: één voor de logica, één voor de foutafhandeling, één voor de tests.
- Als iets ingewikkelder lijkt dan nodig is, is dat een reden voor een tweede blik. Modellen produceren soms overgecompliceerde oplossingen.
- Noteer waar door AI gegenereerde code problemen veroorzaakte. Patronen worden snel zichtbaar en geven richting aan wat je de volgende keer controleert.
Voor een breder beeld van hoe code review-praktijken veranderen, zie wat er veranderd is aan code review.
Waar we op testen
Het reviewen van AI-gegenereerde code is een van de vaardigheden die we tijdens de selectie direct beoordelen. In het AI-native assessment scoren we verificatie van AI-output expliciet. Kan de engineer verzonnen API's, subtiel foute logica of beveiligingslekken in gegenereerde code opsporen voordat die live gaat, in plaats van erop te vertrouwen omdat het compileert? Risicogericht oordeelsvermogen scoren we over beide assessments, omdat agents een tekstwijziging en een betalingsmigratie even snel en met dezelfde stelligheid opleveren. Hoe beide assessments verlopen, lees je op hoe we selecteren.
Korte antwoorden
Verschilt het reviewen van door AI gegenereerde code fundamenteel van het reviewen van door mensen geschreven code?
De principes zijn hetzelfde, maar de foutpatronen verschuiven. Door AI gegenereerde code ziet er doorgaans netter uit dan ze is, fouten concentreren zich op contextgrenzen, en tests bevestigen vaak alleen wat het model net heeft geschreven in plaats van toekomstige regressies op te vangen.
Moet door AI gegenereerde code als zodanig worden gemarkeerd in een pull request?
Veel teams vinden dit nuttig, omdat het reviewers aanzet de specifieke controles toe te passen die ertoe doen. Het helpt ook bij het bijhouden van waar problemen vandaan komen. Er is nog geen universele standaard, maar transparantie verbetert de reviewkwaliteit doorgaans.
Hoe review je door AI gegenereerde tests effectief?
Controleer of elke test het gedrag test dat de codebase daadwerkelijk moet beschermen, niet alleen of de test slaagt. Modellen schrijven tests die hun eigen output bevestigen. Vraag welke regressie de test zou opvangen, niet alleen of hij nu slaagt.
