Il giorno in cui ho smesso di leggere il mio codice

Non aprivo più l'IDE da settimane. Ho scoperto che non ero il solo, e che dietro c'è molto più che smettere di leggere codice.

Il giorno in cui ho smesso di leggere il mio codice

Qualche settimana fa ho notato una cosa strana: erano giorni che non aprivo il mio IDE, eppure i miei progetti non erano mai avanzati così velocemente e così bene. Pensavo fosse solo un'impressione, finché non sono entrato su Twitter (non credo che lo chiamerò mai X) e ho scoperto che tutto il settore si stava ponendo la stessa domanda che, solo 12 mesi fa, sarebbe sembrata assurda: "Ma tu il codice lo leggi ancora?". Oggi quella domanda si è spinta un passo più in là, ed è molto più scomoda di "chi lo scrive ancora?".

Ma tu il codice lo leggi ancora? 🤔

Tutto è iniziato con un tweet di Mitchell Hashimoto, il creatore dell'emulatore di terminale Ghostty. In realtà non è stato nemmeno il tweet, è stata la sua risposta. Qualcuno gli aveva chiesto come evitava che l'IA introducesse errori, incongruenze o cattive decisioni nel suo codice. E Mitchell ha risposto con una genialità: "Io leggo il codice."

Quattro parole semplici che due anni fa sarebbero passate inosservate, una risposta generica come tante altre nella rete.

Oggi invece è diventato un tweet virale con oltre 800.000 visualizzazioni (ho controllato: il thread è rimbalzato anche su Hacker News e su Reddit, segno che non è rimasto confinato alla bolla di Twitter).

Perché è diventato un dibattito? 🤔

Ed è lì che ho capito che non si trattava più di un'opinione isolata: era diventata una vera presa di posizione. Altri ingegneri con carriere importanti nel settore hanno iniziato a schierarsi apertamente in difesa della stessa idea.

Gergely Orosz, ex ingegnere senior di Uber e oggi autore della newsletter The Pragmatic Engineer, ha ripreso lo stesso commento e ha detto una cosa che mi ha colpito molto: gli ingegneri con esperienza resteranno preziosi ancora per anni non perché scrivono codice, ma perché continuano a leggerlo.

Guarda anche come il software engineer Yacine, ex ingegnere di Stripe, ha chiuso un'altra conversazione. Qualcuno gli aveva chiesto se avesse una skill o un loop per imparare da ciò che il modello Fable faceva bene o male, lamentandosi di non averne trovata una buona. E indovina qual è stata la risposta ironica di Yacine? La skill si chiama: "io il mio codice lo leggo davvero".

Cosa avevano in comune? 😮

La maggior parte di loro erano ingegneri con decenni di esperienza. Avevano contribuito a costruire sistemi enormi, lavorando in aziende dove un piccolo errore poteva costare milioni di dollari. Per loro, leggere il codice non era un'abitudine: era parte della responsabilità.

C'è però un caso che complica lo schema, ed è forse il più interessante di tutti: quello di Peter Steinberger. Non è un giovane indie hacker alle prime armi, ma un ingegnere veterano che ha già venduto la sua azienda, PSPDFKit, a Insight Partners nel 2021 per oltre 100 milioni di euro dopo 13 anni di bootstrapping, si è ritirato, si è annoiato ed è tornato a costruire software. Eppure oggi con OpenClaw, il suo progetto open source più recente, sostiene apertamente il contrario di Hashimoto: non legge il codice che manda in produzione. Invece di leggerlo riga per riga, chiede a un modello se ha capito l'intento della modifica.

Lo ha raccontato lui stesso, proprio nel podcast di Gergely Orosz — sì, lo stesso Orosz che difende la lettura del codice. Il che mi ha fatto capire che la linea di confine non passa tra "veterani" e "indie hacker", come pensavo all'inizio, ma da qualcos'altro.

In quel momento ho pensato: ok, ha senso. Ma no 🤔, il dibattito non era affatto finito lì: era appena cominciato.

Scorrendo ancora un po', mi sono imbattuto nei membri dell'altro schieramento, e sinceramente non era affatto il gruppo che mi aspettavo. Tutto è iniziato con Jack Friks, un indie hacker che ha lanciato un tweet capace di far digrignare i denti a più di un ingegnere software. Diceva: "Oggi mi sono svegliato e mi sono reso conto che l'AI è ormai abbastanza brava da farmi chiudere l'editor per sempre e non guardare mai più una riga di codice."

Quando l'ho letto ho pensato: ok, questo di sicuro sta esagerando. Ma poi ha risposto Peter Levels, probabilmente il creatore indipendente più influente al mondo — e a quel punto la cosa si è fatta seria.

Da oltre un decennio costruisce prodotti da solo, generando milioni di dollari all'anno. Non esattamente uno che scherza.

Peter ha risposto: "Credo di non aver aperto il mio IDE o editor di codice da 12 mesi. Claude Code fa il 95% del lavoro direttamente sul mio server." E dietro di lui hanno iniziato a comparire decine di persone che raccontavano esattamente la stessa storia.

Uno schema diverso 🧩

Mi sono messo a indagare e anche qui ho trovato uno schema molto chiaro, ma completamente diverso dal primo. Se il primo schieramento era fatto di ingegneri veterani — ex dipendenti di Uber, Stripe e altri colossi della Silicon Valley — questo secondo gruppo era fatto di indie hacker e founder, spesso "solo founder", cioè creatori indipendenti a tutti gli effetti.

Persone che costruiscono prodotti da sole, senza cercare investimenti esterni, facendoli crescere con le proprie forze. Molti di loro non avevano mai lavorato in grandi team di ingegneria, eppure erano tra i creatori che generavano più soldi in assoluto. Ed è lì che ho capito che questa discussione non era mai stata davvero sul leggere il codice: riguardava qualcosa di molto più profondo.

I primi stavano ottimizzando per l'affidabilità, i secondi per la velocità. I veterani hanno la responsabilità di mantenere sistemi usati da milioni di persone: fanno parte di un team più ampio, che li paga proprio perché non si può permettere di lasciar passare errori capaci di danneggiare gli altri.

Un team che si fida del tuo giudizio proprio perché quegli errori non arrivino mai in produzione. L'altro schieramento, invece, ha la responsabilità di scoprire se un'idea funziona prima di restare senza tempo o senza soldi. Lavorando generalmente da soli, non sentono quel peso: possono spingere una modifica e sistemare tutto subito, direttamente sul server o persino in produzione.

E quando l'ho capito, ho smesso di chiedermi chi avesse ragione e ho iniziato a chiedermi come siamo arrivati fin qui.

Come siamo arrivati fin qui? 🤔

Appena due anni fa nessuno di noi stava discutendo se leggere il codice o no. La discussione era molto più semplice: l'IA non era nemmeno in grado di scrivere codice.

All'inizio scrivevo ancora il 100% del mio codice e l'AI era appena un copilota.

Nel 2021 GitHub Copilot compariva ogni tanto: era ancora una technical preview su invito che suggeriva la riga successiva o autocompletava una funzione — ma la tastiera restava completamente mia. Non a caso, l'anno seguente GitHub stessa, in una ricerca interna, avrebbe misurato che con Copilot i task venivano completati più velocemente e gli sviluppatori si sentivano più soddisfatti del proprio lavoro: il seme di questo dibattito era già lì, solo molto più piccolo.

Poi sono passato a scrivere solo l'80% del mio codice.

Arriva la chat dentro l'editor. Non scrivevo più solo codice: ora facevo anche domande, direttamente al mio editor: "Come dovrebbe essere fatto questo?" Oppure: "Perché fallisce questo frammento di codice?" Eppure, restava il mio codice.

Un po' di tempo dopo sono passato a scrivere solo il 30% del mio codice.

Mi hanno spostato dal mio IDE a uno nuovo chiamato Cursor, ed è lì che è avvenuto il vero cambiamento. Non dicevo più "scrivi questa funzione", ora dicevo: "fai tutta questa modifica al posto mio".

Avevo ancora la responsabilità di accettare o rifiutare le nuove modifiche. Dovevo ancora leggere e capire cosa avesse scritto l'agente, finché non è arrivato il giorno in cui ho finito per scrivere lo 0% del mio codice.

Mi hanno spostato di nuovo, questa volta da Cursor, l'editor a cui mi stavo appena abituando, e mi hanno detto: "Sai una cosa? Non hai più bisogno di vedere il codice".

"Sai, ti presento Claude Code". Improvvisamente mi sono ritrovato a parlare con un robot in un terminale — non uno solo, ma due, fino a dieci agenti insieme. Loro scrivevano, eseguivano, testavano, correggevano, riprovavano al posto mio.

Mi sono sentito come se mi avessero tolto il volante della macchina che avevo sempre guidato e mi avessero detto: "Non ti preoccupare, ci penso io al posto tuo".

Non ho lasciato il volante 🚗

C'è però una terza voce che ho scoperto solo dopo, ed è quella che mi ha fatto smettere di pensare a questo come a uno scontro tra due squadre.

Robert C. Martin — Uncle Bob, l'uomo che per vent'anni ci ha ripetuto che il codice si legge molto più spesso di quanto si scriva — ha dichiarato pubblicamente che con i suoi agenti non legge più una riga di quello che producono. La stessa frase di Peter Steinberger, detta però da chi ha scritto "The Clean Coder" — il libro dove Martin spiegava che un professionista non manda mai in produzione codice che non ha testato, che il TDD non è un'opzione ma una best practice.

Solo che, guardando meglio, Bob non ha smesso di fare code review. L'ha spostata. È la lettura che ne dà Emilio Carrión, staff engineer a Mercadona Tech, in una riflessione pubblicata poco dopo il tweet: Bob non guarda più la sintassi, guarda le specifiche che scrive a mano prima, i vincoli che impone (test, metriche, mutation testing) e il collaudo finale che fa lui stesso dopo. Come scrive Carrión, "no hemos soltado el volante, hemos subido el nivel al que conducimos" — non abbiamo lasciato il volante, abbiamo solo alzato il livello a cui guidiamo.

Il giudizio non è sparito, si è solo spostato ai due estremi della pipeline — esattamente il principio dietro strumenti come OpenSpec, dove l'allineamento tra umano e AI si costruisce nella specifica, prima ancora che esista una riga di codice da leggere o non leggere.

Ed è qui che i due schieramenti da cui sono partito smettono di sembrare opposti. I veterani come Hashimoto leggono perché non hanno ancora costruito l'infrastruttura di vincoli che renderebbe superflua quella lettura. Gli indie hacker come Levels non leggono perché il costo di un errore, per loro, è basso e reversibile. Bob non legge perché ha passato anni a spostare quella responsabilità altrove, in un sistema di verifica che lavora al posto suo. Tre strategie diverse, non tre gradi di pigrizia: ognuna ottimizzata per un rischio diverso.

Forse la vera domanda, tra un anno, non sarà più "il codice lo leggi ancora?" ma "dove hai messo il tuo giudizio?" — nel codice, nei vincoli, o nella specifica. E se non lo sai ancora, va bene: lo sto ancora capendo anch'io.

🔗Sitografia

2021

[0] Dave Gershgorn, GitHub and OpenAI launch a new AI tool that generates its own code, TheVerge, 29/06/2021

2022

[0] Eirini Kalliamvakou, Research: quantifying GitHub Copilot’s impact on developer productivity and happiness, Github Blog, 07/09/2022 (Updated 21/05/2024)

2023

[0] Yacine, I left stripe to build stuff, Medium, 16/05/2023

2026

[0] Emilio Carrión, Soltar el volante, Blog, 26/07/2026

📺Videografia

2026

[0] The Pragmatic Engineer, The creator of OpenClaw: "I ship code I don't read", Youtube, 28/01/2026

[1] Midudev, No reviso el código de la IA" - Uncle bob, Youtube, 31/07/2026