Venerdì 26 giugno 2026, 8:47, scrivania di Calcinaia. Dieci finestre di Claude Code aperte sul monitor sinistro, una per task: tre sul refactor del modulo di ingestione articoli dell’Application Service, due su un fix di routing tenant-aware in WordPress lato plugin, una sul nuovo connettore di stilometria, una sul revamp dei dashboard Grafana, due su un piccolo servizio interno di matching, e l’ultima dedicata al dev senior che è in onboarding sul nuovo workflow e che mi sta facendo domande in chat. Sul monitor destro, la finestra di review dei diff, ordinata per età. Nessun file aperto in editor. Ne apro forse uno al giorno, di mia mano, e quasi sempre per leggere, non per scrivere.
Per dodici anni, dal 2011 al 2023, ho fatto un altro mestiere: rileggere ogni pull request di tre, quattro, fino a otto sviluppatori, riga per riga, perché il mio nome era CTO e la mia firma morale era sul codice di produzione. Nel 2026 quel mestiere è morto, almeno nella forma in cui lo conoscevo. Non perché io abbia smesso di essere responsabile della tecnologia di Romiltec: continuo a esserlo. Perché lo strumento sotto le mie mani è cambiato, e con lo strumento è cambiato il mestiere.
Il problema: la review da novanta minuti che saturava la giornata
Fino a fine 2025 il mio rituale era stabile. Caffè alle 8:30, apertura della board GitHub, lettura ordinata delle pull request aperte dei dev senior. Ogni patch passata sotto i miei occhi, riga per riga: nome di variabile, naming di metodo, choice di astrazione, copertura di test, side effect non documentati, query N+1 nascoste in un eager load mal scritto, race condition latenti in un job Horizon. La review media durava 90 minuti al giorno, distribuiti su tre slot. In una settimana erano sette ore e mezza, quasi una giornata intera, dedicate a leggere codice scritto da altri.
Per dodici anni quel rituale è stato la mia forma di responsabilità tecnica. Ed era utile: trovavo bug veri, riallineavo astrazioni che stavano divergendo, correggevo nomi di variabile che sarebbero diventati debito tre mesi dopo. La fatica era reale, ma il segnale era reale.
Da inizio 2026 il rituale ha smesso di funzionare. Non perché i bug siano spariti. Perché il rapporto tra righe di codice prodotte al giorno e tempo umano disponibile per leggerle si è rotto. Cinque persone con coding agent attivi in parallelo producono in una giornata quello che nel 2024 produceva il team intero in una settimana. Se continuavo a leggere tutto riga per riga, la review diventava il collo di bottiglia: l’agente terminava un task in venti minuti, io ci mettevo due ore a guardare il diff, e nel frattempo l’altro agente aveva completato il task successivo. Non si scala così.
Il primo riflesso, come immagino chiunque abbia il mio ruolo, è stato di stringere i denti e leggere più velocemente. Non funziona. La review riga per riga ha un costo cognitivo che non si comprime: o la fai bene, o non la stai facendo. La seconda tentazione è stata di rallentare gli agenti, dare meno task in parallelo, restare nel rapporto vecchio fra produzione e revisione. Funziona, ma butta via il valore del nuovo strumento. La terza, quella scomoda, è stata accettare che il mestiere fosse cambiato e ridisegnarlo.
Cosa ho smesso di fare
La review line-by-line dei diff dei senior. Apro il pull request, leggo il titolo, leggo il messaggio di commit, scorro il diff in modalità aggregata (la vista che ti dà solo le sezioni cambiate, non i file singoli), guardo se ci sono file che mi insospettiscono per posizione (un cambio dentro app/Services/Tenancy/ mi accende sempre, un cambio dentro tests/ quasi mai), e poi approvo o richiedo modifiche di alto livello. Tempo medio: cinque, sette minuti.
Ho smesso di correggere i nomi di variabile. Ho smesso di chiedere refactor di metodi da venti righe a quattordici. Ho smesso di segnalare la mancata aderenza a una convenzione di stile che il linter gestisce da solo. Tutta quella superficie di review è scomparsa, e con lei il novanta per cento del tempo che le dedicavo.
La sostituzione non è stata immediata. Per le prime sei, otto settimane mi sono sentito in colpa: avevo l’impressione di non stare facendo il mio lavoro. Quella sensazione era una illusione di controllo: stavo confondendo la quantità di righe lette con la qualità della decisione tecnica. Sono due cose diverse, e nel 2026 lo sono ancora di più di quanto non lo fossero nel 2014.
Cosa ho iniziato a fare
Quattro cose, in ordine di tempo dedicato.
Tengo la visione del prodotto. Più che mai. Quando un agente parte su un task, gli passo non solo il prompt operativo, ma la specifica architetturale del sistema: i contratti API esposti, gli invariants del cluster MariaDB con replica circolare (i due nodi codename james e jason con i loro vincoli di consistency), il modello dati multi-tenant, le regole di scoping. Il tempo che prima passavo a correggere nomi di variabile lo passo a tenere aggiornato il documento di architettura che gli agenti leggono come contesto prima di toccare codice. È un mestiere diverso e, devo ammetterlo, più stancante: pretende che io sappia davvero cosa sto facendo, perché un agente eseguirà alla lettera quello che gli ho scritto.
Definisco i contratti API. Prima di delegare un task all’agente scrivo il contratto: input attesi, output attesi, errori possibili, side effect dichiarati, invarianti che non devono essere violate. Dieci minuti di mio tempo prima del task valgono due ore di review evitate dopo. È la stessa disciplina che avevo da CTO sui design doc, ma adesso il design doc non è una formalità: è il prompt principale che l’agente userà per generare il codice.
Scrivo gli oracoli di test. Non i test (quelli li scrive l’agente), ma gli oracoli: cosa vogliamo verificare, su quali edge case, con quali fixture, contro quali errori del sistema sotto test. Un oracolo ben scritto è un test pass che vale dieci. Un oracolo male scritto è un test che passa sempre e non garantisce nulla. Il tempo che dedico agli oracoli è raddoppiato rispetto al 2024.
Leggo i diff aggregati, non i singoli file. Quando un agente apre la pull request, guardo prima la mappa delle modifiche: quali moduli ha toccato, in quale ordine di dipendenza, se ha rispettato le convenzioni di scoping multi-tenant, se i test che ha scritto coprono i casi che gli avevo elencato. Se la mappa è coerente, scendo nei file solo dove vedo qualcosa di sospetto: un cambio in un file di middleware, una modifica in una migration, un’aggiunta nel layer di orchestrazione delle queue. Su un diff da 1.300 righe scritto in tre giorni dall’agente, il mio tempo umano sopra è di sei ore di review architetturale, non di tre giorni di review riga per riga.
Perché è scomodo
Lo è per quattro ragioni, in ordine di intensità.
La prima: la tentazione di tornare a leggere ogni riga come “sicurezza tecnica”. È una illusione. Quando leggi un diff da 1.300 righe in tre ore non stai esercitando controllo, stai esercitando un rituale. Il controllo vero, su quel volume di codice, lo eserciti a monte (specifica) o a valle (test e telemetria), non al centro.
La seconda: il senso di colpa. Per dodici anni la mia identità tecnica è stata “quello che legge il codice prima di mergiarlo”. Smettere di farlo è stato un piccolo lutto. Il dev senior che mi conosce da quattro anni, in un retro di marzo, mi ha detto: “ti vedo meno con la tastiera, ti vedo di più al telefono con i clienti”. Aveva ragione. Mi sono spostato.
La terza: la fatica del context-switching fra dieci task. Tenere la visione di dieci sottosistemi che lavorano in parallelo è cognitivamente più pesante di rivedere otto pull request sequenziali. Ho dovuto ridisegnare la giornata: due slot di “deep work” architetturale al mattino (8:30-10:30 e 11:00-12:30), un solo slot di review nel pomeriggio (15:00-16:00), tutto il resto è dialogo con gli agenti e con il team. Nessuna chiamata cliente prima delle 14:30, niente.
La quarta: la difficoltà di delegare la decisione tecnica al dev senior. Per anni la review era anche il momento in cui io traferivo loro il mio mental model. Adesso quel transfer passa attraverso il documento di architettura e attraverso le sessioni di pairing settimanale del venerdì, dove ogni dev senior mi mostra dove l’agente ha brillato e dove ha sbagliato. È più formale, e all’inizio è stato meno spontaneo. Ci stiamo ancora adattando.
Perché senza i dodici anni di gavetta non funzionerebbe
Questo è il punto che voglio dire chiaro, perché da fuori sembra che il mio mestiere sia diventato banale (apri tab, dai prompt, leggi diff). Non lo è. È diventato condensato.
Per guidare dieci agenti in parallelo serve l’intuizione di “dove guardare”. Quando l’agente mi chiude un task da 600 righe, non posso permettermi di leggerle tutte. Devo sapere, dal nome del task e dal modulo toccato, dove si nascondono i bug più probabili. Quell’intuizione non si compra e non si finta: si costruisce scrivendo codice di produzione per anni, prendendo schiaffi su race condition latenti, su query N+1 nascoste, su transazioni MariaDB che si comportano in modo non ovvio sotto carico, su deploy notturni che vanno in errore alle 3 del mattino. Solo dopo aver passato anni dentro quei mestieri, riesci a leggere un diff e dire “qui c’è qualcosa che non torna” senza saperlo articolare subito a parole.
Un junior con coding agent non è un me con coding agent. Il primo è un esecutore con uno strumento potente, il secondo è un revisore architetturale con uno strumento potente. La differenza non è sull’agente, è sui dodici anni. Ed è la cosa che oggi quando assumo cerco con più attenzione: non quanto codice scrive un candidato, ma quanti errori di produzione ha visto.
Lo scrivo perché c’è chi sostiene che il coding agent appiattisca le competenze e che il junior con AI valga quanto il senior con AI. Sul mio campo, dentro Romiltec, non l’ho visto succedere. Ho visto l’opposto: il delta tra senior e junior, se misurato in qualità del prompt iniziale e del documento di architettura passato all’agente, è cresciuto, non diminuito. Il senior scrive una specifica che l’agente segue per tre giorni e produce un modulo da 1.300 righe che tiene. Il junior scrive una specifica che l’agente segue per tre giorni e produce un modulo da 2.400 righe che bisogna riscrivere. La differenza non è nello strumento, è nella mano che lo guida.
Cosa porto a casa
Tre cose, in ordine.
La prima: il ruolo del founder tecnico nel 2026 si è spostato dal codice al sistema. Il codice lo scrive l’agente. La coerenza del sistema, intesa come somma di architettura, contratti, invarianti, oracoli di test e telemetria, la fa l’umano. Se non c’è chi tiene quella coerenza, il volume di codice prodotto dagli agenti diventa un problema, non un vantaggio.
La seconda: la review riga per riga, su un team con coding agent attivi, è obsoleta come rituale quotidiano. Non è obsoleta in assoluto: la uso ancora quando un dev senior mi chiede una seconda opinione su un pezzo di codice critico, o quando vedo qualcosa di sospetto nel diff aggregato. Ma non è più la mia forma quotidiana di responsabilità tecnica. La forma quotidiana è il documento di architettura tenuto aggiornato.
La terza: la traiettoria di chi ha fatto dodici anni di codice scritto a mano è oggi un asset, non una zavorra. Nel 2024 sentivo dire che chi è cresciuto nel rituale del CTO classico avrebbe fatto fatica ad adattarsi all’AI in produzione. L’esperienza dentro Romiltec dice il contrario: chi ha la mappa mentale dello stack costruita su anni di codice scritto, oggi guida gli agenti con un livello di sicurezza che chi non l’ha non ha. È controintuitivo solo se si guarda lo strumento e non la mano.
Venerdì 26 giugno 2026, 18:30, chiudo gli ultimi tab di Claude Code della giornata. Il dev senior in onboarding mi scrive in chat: “domani mi spieghi come imposti il documento di architettura che dai agli agenti?”. Gli rispondo che lunedì gli dedico due ore. Quella conversazione, due ore di un venerdì che cinque anni fa avrei passato a leggere diff, è il mio nuovo mestiere. Non lo trovo più scomodo. Lo trovo, finalmente, condensato.