Forse non dovremmo più revisionare tutto il codice

A Meta le “significant lines of code per human-landed diff” sarebbero cresciute del 106% in un anno. La domanda è diretta: ha senso provare a revisionare tutto quel codice? [S1]

L’innesco è un confronto pubblico. L’autrice racconta un dibattito con Brian Houck (DX) al panel Code Remix, ospitato da Moderne. Martin Fowler osserva che i panel funzionano quando c’è disaccordo, e qui c’era. Entrambi avevano argomenti solidi su fronti opposti. [S1]

Houck ha poi scritto “What are code reviews even for?”. L’autrice risponde con una tesi chiara: l’AI produce più codice di quanto gli umani possano realisticamente revisionare. Ma il punto, scrive, potrebbe non essere che l’AI “rompe” la code review. Forse stiamo usando la code review per obiettivi che non è progettata per raggiungere. [S1]

La discussione parte dai numeri citati da Houck. Se i diff “atterrati” per persona crescono così, il volume cambia. La revisione manuale incontra un limite umano. In questo contesto, l’autrice interroga lo scopo della pratica: cosa vogliamo ottenere quando chiediamo una review? La domanda guida il resto del pezzo. [S1]

C’è un accordo di fondo. L’autrice scrive che lei e Houck “vogliono le stesse cose”. Divergono sul mezzo. Lei non considera la code review il modo migliore per raggiungere quegli obiettivi, soprattutto quando il codice aumenta per effetto dell’AI. È una presa di posizione, non un rifiuto della pratica in sé. [S1]

Il titolo lo dice senza giri di parole: “Maybe We Shouldn’t Be Reviewing All This Code”. L’argomento non minimizza il valore della revisione, ma rimette al centro il nesso tra strumento e fine. Se la review serve a ottenere certi risultati, conviene chiederle proprio quelli. Se le chiediamo altro, rischiamo di confonderne il ruolo. [S1]

Il pezzo nasce anche da una dinamica personale e professionale trasparente. L’autrice racconta che il disaccordo ha reso il panel più interessante. Dice che Houck è stato incoraggiante e che l’ha spinta a scrivere. Aggiunge una nota di onestà: vuole convincere chi legge. Il tono è netto, ma la cornice resta di confronto. [S1]

La posta in gioco è pratica. Se l’AI fa aumentare il codice, i team devono chiarire cosa chiedono alla review. Questo non è un dettaglio di processo: orienta come si usano tempo e attenzione. Spinge a distinguere tra obiettivi e abitudini. E a verificare se le pratiche in uso corrispondono davvero ai risultati attesi. [S1]

La chiusura non è un verdetto su “review sì o no”. È un cambio di domanda. Non se l’AI rende inutile la review, ma se stiamo tentando di risolvere con la review problemi diversi da quelli per cui è nata. La conseguenza è concreta: definire meglio lo scopo prima di definire il volume. In un anno in cui i numeri crescono, è una scelta che incide più delle preferenze di stile. [S1]