---
title: "Nessuno legge più ogni riga. Metti la sicurezza nel sistema."
url: "https://simonebova.com/it/writing/nessuno-legge-ogni-riga"
lang: "it"
updated: "2026-11-08"
author: Simone Bova
alternates:
  it: "https://simonebova.com/md/it/writing/nessuno-legge-ogni-riga"
  en: "https://simonebova.com/md/en/writing/nessuno-legge-ogni-riga"
  pl: "https://simonebova.com/md/pl/writing/nessuno-legge-ogni-riga"
---

# Nessuno legge più ogni riga. Metti la sicurezza nel sistema.

2026-11-08 · Metodo

Quando il codice lo scrivono gli agenti, un umano che legge ogni diff è la safety net sbagliata. Come shippo a velocità agentica, dove sono d'accordo con Anthropic e dove sto con Theo.

Io shippo così ogni giorno (prodotti e feature per utenti veri, non «righe di codice»): sessioni che durano settimane, 5 subscription, $30k al mese di token, agenti che scrivono codice che non leggo. Quando Anthropic ha pubblicato come il team di Claude Code fa code review ([l'articolo](https://claude.dev/blog/solving-code-review-at-anthropic/)) e Theo l'ha letto in video ([qui](https://www.youtube.com/watch?v=TFCDWrEBaFM)), ci ho ritrovato il mio processo. Dove i due non sono d'accordo, sto quasi sempre con Theo.

I loro numeri dicono quello che vedo io. Su Claude Code le PR mergiate sono più che raddoppiate tra giugno e settembre, e la quota di revert è scesa di oltre il 40%. Theo riceve fino a 800 PR al giorno su T3 Code, con un team di tre persone. Più velocità e meno errori, insieme. Ecco come lo tengo vero io.

## Leggere il diff non è mai stata la safety net

Non leggo ogni riga, e lavoro meglio così. I bug che passano oggi vivono tra un pezzo e l'altro, nei tempi e nei dati, e fissare il codice raramente li trova. Theo dice che quasi ogni regressione che ha shippato gli sarebbe sfuggita anche in review, e la mia esperienza è la stessa. La domanda che mi faccio è quella che Anthropic formula bene: cosa può andare storto con questa modifica, e quale check, automatico o umano, la deve intercettare?

La review la chiedo sempre a un modello di un'altra famiglia. Quest'autunno, in un progetto di ricerca su come far girare agenti di coding dentro sandbox, ho fatto fare due review indipendenti del mio codice: entrambe hanno trovato problemi veri, e ogni fix è entrato con un test che falliva prima e passava dopo. Theo chiama la sua versione Council: tre modelli di tre famiglie, sulle subscription. Trova troppo caro il prodotto di review di Anthropic a questa velocità, e sono d'accordo. Oggi i reviewer che non si lasciano scappare niente sono GPT-6.1 Sol e Astra. I bug che passano sotto le review di Opus e Astra sono bug che non avrei mai trovato fissando il codice intensamente e appassionatamente. E neanche tu. Il mio lavoro è decidere quali finding contano.

## Ogni modifica arriva verificata

Anthropic scrive che la maggior parte delle modifiche passa da una review di Claude prima che la veda un umano. Theo dice tutte, e io pure: una PR che il tuo agente non ha verificato fa perdere tempo a chi la legge. Da me Claude la feature la prova davvero, come la proverebbe un utente: niente sMoKe TeStS «trust me bro». Boris Cherny, che ha creato Claude Code, stima che dare all'agente un modo per verificarsi renda il risultato due o tre volte migliore. Theo arriva a far aprire a ogni thread il suo desktop, lanciare l'app e allegare alla PR il video della modifica che funziona.

Quello che mi ha insegnato di più sulla verifica è stata una suite verde. Nello stesso progetto, i test che avevano bisogno dei container si skippavano da soli, in silenzio, ogni volta che il motore dei container era spento. Il run diceva verde, e voleva dire solo che i test eseguiti erano verdi. Una verifica deve dire cosa è girato, cosa è stato skippato e cosa resta da fare. Sul Company Brain di Yempik è una regola di ogni release ([la storia è qui](https://simonebova.com/it/writing/deploy-to-prod-make-no-mistakes)).

## La review la legge il mio agente. Io leggo il verdetto.

Qui sto con Theo fino in fondo. I commenti di review sono per l'agente che ha scritto la PR: decide quali feedback sono buoni, fixa, e solo allora mi chiama. Copiare a mano il suggerimento di un reviewer dentro un prompt è roba del 2024. Gli strati di check però aggiungono anche codice: Theo ha visto PR da 50 righe diventare da 2.000 perché l'agente aveva obbedito a ogni commento. Per questo un finding deve essere verificato prima che qualcuno ci agisca sopra.

## L'attenzione umana segue il rischio

Il tier lo decide la modifica, mai l'autore. Docs e copy dietro un flag passano senza umani quando i check sono verdi, il codice rischioso ne vuole uno o due, i workflow di CI passano sempre da una persona. Anthropic usa tier fissi da zero, uno o due umani. Theo li vorrebbe dinamici, con il bot che descrive il rischio e non sceglie mai quale persona taggare, e preferisco la sua versione. Su una regola non tratto: l'approvazione di un bot non sostituisce mai la mia. È un finding, e la firma è mia. Chi ha promptato la modifica ne è l'autore.

La review più utile che ho fatto quest'autunno non c'entrava con i bug. Un agente aveva aperto una PR su questo sito con nuove pagine servizi: build verde, fatti verificati, tutto al suo posto. L'ho chiusa il giorno stesso, perché la direzione era sbagliata: troppo safe, troppo testo per poco valore. Nessun check l'avrebbe intercettato. Decidere se una cosa deve esistere è la parte della review che resta umana.

## Un loop di review ha bisogno di uno stop

Alla mia scala è la regola che conta di più. Con sessioni che durano settimane, un loop che nessuno ferma ti prosciuga il weekly. In Anthropic una PR è passata da più di 50 round di review e fix in una notte, e circa il 59% di quello che il reviewer segnalava era codice presente fin dal primo round. Theo ha dimenticato un loop in una tab chiusa e dopo quattro giorni la PR era a circa 80.000 righe. Il noise costa di più quando l'autore è un agente: una persona ignora un nit in pochi secondi, un agente lo fixa, con un altro commit e un altro round.

Il fix è semplice. Cap a tre round, poi il reviewer chiede di ripensare l'approccio. Dopo i primi round si rivede solo il diff nuovo. Si segnala la classe di bug, non la singola riga, e niente di già segnalato torna. Con queste regole Anthropic ha portato la media di review per passare da 2,08 a 1,32. La mia soglia è un punteggio di confidenza al posto del conteggio dei commenti: una PR con un commento e voto 6 su 10 viene prima di una con venti nit e voto 9 su 10. La stessa lezione l'avevo già pagata con i retry ([qui](https://simonebova.com/it/writing/il-modello-intelligente-e-il-collo-di-bottiglia)).

## Andare più piano non risolve niente. Il rollback a costo zero sì.

Rallentare abbassa il tasso di errore soprattutto perché fai meno di tutto. Se la tua soluzione per non rompere le cose è andare più piano, hai solo fatto meno. Un team che va brrrr deve imparare a rendere gli errori meno costosi e più facili da revertare. Io preferisco diventare più veloce a notare e a fixare: flag che si spengono senza deploy, uso interno prima, rilascio graduale, rollback in un passo. Chi fa landare una modifica la fixa se si rompe, perché ha più contesto di tutti.

In Intarget quest'estate abbiamo cambiato il modo in cui la piattaforma agentica salva le conversazioni, con persone che la usano ogni giorno. Il vecchio storage ha continuato a ricevere ogni scrittura in parallelo, come una via di ritorno a costo zero. Le letture sono passate dietro un flag. La vecchia copia l'abbiamo cancellata solo dopo confronti ripetuti con zero differenze. In ogni momento, il rollback era uno switch. Prima di ogni modifica rischiosa mi faccio due domande: come la reverto, e quanto in fretta mi accorgo che devo farlo.

## Anche il reviewer ha il suo eval set

Il reviewer è un modello più un harness come ogni altro agente, quindi lo tratto allo stesso modo. Incidenti e revert diventano il suo eval set, e ogni modifica a prompt, tool o modello resta solo se il punteggio sale. Anthropic misura anche il noise, facendo girare il reviewer su PR che sa pulite. La regola che applico ovunque vale anche qui: un punteggio misurato sul lavoro di qualcun altro non ti dice niente sul tuo.

## L'obiezione più forte: funziona per Anthropic, non per un team piccolo

Funziona per Theo, che è in tre e non ha una merge queue, e funziona per me. Fino a questa settimana questo sito non aveva nemmeno un template per le PR: il gate era build, lint e typecheck verdi sulla mia macchina, poi la build della piattaforma. Gli strati costano poco: un template, un reviewer AI su una repo, un cap ai round, un flag. Quello che non scala è trattare la lettura umana come garanzia. Da questo saggio, ogni PR del sito parte da un template che chiede Testing, Risk e How to revert.

## Da lunedì

- Dai al tuo agente un modo per verificare il suo lavoro, e chiedigli l'output, mai il “fatto”.
- Aggiungi Testing, Risk e How to revert al template delle PR.
- Metti un reviewer AI di un'altra famiglia su una repo, calibra cosa segnala per qualche settimana, poi allarga.
- Lascia che sia l'agente autore a leggere i commenti di review. Tu leggi il verdetto.
- Decidi il tier dalla modifica, mai dall'autore. L'approvazione di un bot non vale mai quella di una persona.
- Cap ai round di review, e dopo i primi rivedi solo il diff nuovo.
- Rendi ogni modifica rischiosa revertabile con uno switch.
- Trasforma incidenti e revert in un eval set per il tuo reviewer.

*// sessioni lunghe settimane, $30k al mese di token. a questa scala lo stop ce l'hai, o lo paghi.*

[simone@yempik.ai](mailto:simone@yempik.ai) · [Book a call](https://calendar.app.google/LKDrQPKGV2EAFCMN9)