# laycock-thoughtworks-reviewing-all-this-code-2026-09-02

## Veille

Post di **Rachel Laycock**, CTO di **Thoughtworks**, pubblicato il **2 settembre 2026** su *Rachel's Ramblings*, la sezione di martinfowler.com che dirige, circa **8.000 caratteri**. Il testo è una **risposta deliberata** a [[houck-dx-what-are-code-reviews-for-2026-08-05]], in seguito a un disaccordo pubblico tra i due autori durante un panel **Code Remix** ospitato da **Moderne**. Laycock accetta la diagnosi quantificata di Houck (+**106%** di righe per diff in **Meta**, +**64%** di dimensione mediana delle PR sul lato DX) e l'elenco delle funzioni della revisione che non riguardano l'individuazione di difetti, poi sposta la domanda: *« perché aspettiamo la code review per fare tutte queste cose? »* (A) Il principio guida è l'accorciamento dei cicli di feedback appreso in Thoughtworks — se il feedback ha valore, non eliminarlo, spostalo più vicino alla decisione che informa. Ogni funzione attribuita alla revisione viene riassegnata a monte: esplorazione delle alternative prima dell'implementazione, trasferimento di conoscenza tramite **pair programming**, ownership collettiva tramite **mob programming** e sessioni di design in team, allineamento architetturale tramite design condiviso seguito da **fitness functions**, e automazione di tutto ciò che è deterministico — *« Non dovremmo più discutere di spazi bianchi nel 2026. »* (B) La revisione basata sulle eccezioni sostituisce la revisione sistematica: un cambiamento architetturale fondamentale, un confine di sicurezza sensibile, un ampio blast radius, un'area non familiare di un sistema critico, o semplicemente una mancanza di confidenza dichiarata da un team. (1) L'automazione della revisione tramite un agente che imita il revisore umano viene respinta come *« automatizzare la cerimonia piuttosto che interrogarsi sul perché la cerimonia esista »*. (2) Il debito cognitivo di Houck viene riconosciuto come reale, ma la PR obbligatoria viene giudicata una difesa debole: *« Abbiamo bisogno che gli ingegneri comprendano i sistemi, non i diff. »*

## Titre Article

Maybe We Shouldn't Be Reviewing All This Code

## Date

2026-09-02

## URL

https://martinfowler.com/rachels-ramblings/code-review.html

## Keywords

code review, revisione basata sulle eccezioni, pull request, ciclo di feedback breve, spostare il giudizio a monte, shift left, pair programming, mob programming, sessione di design in team, trunk-based development, fitness functions, architettura evolutiva, analisi statica, test automatizzati, scansione di sicurezza, cerimonia, collo di bottiglia, blast radius, confine di sicurezza, debito cognitivo, debito di intenzione, ownership collettiva, trasferimento di conoscenza, comprendere i sistemi, non i diff, Thoughtworks, Code Remix, Moderne

## Authors

Rachel Laycock, CTO de Thoughtworks, sur *Rachel's Ramblings* (martinfowler.com).

## Ton

Profilo: post di risposta breve firmato da una dirigente tecnica, voce in prima persona interamente assunta, registro argomentativo e personale, livello tecnico medio, pubblico target di leader dell'ingegneria e praticanti agile. Il testo si annuncia come tale già dall'apertura — il panel, il disaccordo, l'invito dell'altro autore a scrivere la risposta — e stabilisce i suoi termini di cortesia prima di attaccare: accordo sui fatti, accordo sugli obiettivi, disaccordo sui mezzi. *« Penso che vogliamo per lo più le stesse cose. Semplicemente non penso che la code review sia il modo migliore per ottenerle. »* La concessione è esplicita e raddoppiata dall'umorismo (*« Brian è adorabile, comunque »*, *« Ma mentirei se dicessi che non voglio che alla fine pensiate che ho ragione :) »*), così come l'ammissione di una posizione mantenuta da tempo: l'autrice non ha mai apprezzato la pull request al centro del processo, e lo dichiara con una digressione deliberata sui merge conflict. La costruzione è una confutazione punto per punto che riprende l'elenco del suo opponente e lo riassegna, con una cifra ripetuta fino all'autoironia (*« Non mi ripeterò sul pairing e sulle sessioni di design in team, ah no aspetta... »*). La riserva è collocata dove le spetta, senza enfasi: il debito cognitivo e di intenzione viene concesso come *« un problema molto reale »*, solo il rimedio viene contestato. Citabile tale e quale: *« Se il feedback ha valore, non eliminarlo. Spostalo più vicino alla decisione che informa »*; *« Abbiamo bisogno che gli ingegneri comprendano i sistemi, non i diff »*; *« automatizzare la cerimonia invece di interrogarsi sul perché la cerimonia esista »*; e la frase di chiusura, *« forse la domanda non è come far revisionare il codice più rapidamente. Forse è perché aspettiamo la code review per avere fin dall'inizio tutte le conversazioni importanti. »*

## Pense-betes

- **Il disaccordo riguarda i mezzi, non il fine.** Laycock accetta le cifre e l'elenco di Houck — la revisione serve anche alla condivisione della conoscenza, alla formazione dei junior, all'ownership collettiva e alla diffusione della comprensione architetturale — e non ne conclude che la revisione debba essere preservata, ma che si debba smettere di aspettare la revisione per fare tutto questo. La tesi si basa su un'inversione temporale, non su una contestazione dei dati.
- **Il principio importato: accorciare il ciclo, non eliminare il feedback.** *« Se il feedback ha valore, non eliminarlo. Spostalo più vicino alla decisione che informa. »* Tabella di riassegnazione funzione per funzione: esplorazione delle alternative → prima dell'implementazione, non dopo; trasferimento di conoscenza → **pair programming**, perché ragionare insieme a qualcuno insegna più della lettura della sua soluzione finita; apprendimento dei junior → lavorare con i senior *mentre* pensano; ownership collettiva → organizzazione del team, **mob programming**, sessioni di design alla lavagna; allineamento architetturale → design condiviso seguito da **fitness functions** che codificano i vincoli; formattazione, linting, problemi di sicurezza noti, e tutto ciò che è testabile in modo deterministico → automazione.
- **La « revisione basata sulle eccezioni » è il meccanismo di uscita proposto**, ed è esplicitamente circoscritta: un cambiamento architetturale fondamentale (eventualmente revisionato in team dopo una sessione di design), l'attraversamento di un confine di sicurezza sensibile, un cambiamento con un ampio blast radius, una parte non familiare di un sistema critico, o un team che dichiara di mancare di confidenza. La distinzione è tra *« esattamente i punti in cui il giudizio umano ha valore »* e il richiedere l'ispezione umana di ogni cambiamento in nome della cerimonia storica di produzione della confidenza.
- ⚠️ **L'argomento anti-collo di bottiglia è indipendente da quello pedagogico** e si sostiene da solo: se un agente produce dieci volte più codice ma ogni riga finisce comunque in coda davanti a un ingegnere senior, non si è costruita un'organizzazione dieci volte più rapida — si è costruito un backlog e un nuovo collo di bottiglia. È lo stesso meccanismo del costo del cambiamento accettato in [[staples-gitlab-when-code-is-abundant-2026-08-24]]: eliminare un vincolo espone il successivo.
- **La revisione IA che imita il revisore umano viene esplicitamente respinta** — non perché funzionerebbe male, ma perché preserva un processo la cui ragione di esistere non è stata riesaminata: *« Questo automatizza la cerimonia invece di interrogarsi sul perché la cerimonia esista. »* Nota per la pratica: questa riserva riguarda la sostituzione uno a uno, non gli agenti che partecipano ai cicli a monte, che il testo accetta (contestare i design, testare le ipotesi, verifica continua), pur mantenendo che il pensiero provenga da umani esperti.
- **Cosa viene concesso e cosa viene respinto**: il debito cognitivo e di intenzione viene definito un *« problema molto reale »*; ciò che viene contestato è la PR obbligatoria come difesa contro di esso. La controproposta non è un singolo meccanismo ma un elenco — design collaborativo, pairing, buoni confini, architettura eseguibile, responsabilità operativa condivisa — accompagnato dall'ammissione che probabilmente saranno necessarie pratiche non ancora inventate.
- **La diagnosi di fondo, da mantenere al di fuori del dibattito**: anni passati ad accumulare un numero straordinario di responsabilità sulla code review — gate di qualità, controllo di sicurezza, revisione architetturale, meccanismo di mentoring, sistema di condivisione della conoscenza, modello di ownership. Questo ha tenuto solo finché gli umani potevano produrre codice a una certa velocità; è questo vincolo che sta scomparendo, e con esso l'intera pila.
- **Correlati**: [[monperrus-end-of-code-review-agents-supersede-2026-06-11]] (la stessa conclusione sull'ispezione umana, raggiunta tramite l'automazione piuttosto che lo shift left) e [[boeckeler-harness-engineering-coding-agents-2026-04-02]] (strumenti di verifica a monte, anch'essi di Thoughtworks).

## RésuméDe400mots

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?

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.

## GrapheDeConnaissance

- Rachel Laycock —a_créé→ Maybe We Shouldn't Be Reviewing All This Code (DOCUMENT, 0.97)
- Rachel Laycock —dirige→ Thoughtworks (ORGANISATION, 0.95)
- Maybe We Shouldn't Be Reviewing All This Code —s_oppose_à→ What are code reviews even for? (DOCUMENT, 0.96)
- Rachel Laycock —affirme_que→ le problème n'est pas que l'IA ait cassé la revue de code, mais qu'on utilisait la revue pour résoudre les mauvais problèmes (AFFIRMATION, 0.95)
- boucle de rétroaction courte —recommande→ ne pas supprimer un retour de valeur, mais le rapprocher de la décision qu'il informe (CITATION, 0.94)
- pair programming —remplace→ revue de code (METHODOLOGIE, 0.92)
- pair programming —surpasse→ la lecture d'une solution achevée pour apprendre le raisonnement d'un ingénieur expérimenté (AFFIRMATION, 0.91)
- mob programming —permet→ propriété collective par construction, au lieu d'une notification de l'équipe après coup (AFFIRMATION, 0.89)
- session de design d'équipe —permet→ explorer les alternatives avant l'implémentation plutôt qu'après (CONCEPT, 0.91)
- fitness functions —permet→ encoder les contraintes architecturales importantes après un design commun (CONCEPT, 0.92)
- analyse statique —s_applique_à→ formatage, linting, problèmes de sécurité connus et tout ce qui est testable déterministiquement (CONCEPT, 0.92)
- revue par exception —s_applique_à→ changement architectural fondamental, frontière de sécurité sensible, large rayon d'impact, zone inconnue d'un système critique, inconfiance déclarée de l'équipe (CONCEPT, 0.94)
- revue par exception —s_oppose_à→ exiger l'inspection humaine de chaque changement au titre de la cérémonie historique de production de confiance (AFFIRMATION, 0.93)
- Rachel Laycock —prédit→ un agent produisant dix fois plus de code devant une file de revue senior ne crée pas une organisation dix fois plus rapide mais un backlog et un nouveau goulot (AFFIRMATION, 0.93)
- revue de code par agent imitant le relecteur humain —s_oppose_à→ interroger la raison d'être de la cérémonie plutôt que l'automatiser à l'identique (CITATION, 0.92)
- agents IA —permet→ participer aux boucles amont en contestant des designs, testant des hypothèses et vérifiant en continu, la pensée restant humaine (AFFIRMATION, 0.88)
- Rachel Laycock —soutient→ la dette cognitive et d'intention est un problème réel (AFFIRMATION, 0.92)
- pull request —réduit→ faiblement la dette cognitive et d'intention lorsqu'elle est rendue obligatoire, contre l'usage qui lui est prêté (AFFIRMATION, 0.9)
- Rachel Laycock —affirme_que→ il faut que les ingénieurs comprennent des systèmes, pas des diffs (CITATION, 0.95)
- revue de code —est_instance_de→ empilement de responsabilités (CONCEPT, 0.93)
- abondance du code générée par l'IA —s_oppose_à→ la contrainte de vitesse humaine qui rendait cet empilement tenable (AFFIRMATION, 0.9)
- Code Remix —observé_dans→ le désaccord public entre Rachel Laycock et Brian Houck, à l'origine du billet (AFFIRMATION, 0.9)
- Moderne —publie→ Code Remix (EVENEMENT, 0.88)
- Rachel Laycock —recommande→ maintenir la compréhension humaine par design collaboratif, pairing, bonnes frontières, architecture exécutable et responsabilité opérationnelle partagée (AFFIRMATION, 0.92)

---
Canonical: https://www.thekb.eu/it/fiches/laycock-thoughtworks-reviewing-all-this-code-2026-09-02/