Er is meer aan code review dan (automatiseerbare) detectie

De samenvatting van het artikel “The End of Code Review: Coding Agents Supersede Human Inspection” schetst het volgende beeld voor de lezer:

Abstract – Code review is sinds dat Fagan in 1976 code-inspectie formaliseerde de primaire kwaliteitscontrole in softwareontwikkeling geweest. Vijf decennia lang is het een hoeksteenpraktijk voor organisaties van elke omvang geweest dat een mens de wijzigingen van een collega bekijkt en becommentarieert voordat deze worden samengevoegd (merged). Codeer-agenten zijn autonome systemen op basis van grote taalmodellen (LLM's) die in staat zijn software te lezen, schrijven, testen en repareren. Wij stellen dat codeer-agenten een drempel van bekwaamheid hebben overschreden waarbij traditionele menselijke code review niet langer een noodzakelijk onderdeel is van een softwarekwaliteitslijn. Ons argument rust op twee claims: elk gesteld doel van code review kan door agenten worden bediend tegen lagere kosten en met een hogere doorvoersnelheid; de naïeve integratie waarbij agenten code schrijven en mensen de verplichte reviewers blijven, is een doodlopende weg omdat het noch betekenisvolle zekerheid biedt, noch schaalt met de AI-ondersteunde doorvoersnelheid.

Het artikel is goed gestructureerd en vrij eenvoudig voor engineers die niet gewend zijn aan het lezen van wetenschappelijke artikelen. Ik denk echter dat het argument kritisch afhankelijk is van een problematische inkadering: de substitutiemythe.

De auteur splitst peer code review op in vier gestelde functies: defectdetectie, handhaving van stijl, kennisoverdracht en bewustwording. Er wordt betoogd dat een agent elk van deze functies kan uitvoeren. De conclusie is uiteraard dat als een agent elk van deze functies kan uitvoeren, de agent in staat is om een menselijke reviewer te vervangen.

Ik denk dat dit enkele belangrijke aspecten van peer code review over het hoofd ziet die niet gereduceerd kunnen worden tot een functie:

De verwarring van een peer-reviewer

Wanneer een ervaren engineer een diff leest en zegt: "Ik begrijp dit niet", dan is die verwarring de bevinding. Het betekent dat de code te complex is, de abstractie onjuist is of de intentie onduidelijk is. Een LLM zal de code altijd 'begrijpen' in de zin dat het in staat is deze te verwerken. Het kan je niet het signaal geven van legitieme menselijke onbegrijpelijkheid. Het artikel behandelt begrijpelijkheid alsof het meer over stijl gaat dan over iets anders. Dat is niet zo. Het is een emergente eigenschap en het manifesteert zich in de interactie tussen een persoon die probeert het artefact te begrijpen en het artefact zelf.

Gekwalificeerd scepticisme over de noodzaak van de wijziging

Het in twijfel trekken van het bestaan van een wijziging, zoals:

• "Zouden dit eigenlijk twee PR's moeten zijn?"
• "Dit lost het symptoom op, niet het probleem."

Dit zijn vragen over de intentie, de reikwijdte en de gepastheid van de wijziging. Al dit komt vóór de vraag of de code "correct" is. De inkadering van het artikel gaat ervan uit dat a) de code-wijziging die wordt beoordeeld noodzakelijk is, en b) het hoofddoel van de review verificatie is.

Iedereen die ooit contact heeft gehad met een productieomgeving, begrijpt echter dat code review vaak het laatste (of soms enige) moment is waarop iemand wordt geacht uit te dagen of de wijziging überhaupt wel nodig is.

Het vermogen om te zien wat er niet staat

Een menselijke reviewer kan opmerken dat een API-contract is gewijzigd, maar de foutafhandeling niet. Ze kunnen opmerken wat er mist. Met andere woorden: in staat zijn te herkennen wat er verwacht wordt, maar niet aanwezig is. Het artikel erkent dit helemaal niet, wat bijzonder interessant is, aangezien "blindheid voor afwezigheid" precies de klasse van fouten is waar LLM's vaak slecht in zijn.

De agent reviewt wat er is; engineers met expertise kunnen gemakkelijk opmerken wat er ontbreekt.

De invloed van de auteur op de mate van controle

Peer code reviewers hebben een soort gekalibreerde aandacht die voortkomt uit ervaring met de auteur van de code, die vaak een collega is. Bijvoorbeeld: de eerste commit van een minder ervaren engineer naar een betalingsmodule zal waarschijnlijk een andere aandacht krijgen dan de routineuze refactoring van een veteraan of 'grey beard' engineer.

Reviewers stemmen de 'wie, wat, wanneer en waar' van de situatie doorgaans af op hun eigen ervaring met waar de risico's liggen. Het artikel lijkt alle diffs als gelijkwaardige inputs te behandelen.

Code review is bidirectioneel en constructief

Het lijkt me dat het artikel kennisoverdracht reduceert tot louter informatieoverdracht; de agent 'genereert simpelweg uitleg'. Maar discussie in een code review is een gezamenlijke cognitieve activiteit. De peer-reviewer leert over de aanpak van de auteur, de auteur leert via de vragen van de reviewers, en het resultaat is een gedeeld begrip dat geen van beide partijen vóór de discussie had.

Dit is coactief werk, geen eenvoudige transmissie. Een samenvatting van een agent is geen vervanging voor een gesprek dat de mentale modellen van beide deelnemers verandert.

Operationele context buiten de repositories

• "We hadden afgelopen dinsdag net een incident in deze service."
• "Het team dat deze downstream-consument beheert, staat op het punt die interface te deprecaten."
• "Juridische zaken heeft ons verteld dit veld niet meer te loggen."

Menselijke reviewers beschikken over veel meer contextuele kennis dan ze zich bewust zijn, zelfs als ze verbindingen in de praktijk kunnen herkennen. Mensen begrijpen de huidige staat van de organisatie, recente gebeurtenissen en informele afspraken die niet zijn vastgelegd in tests, documentatie of versiebeheer, en ze kunnen herkennen hoe deze de te reviewen code kunnen beïnvloeden. Dit gebeurt zo vaak dat het bijna onzichtbaar is.

Het artikel gaat ervan uit dat de codebase de volledige context is. Dat is hij nooit.

Verantwoording voor de code is geen bureaucratische formaliteit

Het artikel behandelt menselijke verantwoordelijkheid als een compliance-artefact, een "genoemde mens" voor juridische of andere regelgevende doeleinden. Maar het besef dat je persoonlijk verantwoordelijk bent voor het goedkeuren van een wijziging, beïnvloedt de manier waarop je deze reviewt. Het is de "skin in the game". Een agent die een pull request "ondertekent", draagt geen consequenties en heeft zeker geen prikkelstructuur die een zorgvuldige evaluatie stimuleert. Hoewel het artikel ethische zorgen meeneemt in de discussiesectie, wordt dit uiteindelijk omgebogen naar "requirements engineering en monitoring na implementatie", wat mij lijkt op een manier om het probleem voor zich uit te schuiven.

***

Het meest fundamentele probleem dat ik heb met het artikel, is dat het ervan uitgaat dat code review in de eerste plaats een detectieproces is: je vindt defecten, stijlovertredingen, beveiligingsproblemen, etc., en de aanname is dat het sneller en goedkoper detecteren hiervan universeel beter is.

Maar code review is ook een coördinatieproces, een betekenisgevingsproces (sensemaking) en een bestuursproces (governance).

De substitutiemythe speelt zich vaak op dezelfde manier af:

1. De menselijke bijdrage aan het werk wordt ontleed in meetbare functies.
2. Er wordt aangetoond dat de machine deze menselijke bijdrage kan repliceren in eigen meetbare functies.
3. De mens wordt als overbodig verklaard.

Deze benadering loopt vaak op hetzelfde punt vast: de menselijke bijdrage die het meest telde, was de integratie over de functies heen. Het vermogen van mensen om zich aan te passen aan ongeplande omstandigheden en contexten, en om de verwachte sociale verantwoordelijkheid te dragen.

Dit vermogen om zich in die situaties aan te passen, is niet meegerekend in de oorspronkelijke ontledingsstap #1, hierboven.

Ik denk dat ze dat in het oorspronkelijke artikel ook niet hebben meegenomen.