Il metodo

C'è una frase che sento ripetere spesso, di solito con un tono tra il preoccupato e il compiaciuto: come fai a fidarti di codice che non hai letto riga per riga?

È una domanda che sembra seria. In realtà nasconde un presupposto falso: che prima dell'intelligenza artificiale esistesse un mondo in cui gli sviluppatori leggevano, capivano e verificavano ogni riga di codice che scrivevano. Quel mondo non è mai esistito.

Il mondo di prima

Nessuno scriveva tremila righe e poi passava la settimana successiva a rileggerle una per una. Da decenni il processo reale è un altro:

scrittura → compilatore → linter → test → debugger → code review → CI → comportamento in esecuzione

Ogni errore aveva il suo strumento. Sintassi sbagliata? Compilatore. Tipo errato? Type checker. Variabile mai usata? Linter. Funzione che restituisce il risultato sbagliato? Test. Regressione? Suite di test più diff Git.

La verifica del software non è mai consistita principalmente nel leggere il codice. Non potrebbe esserlo: un'applicazione seria ha centinaia di migliaia di righe, e nessun essere umano tiene in testa un sistema intero. Del resto, quando uso URLSession non leggo il codice di rete che ci sta sotto. Quando uso SQLite, Postgres, SwiftUI o Linux non conosco ogni riga. Lavoriamo da sempre per livelli di fiducia e di verifica: contratti, tipi, interfacce, isolamento, test, osservabilità.

Quindi no, l'AI non ha creato il problema della verificabilità del software.

Cosa è cambiato davvero

Sarebbe altrettanto sbagliato dire che non cambia niente. Cambia una cosa sola, ma pesante: il rapporto tra la velocità con cui il codice viene prodotto e la velocità con cui viene verificato.

Prima uno sviluppatore in una giornata produceva, diciamo, trecento righe. E in quelle ore aveva pensato alla soluzione, l'aveva scritta, corretta, eseguita, modificata. Quell'attività stessa gli lasciava una familiarità con il codice. Mentre scriveva aveva già pensato: qui devo controllare il valore nullo, questo array potrebbe essere vuoto, questo dato arriva da quell'altra funzione.

Con un agente puoi ottenere tremila righe in pochissimo tempo. Il problema non sono le tremila righe. Il problema è che il costo di produzione è crollato molto più in fretta del costo di verifica, e che tu non hai partecipato alla costruzione di quel codice.

Codice prodotto non è più automaticamente codice compreso. Questa, secondo me, è la formulazione onesta del problema. Molto più difendibile di «l'AI scrive codice inaffidabile».

Il rischio non è la sintassi

Gli errori di sintassi sono il problema meno interessante che esista. Il compilatore li trova sempre.

Il problema serio è un'altra cosa. Immagina un controllo del genere:

if user.subscription != nil {
    unlockPremium()
}

Compila. Nessun warning. Nessun errore. Ma forse la regola corretta era: abbonamento esistente e attivo e non scaduto. Questo è un errore semantico, e il compilatore non può conoscere la tua intenzione. Errori del genere esistevano anche prima. L'AI semplicemente li produce più in fretta se le specifiche sono vaghe.

Ed è per questo che la domanda giusta non è più «ho letto tutto il codice?», ma «ho abbastanza prove che il sistema faccia quello che deve fare?».

Prendiamo una funzione banale come le scadenze ricorrenti. Posso non conoscere a memoria le ottocento righe che la implementano. Ma posso scrivere la specifica: una scadenza mensile impostata il 31 deve comportarsi correttamente nei mesi che non hanno 31 giorni. E poi verificare:

31 gennaio → 28 febbraio 31 marzo → 30 aprile 31 maggio → 30 giugno anno bisestile → 29 febbraio

A quel punto ho una prova comportamentale molto più solida della lettura. E il caso limite che conta davvero non è quello che l'agente sbaglia a compilare: è quello che compila benissimo. Dopo il taglio al 28 febbraio, la scadenza deve ricordarsi di essere nata il 31. Nessun compilatore può saperlo: sta scritto solo nella specifica.

Karpathy e Cherny

Su questo punto vale la pena essere precisi, perché il dibattito pubblico vive di citazioni semplificate.

Il termine vibe coding nasce da un post di Andrej Karpathy del 2 febbraio 2025: «c'è un nuovo tipo di programmazione che chiamo vibe coding, in cui ti abbandoni completamente alle vibrazioni e dimentichi che il codice esista». Quello che si cita molto meno è che nello stesso post Karpathy precisava che il metodo andava bene per progetti usa e getta del fine settimana. Un anno dopo ha definito quel post un pensiero buttato lì senza rifletterci, aggiungendo che nel frattempo programmare tramite agenti è diventato un flusso di lavoro professionale ordinario, «ma con più supervisione e controllo».

Quindi nemmeno chi ha inventato l'espressione ha mai sostenuto che si potesse generare e pubblicare senza guardare.

Dall'altra parte c'è chi questi strumenti li costruisce. Boris Cherny, che guida Claude Code in Anthropic, ha scritto una frase che considero il cuore della questione: il codice di produzione scritto da Claude dovrebbe avere uno standard più alto di quello scritto da un umano. Non più basso: più alto. E ha aggiunto che il fattore che incide di più sulla qualità è dare all'AI un modo di verificare il proprio lavoro — eseguire i test, aprire il browser, provare davvero l'interfaccia.

Due persone che hanno tutto l'interesse a raccontare l'AI come una scorciatoia dicono l'esatto contrario: serve più verifica, non meno.

Il caso Klarna

La storia di Klarna viene citata continuamente, in entrambe le direzioni: «l'AI ha sostituito settecento persone» e poi «l'AI ha fallito, hanno dovuto riassumere tutti». Nessuna delle due versioni è esatta.

Nel febbraio 2024 Klarna annuncia che il suo assistente ha gestito 2,3 milioni di conversazioni nel primo mese, due terzi delle chat di assistenza, con un risparmio stimato di 40 milioni di dollari. La frase che ha fatto il giro del mondo — «fa il lavoro di 700 agenti a tempo pieno» — è una stima di equivalenza di volume, non un annuncio di 700 licenziamenti. L'organico dell'azienda era effettivamente sceso, ma soprattutto per blocco delle assunzioni e turnover naturale.

Nel maggio 2025 il CEO Sebastian Siemiatkowski dichiara che l'azienda torna ad assumere persone per l'assistenza: l'AI costava meno, ma la qualità era più bassa, e i clienti vogliono poter parlare con qualcuno. Anche qui, però, la conclusione non è «abbiamo spento l'AI». Il chatbot continua a gestire due terzi delle richieste. Klarna è passata a un modello ibrido: l'automazione si occupa del volume ripetitivo, le persone di tutto ciò che richiede giudizio.

Non è la storia di una tecnologia che fallisce. È la storia di un'azienda che aveva confuso automazione di una parte del lavoro con scomparsa del lavoro, e che ha corretto il tiro. Ed è esattamente lo stesso errore che commettiamo quando pensiamo che l'AI abolisca la verifica.

Il collo di bottiglia si è spostato

Prima la parte costosa dello sviluppo era produrre il codice. Oggi quella parte si comprime drasticamente. Ma non si comprimono allo stesso modo: capire il problema, decidere l'architettura, verificare, mettere in sicurezza, fare debug, progettare l'esperienza d'uso, conoscere il dominio, assumersi la responsabilità finale.

C'è una trappola in agguato, e la vedo ovunque. Se prima un prodotto richiedeva dodici mesi e oggi l'implementazione si fa in tre settimane, la tentazione è concludere: allora il prodotto è pronto in tre settimane. No. Diventa: tre settimane di implementazione più il tempo necessario di iterazione, design, verifica e uso reale. L'accelerazione resta straordinaria. Ma non hai abolito l'ingegneria del software.

Il punto è che il tempo risparmiato sull'implementazione dovrebbe in parte diventare tempo di verifica, non semplicemente anticipo della data di pubblicazione. Altrimenti abbiamo accelerato enormemente la parte che produce software e usato il guadagno per pubblicare prima invece che per pubblicare meglio. È un'occasione sprecata.

Bisogna distinguere due cose che continuiamo a confondere. Time to code: quanto ci vuole a implementare. Time to product: quanto ci vuole perché quel codice diventi un prodotto affidabile, comprensibile, usabile da persone vere. Il primo sta crollando. Il secondo no, non nella stessa proporzione.

Il metodo

Da qui nasce il modo in cui lavoro. Non è vibe coding nel senso di prompt, codice, pubblicazione. È un piccolo processo di sviluppo assistito dall'AI, dove l'implementazione è diventata la fase breve e la validazione la fase lunga.

problema → requisiti → design → implementazione con l'agente → build, analisi statica, test → seconda analisi con un agente diverso → i rilievi tornano al primo agente, che verifica se reggono → correzioni → test di regressione → uso reale mio → uso non guidato da altre persone → correzioni → rilascio

Due punti mi stanno particolarmente a cuore.

Il primo è la separazione tra chi produce e chi controlla. Non chiedo allo stesso agente «hai fatto bene?», perché la risposta sarebbe prevedibile. Introduco un secondo osservatore. E non accetto nemmeno automaticamente il verdetto del secondo: lo riporto al primo perché verifichi se la segnalazione regge. Non è una garanzia di indipendenza assoluta — due modelli possono condividere gli stessi punti ciechi — ma è una difesa in più, e costa poco.

Il secondo è dare il prodotto alle persone. Mia moglie, mia figlia, chiunque non conosca l'architettura e soprattutto non sappia come io mi aspetto che l'app venga usata. Io guardo una schermata e penso: è ovvio che si preme qui. Loro prendono il telefono e premono da tutt'altra parte. Quello è un dato prezioso, e nessun test automatico me lo restituisce. Spesso non è nemmeno un bug: il software funziona, ma l'interfaccia non comunica come si usa.

Sono due domande diverse. Abbiamo costruito correttamente ciò che avevamo progettato? L'AI può aiutarmi moltissimo. Abbiamo progettato la cosa giusta per chi dovrà usarla? Qui la componente umana resta decisiva.

E aggiungo una terza cosa, che riguarda il design. Man mano che i modelli migliorano, una schermata che funziona, una navigazione, una gestione dello stato diventano sempre meno discriminanti. Un prodotto può essere tecnicamente perfetto e completamente anonimo. Chiedi «fammi un sito moderno» e ottieni titolo grande, sottotitolo, pulsante, quattro riquadri arrotondati, tre funzionalità, footer. Non è un brutto sito: è la soluzione statisticamente più sicura. Se il prodotto deve avere un'identità, quella conversazione è molto più lunga, e il criterio di correttezza non è più vero o falso: è gerarchia, gusto, contesto, comprensibilità.

Quando è pronto

Sono tentato di dire «un prodotto non è pronto prima di due mesi di verifica», ma sarebbe una regola sbagliata. Una piccola utility può essere davvero pronta in due settimane. Un'app che tocca pagamenti, sincronizzazione o dati importanti può richiedere mesi.

Il criterio giusto è un altro: il prodotto non è pronto quando l'AI ha finito di scrivere il codice. È pronto quando ho abbastanza prove che soddisfi il livello di qualità e di rischio richiesto. Possono essere quindici giorni o sei mesi. Questo mi protegge anche dall'errore opposto: testare all'infinito un prodotto semplice senza ricavare più alcuna informazione nuova.

La carrozza e l'automobile

Ogni volta che un agente produce diecimila righe troppo in fretta, qualcuno propone di tornare a scriverle a mano.

È come rispondere all'aumento della velocità delle automobili tornando al cavallo. L'automobile non ha eliminato il problema di arrivare sani e salvi: ha reso necessari freni migliori, segnaletica, patenti, revisioni, assicurazioni, infrastrutture. Nessuno ha proposto di rallentare i motori per poter continuare a guidare come prima.

La risposta ingegneristica non è «produciamo più lentamente per riuscire a controllare». È adattare il sistema di verifica alla nuova capacità produttiva.

Del resto, quando si racconta il fallimento di un progetto generato con l'AI, quasi sempre la sequenza vera è questa: richiesta del cliente, l'AI genera, consegna al cliente. Manca un passaggio. Se uno sviluppatore umano avesse scritto personalmente quella modifica e l'avesse consegnata senza provarla, sarebbe stato esattamente lo stesso errore professionale. L'errore dell'AI resta un errore dell'AI; la consegna senza verifica è responsabilità del processo. Non è un problema intrinseco del vibe coding: è assenza di controllo qualità.

Dove finisce il ragionamento

Non sto dicendo che l'AI non toglierà lavoro a nessuno. Alcune mansioni si ridurranno, alcuni ruoli spariranno, ed è inutile negarlo. Sto dicendo che confondere l'automazione di una parte del lavoro con la scomparsa del lavoro porta a conclusioni sbagliate — ed è esattamente l'errore che ha fatto Klarna prima di correggersi.

Nel software la conclusione è questa: se produrre codice diventa economico e velocissimo, il valore si sposta dal produrre codice al sapere quale codice produrre, come integrarlo, come verificarlo e se il prodotto risultante risolve davvero un problema.

Scrivere codice e sviluppare software non sono sinonimi. Forse è la cosa più importante che ho capito lavorando così.

Il codice corre. La verifica deve imparare a correre con lui.