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. »*
#code review#revisione basata sulle eccezioni#pull request
Rachel Laycock · CTO de Thoughtworks · sur *Rachel's Ramblings* (martinfowler.com).
Numero della newsletter **Engineering Enablement** di **DX** firmato da **Brian Houck**, pubblicato il **5 agosto 2026**, circa **13.000 caratteri**. Il testo si apre con un'osservazione quantificata: in **Meta**, le righe significative per diff unite da un umano sono aumentate del **106%** in un anno e i diff per sviluppatore al mese del **51%**, con più dell'**80%** di questa crescita attribuibile all'IA agentica, mentre la quota di diff revisionati entro 24 ore diminuisce; l'analisi di DX misura invece una dimensione mediana delle pull request in aumento del **64%**, mentre gli sviluppatori vorrebbero dedicare circa il **7%** del loro tempo alla revisione. (A) Prima di affidare la revisione all'IA, Houck riformula la questione dell'uso: *"Quale problema risolveva la revisione del codice prima dell'arrivo dell'IA?"* Se la risposta è l'individuazione dei difetti, l'automazione completa diventa inevitabile; lo studio **Bacchelli & Bird** (*Modern Code Review*, ICSE 2013) mostra che i commenti relativi ai difetti rappresentano solo il **14%** dei commenti effettivamente scritti. (B) Parte dell'onere è *autoimposto*: lo studio Microsoft del 2016 su **911 sviluppatori** aveva già individuato il tempo di turnaround, la dimensione della revisione e la comprensione della motivazione del cambiamento come i primi tre ostacoli, e solo il **26%** scriveva ancora una descrizione dettagliata. (1) **RADAR** in Meta costituisce il dispiegamento di riferimento per la stratificazione del rischio. (2) Tre mosse ordinate: correggere le fondamenta, progettare l'IA attorno al giudizio umano, proteggere ciò che la revisione produce in modo invisibile. Il corpus include già [[monperrus-end-of-code-review-agents-supersede-2026-06-11]], che spinge l'automazione fino alla sostituzione, e [[laycock-thoughtworks-reviewing-all-this-code-2026-09-02]], la risposta diretta a questo testo.
#code review#code review#coda di revisione
Brian Houck · signataire de l'édition · sur la newsletter Engineering Enablement de DX ; fonction non affichée par la page.
Un saggio di Jean-Paul Paoli (*The Intelligence Fabric*) che sposta la paura dell'IA sul lavoro: il vero pericolo non è la **sostituzione** (il posto che scompare) ma lo **sfilacciamento silenzioso** dei legami di squadra mentre *tutti restano occupati*. Tesi: quando ogni dipendente fa dell'IA il proprio **primo confidente e collaboratore**, tre "fili" del tessuto organizzativo si disfano senza licenziamenti — i **legami tra pari** (il trasferimento di conoscenza tacita da junior a senior cortocircuitato), il **legame manager-dipendente** (i segnali di allarme precoce scompaiono, il manager diventa "l'ultimo a sapere invece del primo") e il **giudizio professionale** (le persone smettono di formare chi sa *fare* il lavoro e valutare se la macchina sbaglia). Paoli chiama il fenomeno **shadow intimacy** (per analogia con lo *Shadow IT*) e prescrive non un divieto ma una "ritessitura" deliberata, filo per filo. Ambito: management, trasformazione organizzativa, IA sul lavoro, dipendenza emotiva dai modelli.
#Shadow intimacy#sostituzione IA#legami di squadra