Un coding agent può aprire una pull request più velocemente di quanto un team riesca a valutarla. Il problema del CTO diventa allora scegliere quanto lavoro avviare, quali prove chiedere e dove leggere il codice con più attenzione. Approvare più in fretta, da solo, non risolve nulla.
Il mio punto di osservazione è quello di un founder che continua a occuparsi di software e infrastrutture. In Romiltec una modifica può riguardare una schermata, un’importazione editoriale o l’isolamento dei dati tra clienti. Trattarle tutte allo stesso modo rende la review lenta sulle prime e superficiale sulle ultime.
Prima del diff: qual è la conseguenza di un errore?
Per orientare la revisione parto da quattro domande: quali dati cambiano, chi può accedervi, quali sistemi esterni vengono coinvolti e quanto costa tornare indietro. Il numero di righe è un indizio di complessità, non una misura del rischio.
Una condizione di autorizzazione cambiata in una riga merita una lettura precisa. Una modifica estesa a file generati può richiedere soprattutto il controllo della sorgente e del comando che li ha prodotti. Una migrazione di database richiede attenzione anche al tempo di esecuzione, ai lock e alla compatibilità con la versione dell’app ancora attiva.
| Modifica | Dove concentro la review | Prova che chiedo |
|---|---|---|
| Testi o presentazione | Comportamento visibile e accessibilità | Pagina effettiva nei casi interessati |
| Logica applicativa | Regole di dominio e casi negativi | Esempi con esito noto prima del codice |
| Permessi e multi-tenancy | Percorsi di accesso, query e contesto | Tentativi tra utenti e tenant diversi |
| Database e integrazioni | Transazioni, retry, compatibilità | Fallimento parziale e recupero |
La specifica riduce le ambiguità, non sostituisce la review
Una richiesta come “ottimizza l’importazione” lascia troppe decisioni implicite. Preferisco specificare cosa non deve cambiare: un articolo già importato non viene duplicato, un errore su un elemento non perde lo stato degli altri, una nuova esecuzione riparte da un punto definito.
Questo lavoro aiuta sia una persona sia un agente. Il vantaggio è poter discutere di comportamento invece di interpretare a posteriori il diff. Ho sviluppato l’esempio più delicato nell’articolo sulla specifica di un’applicazione Laravel multi-tenant.
Una specifica resta però un documento: può essere incompleta e il codice può implementarla male. Per approvare devo ricostruire il percorso che porta dall’ingresso al risultato, soprattutto dove si autorizzano operazioni o si modificano dati.
Un test verde può verificare l’errore sbagliato
Se lo stesso agente scrive implementazione e test, può trasferire la stessa assunzione errata in entrambi. Il test passa perché conferma quello che il codice fa; nessuno ha ancora dimostrato che fosse quello richiesto.
Prendo un esempio: un job di fatturazione ritenta dopo un timeout. Un test che controlla soltanto la creazione della fattura nel caso normale è utile, ma non risponde alla domanda decisiva: cosa accade se il servizio esterno ha già accettato la richiesta e la risposta si perde?
Prima di generare il test definisco un risultato indipendente: il secondo tentativo deve riconoscere la stessa operazione, senza crearne un’altra. Poi verifico che il test attraversi davvero quel percorso, senza un mock che elimini proprio la condizione da osservare.
Pull request piccole e lavoro in corso limitato
La velocità degli agenti invita ad aprire molti task insieme. Il limite utile, però, è la capacità del team di integrarli e verificarli. Se due interventi cambiano lo stesso contratto, il costo della riconciliazione arriva comunque, anche quando non c’è un conflitto Git.
Per questo separerei un refactor meccanico da una modifica di comportamento. Una pull request deve avere uno scopo spiegabile e una validazione corrispondente. Le indicazioni di Google sulle modifiche piccole sono un buon riferimento: semplificano revisione e ragionamento sul singolo cambiamento.
Se la coda delle review cresce, riduco i lavori avviati o assegno un revisore competente. Accumulare codice non ancora verificato non equivale a consegnare software.
Cosa automatizzo e cosa tengo nella discussione
Formattazione, analisi statica e convenzioni ripetitive dovrebbero produrre un esito riproducibile. Il tempo della review serve meglio a discutere dipendenze, responsabilità, gestione degli errori e comprensibilità del sistema.
La guida di Google alla code review include design, funzionalità, complessità e test. Sono aspetti che restano rilevanti qualunque sia l’autore materiale del codice. Un secondo agente può cercare difetti, ma la sua approvazione non trasferisce la responsabilità del rilascio.
La review serve anche a far crescere il team. Spiegare perché un retry è pericoloso o perché una query supera il confine di un tenant vale più di correggere il difetto in silenzio. L’esperienza di chi ha già visto questi problemi diventa utile quando è condivisa, non quando rende una sola persona indispensabile.
La misura che mi interessa dopo il merge
Per valutare il metodo osserverei il tempo fino alla consegna, i difetti sfuggiti, i rollback e il lavoro necessario per correggerli. Separerei il tempo risparmiato a scrivere da quello speso a verificare e mantenere. Senza questa distinzione, una settimana di produzione rapida può nascondere un mese di correzioni.
Il compito del CTO rimane rendere comprensibili le decisioni tecniche e sostenibili le loro conseguenze. Gli agenti cambiano il ritmo della scrittura. La qualità del lavoro si vede quando il software affronta utenti, dati e guasti reali.