Code review vereist nu een andere houding. Wanneer het grootste deel van de code in een pull request was geschreven door diegene die het indient, was de taak van de reviewer fouten ondervangen en kennis delen. Wanneer veel ervan door een model is gegenereerd, moet de reviewer ook verifiëren dat de auteur daadwerkelijk begrijpt wat zij samenvoegen.
Waarom de aard van het probleem is veranderd
AI-modellen produceren code die syntactisch schoon, goed opgemaakt en op het eerste gezicht vaak plausibel is. Het oppervlak ziet er afgewerkt uit. Bugs, als ze er zijn, bevinden zich doorgaans in logica, edge cases of integratieaannames in plaats van in duidelijke syntaxfouten. Dat betekent dat de visuele signalen waarop reviewers vroeger vertrouwden, rommelige opmaak, ongebruikelijke patronen, duidelijk copy-paste, minder bruikbaar zijn. Iets kan er correct uitzien en toch fout zijn op manieren die ertoe doen.
Er is ook een volumeprobleem. Engineers die AI-tools gebruiken, kunnen meer code sneller produceren. Pull requests worden groter en komen vaker binnen. 800 regels code reviewen die één persoon in twee dagen heeft geschreven, is anders dan 800 regels reviewen die een model in twintig minuten heeft geproduceerd, omdat er in het tweede geval minder garantie is dat de auteur er allemaal doorheen is gegaan.
Waar reviewers nu op letten
De praktische verandering is dat reviewers steeds vaker controleren op begrip bij de auteur, niet alleen op correctheid van de code. Nuttige vragen tijdens review zijn nu:
- Kan de auteur een specifiek blok uitleggen als ernaar gevraagd wordt?
- Weerspiegelt de testcoverage begrip van de edge cases, of alleen happy paths?
- Zijn er patronen die eruit zien alsof ze zonder aanpassing van het model zijn overgenomen?
- Is de foutafhandeling zinvol voor dit systeem, of is het generieke boilerplate?
Dit is geen bewering dat AI-gegenereerde code gemiddeld slechter is. Het is een bewering dat het risicoprofiel anders is, en dat reviewprocessen die zijn gebouwd voor door mensen geschreven code de foutmodi van door modellen gegenereerde code niet automatisch ondervangen.
Voor meer over waar je op moet letten bij het werken met code die je zelf niet hebt geschreven, zie hoe je AI-gegenereerde code reviewt en software testen die je niet zelf hebt ontworpen.
Technische schuld stapelt zich anders op
Bij mensgeschreven code bouwt technische schuld zich meestal geleidelijk op. Er worden shortcuts genomen onder tijdsdruk; degene die dat deed weet over het algemeen waar de lijken begraven liggen. Bij AI-gegenereerde code die zonder volledig begrip is geaccepteerd, kan de schuld structureel solide lijken terwijl de onderliggende aannames onjuist zijn. Later refactoren is moeilijker omdat niemand in het team een helder beeld heeft van waarom de code zo is geschreven.
Dit speelt vooral in codebases waar meerdere engineers los van elkaar AI-tools gebruiken en code mergen die de anderen niet goed hebben gelezen. Het gezamenlijke effect kan een codebase zijn die moeilijk te doorgronden is: geen enkel bestand hoeft slecht te zijn, en toch is het mentale model van hoe alles in elkaar zit nooit goed opgebouwd.
Wat niet veranderd is
Het doel van review is nog steeds hetzelfde: gedeeld begrip van wat er in productie staat en vertrouwen dat het zich correct gedraagt. De manier om dat doel te bereiken is verschoven. Auteurs vragen om de logica mondeling toe te lichten, uitleg eisen bij niet-voor-de-hand-liggende ontwerpbeslissingen, en bewuster omgaan met testkwaliteit zijn allemaal praktijken die al goed waren en nu nog belangrijker zijn.
Sommige teams reageren door ook AI-tooling toe te voegen aan de reviewkant, waarbij modellen potentiële problemen signaleren vóór de menselijke review. Dat kan ruis verminderen, maar het neemt de behoefte aan een menselijke reviewer die het systeem begrijpt niet weg.
Waar we op testen
Beide sessies in hoe we vetten zijn hier direct relevant. Sessie 1 stelt vast of een engineer echte problemen kan vinden zonder hulpmiddelen, via gestructureerd debuggen en echte technische kennis van de stack. Sessie 2 test dezelfde instincten onder andere omstandigheden: of ze gehallusineerde API's of subtiel foutieve logica in gegenereerde output onderscheppen voordat die live gaat, en of ze een wijziging kunnen uitleggen die ze zelf niet hebben getypt. Engineers die AI output verificatie als optioneel beschouwen, maken van code review al snel een formaliteit in plaats van iets nuttigs.
Korte antwoorden
Is AI-gegenereerde code moeilijker te reviewen dan mensgeschreven code?
Het is anders om te reviewen, niet per se moeilijker qua volume. De oppervlakte is vaak netjes, wat logische fouten of onjuiste aannames kan maskeren. De grootste uitdaging is dat reviewers niet meer kunnen aannemen dat de auteur elke ingediende regel volledig begrijpt.
Betekent snellere codegeneratie meer technische schuld?
Dat kan, als de reviewpraktijken niet meegroeien. Wanneer code wordt gegenereerd en geaccepteerd zonder dat de auteur er doorheen heeft gelopen, stapelt het team aannames op die niemand heeft geverifieerd. Dat levert schuld op die moeilijker te vinden en op te lossen is dan de soort die bewust onder tijdsdruk is opgebouwd.
Moeten teams AI-tools toevoegen aan het reviewproces zelf?
Het kan helpen bij oppervlakkige controles, maar het vervangt niet een reviewer die het systeem begrijpt. Geautomatiseerde review vangt een aantal problemen op; het verifieert niet dat de auteur begreep wat hij of zij mergede, of dat het ontwerp past binnen de bredere codebase.
