C'è un'obiezione che gira insistente tra gli scettici dell'AI applicata alla programmazione, ed è tutt'altro che stupida: se il modello sbaglia di continuo, l'unico modo per fidarsi del suo codice è rileggerlo tutto. Ma rileggere tutto è un'attività umana con limiti enormi. Quindi il presunto vantaggio di produttività evapora nel momento stesso in cui inizi ad utilizzare l'AI. E questo è un fatto logico.

Il mio ragionamento poggia su un paio di temi empirici ma reali, e vale la pena prenderlo sul serio proprio perché arriva a una conclusione opposta a quella di Thomas Depierre in un pezzo dal titolo programmatico: revisionare il codice dell'AI non è un argomento valido (tradotto in italiano però rende poco l'idea). Perché è nel punto in cui Depierre ha ragione che si capisce dove, secondo me, sbaglia bersaglio.

1.L'argomento dello scettico, in breve

La ricerca sulla code review dice cose piuttosto sensate. Una revisione efficace fatta da un umano non regge più di un'ora: dopo, l'attenzione crolla e la capacità di ragionare si affievolisce. E non si revisionano più di circa 400 righe di codice all'ora senza che la capacità di trovare difetti si degradi. Metti insieme le due cose e ottieni un limite: un senior può fare una manciata di sessioni serie al giorno, per un totale realistico ben sotto le mille righe revisionate davvero bene.

Da qui la stoccata di Depierre: se la difesa dei coding assistant è "basta revisionare tutto come hai sempre fatto", allora quella difesa si schianta contro un muro aritmetico. Peggio ancora — nota lui — ci sono indizi sperimentali che dicono che revisionare codice generato da un LLM sia più difficile che revisionare codice umano, e che chi lo fa si senta più sicuro trovando meno difetti. Il modello è addestrato, in un certo senso, a produrre output che passa l'ispezione. Fine dei giochi.

Ecco. Su questo non ho niente da obiettare. È vero. Ed è precisamente per questo che la strategia "leggo tutto riga per riga" è quella sbagliata — non perché sia troppo poco, ma perché è la mossa di chi non ha ancora capito come è cambiato il mestiere dei programmatori.

2.Il difetto nascosto

L'intera costruzione di Depierre assume una cosa: che l'unità di controllo qualità sia la riga di codice. Che revisionare significhi passare in rassegna token dopo token finché non trovi il refuso fatale. Sotto questa assunzione, sì, l'AI diventa una macchina che ti scarica addosso più lavoro di verifica di quanto ne tolga.

Ma è davvero così che i programmatori bravi hanno sempre garantito la qualità?

No. La riga di codice non è mai stata l'unità di fiducia. Lo sono i confini: le interfacce tra servizi, i contratti tra moduli, gli invarianti che devono restare veri, i punti in cui i dati entrano ed escono dal sistema. Un senior non legge diecimila righe per fidarsi di un componente. Guarda la firma delle funzioni, i test che lo circondano, come si comporta ai bordi, e decide dove serve infilare il naso davvero.

Detta diversamente: la revisione riga per riga non rende scalabile nulla. Nessuna azienda seria ha mai retto la qualità del proprio software facendo leggere ogni riga a un umano. La regge con architetture che rendono certi errori impossibili, con tipi che vincolano, con test che catturano le regressioni, con osservabilità che segnala quando qualcosa devia. L'AI non rompe questo modello: lo mette solo sotto pressione, costringendoci a smettere di fingere che la lettura integrale fosse mai il vero meccanismo.

3.Le tre fazioni

Oggi, se guardi come le persone lavorano davvero con questi strumenti, vedi tre atteggiamenti distinti. Non sono livelli di bravura tecnica in senso classico: sono tre modi diversi di rapportarsi a ciò che la macchina produce.

1. Chi legge ogni riga

Non si fida di niente che non abbia ispezionato personalmente. È l'atteggiamento più rassicurante e, paradossalmente, quello che regge peggio la scala. Fa esattamente ciò che Depierre descrive: si scontra con il muro dell'ora e delle 400 righe, e finisce per essere più lento di prima, con in più la falsa sicurezza di aver controllato tutto.

2. Chi non sa nemmeno cosa c'è scritto

Accetta l'output alla cieca, incolla, spinge in produzione e spera. È la fazione che dà ragione a tutti gli scettici del mondo. Non capisce lo stack, non ha un modello mentale del sistema, e non ha modo di sapere se il codice è corretto o solo plausibile. È qui che nascono i disastri che poi vengono attribuiti "all'AI".

3. Chi guarda l'insieme e verifica dove conta

Tiene in testa l'architettura. Sa quali parti sono critiche e quali innocue. Legge il diff a colpo d'occhio per capire la forma del cambiamento, poi affonda la lettura riga per riga solo dove il rischio lo giustifica: il parsing, i confini di sicurezza, la logica che tocca i soldi o i dati sensibili. È la fazione che rende l'AI effettivamente utile, perché applica l'attenzione dove ha valore invece di spalmarla uniformemente su tutto.

Scorri orizzontalmente per vedere tutte le colonne →

La differenza tra le diverse scuole di pensiero non è la capacità. È il criterio con cui si sceglie cosa leggere. Chi controlla tutto non ha un criterio: legge tutto perché non sa distinguere. Chi invece sa cosa accade ha un modello del sistema abbastanza forte da permettersi di ignorare il novanta per cento dell'output e concentrarsi sul dieci per cento che può davvero fare male.

4.Lo shellscript, ovvero perché il modello mentale conta

Depierre porta un esempio contro gli entusiasti: qualcuno arriva a dire che non dovrai mai più scrivere uno shellscript a mano, lo farà l'AI. E lui giustamente ribatte: ma lo shellscript è proprio il codice più difficile da revisionare, quello dove un carattere di punteggiatura sbagliato è la differenza tra "innocuo" e "ho appena cancellato l'intero disco". Dare all'AI il codice più insidioso da controllare è la mossa peggiore possibile.

Ha ragione — solo se il tuo unico strumento è la lettura. Ma il programmatore che sa cosa sta accadendo non affronta uno script generato dall'AI rileggendolo carattere per carattere e sperando di beccare il refuso letale. Lo affronta come affronterebbe qualsiasi codice pericoloso di cui non si fida: lo isola, lo esegue in un ambiente sacrificabile, gli dà in pasto input di prova, controlla cosa fa prima di puntarlo su qualcosa di importante. Sposta la fiducia dalla lettura al comportamento osservato. Il codice più difficile da revisionare a occhio è spesso quello più facile da verificare per esecuzione — a patto di avere l'impostazione mentale per farlo.

È qui che l'argomento dello scettico e la mia tesi in realtà convergono, arrivando a due morali opposte.

---

5.Cosa significa "capire cosa sta succedendo"

Se dovessi comprimere tutto in una sola competenza, non sarebbe "saper leggere il codice velocemente". Sarebbe avere un modello mentale del sistema abbastanza accurato da sapere dove le cose possono rompersi, come progettare l'insieme e conoscere almeno il 20% dei risultati che ti aspetti. È questo che permette di delegare senza abdicare. È questo che trasforma l'AI da fabbrica di debito tecnico a moltiplicatore reale.

Inoltre, chi conosce o studia l'ambito di applicazione di un software e sa cosa sta accadendo durante lo sviluppo, ecco, quella persona ha in mano le chiavi.

Il programmatore che capisce lo stack sa che quel modulo parla con quel servizio tramite quell'interfaccia, e che se il contratto regge il resto è dettaglio. Sa che quella funzione è pura e testata, quindi può fidarsi del diff senza leggerlo. Sa che quel pezzo tocca l'autenticazione, quindi lì e solo lì rallenta, apre l'editor e legge ogni singola riga come farebbe un revisore d'altri tempi. Distribuisce la diffidenza in modo informato. Non uniforme, informato.

Gli scettici hanno ragione su un punto e vale la pena ripeterlo: chi usa questi strumenti senza un modello del sistema sta accumulando problemi che esploderanno dopo, e la falsa sicurezza è reale e documentata — e forse un giorno questo problema sparirà. Ma ora la risposta a quella falsa sicurezza non è "leggi ancora più righe". È costruire un tipo di comprensione che ti dice, in ogni momento, se puoi fidarti dell'insieme e dove devi smettere di fidarti.

Nell'epoca dell'AI il codice è aumentato a dismisura e a buon mercato. Ciò che resta scarso — ed è sempre più prezioso — è la persona che capisce cosa sta succedendo davvero dentro il sistema. Non chi legge di più, ma chi sa dove guardare l'insieme delle cose.