Rachel Laycock, CTO di Thoughtworks, pubblica una risposta su martinfowler.com il 2 settembre 2026 all'edizione Engineering Enablement firmata da Brian Houck un mese prima. I due autori si sono scontrati pubblicamente durante un panel Code Remix ospitato da Moderne, e Houck l'ha incoraggiata a scrivere questo articolo. Il disaccordo è circoscritto fin dall'inizio: vogliono la stessa cosa, lei semplicemente non pensa che la code review sia il modo migliore per ottenerla.
Lei accetta la diagnosi. L'IA produce più codice di quanto gli umani possano ragionevolmente revisionare, e le cifre di Houck — un aumento del 106% delle righe significative per diff in Meta, una dimensione mediana delle pull request del 64% su DX — sono accettate senza riserve. Condivide anche la sua preoccupazione: automatizzare la revisione rischia di far perdere tutto il resto, poiché la revisione non è mai servita solo a trovare bug. La sua domanda si colloca altrove: perché aspettare la revisione per fare tutto questo?
automatizzare la cerimonia piuttosto che interrogarsi sul perché la cerimonia esista
Non le è mai piaciuto vedere la pull request al centro del processo. Costruire qualcosa, finirlo, impacchettarlo, lanciarlo oltre la recinzione, e solo dopo avere la conversazione importante su se ciò che è stato costruito sia corretto, le appare come un ordine invertito. Il principio che contrappone è uno imparato presto in Thoughtworks: se il feedback ha valore, non eliminarlo, ma spostalo più vicino alla decisione che informa.
Segue una riassegnazione sistematica. L'esplorazione delle alternative avviene prima di implementarne una. Il trasferimento di conoscenza avviene tramite il pairing, che insegna più della lettura di una soluzione finita. L'apprendimento dei junior richiede di lavorare insieme ai senior mentre questi pensano. L'ownership collettiva nasce dall'organizzazione del team, dal mob programming e dalle sessioni di design alla lavagna. L'allineamento architetturale emerge dal design condiviso, poi dalle fitness functions. Formattazione, linting, problemi di sicurezza noti, e tutto ciò che è deterministico vengono automatizzati.
Ciò che resta è la revisione basata sulle eccezioni: un cambiamento architetturale fondamentale, un confine di sicurezza sensibile, un ampio blast radius, un'area non familiare di un sistema critico, o un team che dichiara di mancare di confidenza. Questo è diverso dal richiedere l'ispezione di ogni cambiamento in nome della cerimonia. Respinge anche l'agente IA che imiterebbe il revisore umano: ciò automatizza la cerimonia invece di interrogarsi sulla sua ragione di esistere.
Concede un punto: il debito cognitivo e di intenzione descritto da Houck è un problema reale. Ma la PR obbligatoria è una difesa debole contro di esso. Ciò che serve è design collaborativo, pairing, buoni confini, architettura eseguibile e responsabilità operativa condivisa — perché gli ingegneri devono comprendere i sistemi, non i diff.