Il debito tecnico AI non è il bug del giorno dopo. È il bug fra due anni — quello che esce quando qualcuno aprirà un file scritto oggi a quattro mani con un assistente, dovrà cambiarlo, e non troverà nessuno che sappia spiegargli perché lì è stato fatto così.
Stiamo scrivendo più codice che mai. Lo sta leggendo qualcuno?
Negli ultimi sei mesi mi sono accorto di un'abitudine che si è insinuata nei team con cui lavoro. Si genera codice, si fanno passare i test, si manda in produzione. La review formale c'è. La lettura attenta, sempre meno.
È un cambio sottile, e non riguarda i "vibe coder cattivi". Riguarda persone serie, con anni di esperienza, che si trovano a gestire un volume di output triplicato e cercano scorciatoie ragionevoli. Non è pigrizia: è una conseguenza meccanica del fatto che oggi l'output di un developer è quasi disaccoppiato dal tempo che ha per pensare a quell'output.
Cognitive debt: un debito che non si vede nei test
Le ricerche che stanno girando nel 2026 lo chiamano cognitive debt: un debito di comprensione che non emerge nei test ed esce fuori in manutenzione. È diverso dal debito tecnico classico — quello fatto di scorciatoie architetturali consapevoli. Qui il problema è che nessuno, dentro al team, ha più una rappresentazione mentale completa di porzioni di codebase scritte negli ultimi mesi.
Il codice c'è, è in produzione, gira. Ma se domani la persona che ha fatto la prompt-and-merge se ne va, quel pezzo diventa una specie di scatola nera dentro casa nostra. Funziona finché funziona.
L'aneddoto: tre file che non sapevo spiegare
Tre settimane fa ho fatto fare l'onboarding a un nuovo dev su una codebase che conoscevo bene. O così pensavo.
Mentre gliela mostravo, mi sono accorto che almeno tre file non riuscivo a spiegarli davvero. Erano stati scritti negli ultimi sei mesi, con un AI assistant, in fretta. I test passavano. La logica funzionava. Ma il "perché qui ho scelto questo pattern e non un altro", non lo sapevo dire.
Era codice mio. Era stato pensato in qualche misura. Ma il filo del ragionamento — quello che permette a un altro dev di lavorarci sopra — era saltato. Ho passato due ore a riaprirli con calma. Non a riscriverli: a capirli di nuovo, per me e per chi sarebbe arrivato dopo.
Una piccola disciplina: 30 minuti di lettura senza tastiera
Mi sono dato una regola che, finora, sto rispettando solo a metà: il giorno in cui scrivo codice con l'AI, nello stesso giorno mi tolgo 30 minuti per rileggerlo da solo, senza altri tab aperti. Non come review tecnica. Come comprensione mia.
Sembra una banalità. In un mondo che ti spinge a generare di più ogni settimana, è la cosa che trovo più difficile da difendere. Quando ho una sprint piena, la prima cosa che salta è proprio quel mezzora di lettura silenziosa — che è esattamente la cosa che dovrei salvare per prima.
Il mestiere che cambia: da scrittori a revisori
C'è una cosa che si dice poco, nei team di sviluppo del 2026. Stiamo cambiando la natura di quello che facciamo, e non abbiamo ancora un nome stabile per la nuova versione del mestiere.
Per anni il valore di un developer si è misurato in larga parte sulla capacità di scrivere codice. Velocità, qualità, eleganza. Era un mestiere artigianale. Adesso il codice lo scrive in larga parte un'altra cosa, e noi siamo sempre di più revisori, orchestratori, garanti. Una professione diversa, ma con la stessa firma in fondo al file — e con la stessa responsabilità quando le cose si rompono.
Mi sembra che ci sia un'intera generazione di mid-level che si sta rendendo conto solo adesso di questa trasformazione. Io stesso, a 20 anni, sono in mezzo a un mestiere che sta cambiando troppo in fretta — e non ho la pretesa di averlo capito tutto. Ho qualche osservazione e molte domande aperte.
La skill che (forse) varrà di più: leggere lentamente
Ho il sospetto che la skill che varrà di più nei prossimi anni sia leggere lentamente, non scrivere velocemente. Posso sbagliarmi — e lo dico senza ironia, perché è una previsione fragile. Ma se l'output di codice diventa sostanzialmente gratuito, l'asset scarso non è più la generazione: è la comprensione.
- Lettura lenta del diff: prima di mergiare, leggi il diff come se fosse un articolo, non come se fosse una checklist.
- Spiegabilità a voce: prova a raccontare a un collega perché hai scelto una soluzione e non un'altra. Se non ci riesci, fermati.
- Documentazione del *perché*: i commenti utili nell'era AI non spiegano cosa fa il codice — quello l'AI lo capisce. Spiegano perché è stato scritto in quel modo.
- Onboarding come stress test: ogni volta che fai onboarding a un nuovo dev, segna i file che non sai spiegare. Sono il tuo backlog di comprensione.
Cosa fare oggi nel tuo team
Non ho una ricetta. Ho qualche pratica che sto provando io e qualcuna che vedo funzionare nei team con cui lavoro. Le metto giù come spunti, non come verità.
- Identificare i "file orfani": pezzi di codebase scritti con AI che nessuno saprebbe spiegare a voce. Farne una mappa, anche grezza.
- Riservare tempo settimanale alla lettura — non alla review, alla lettura. Mezz'ora a settimana di codice altrui (e proprio) letto senza intenzione di toccarlo.
- Riscrivere i commenti dei file più critici concentrandoli sul perché delle scelte, non sul cosa fa il codice.
- Trattare l'onboarding di un nuovo dev come un audit: usare le sue domande per scoprire dove la nostra comprensione ha buchi.
Una domanda aperta
Vorrei che si parlasse di più di questa trasformazione, e meno della "produttività triplicata". La produttività di adesso si paga in qualche misura sulle prossime generazioni di chi dovrà manutenere quello che stiamo costruendo oggi. Non è un argomento contro l'AI nel codice — io la uso ogni giorno. È un invito a tenere d'occhio la metrica giusta.
Nel tuo team, chi è la persona che capisce davvero il codice che l'AI produce? Cosa succede se domani se ne va? È una domanda banale e per questo facile da rimandare. Ma è la domanda che, fra due anni, distinguerà i team che hanno costruito qualcosa di solido da quelli che si ritroveranno con una codebase che funziona e che nessuno sa più leggere.
Se hai un'esperienza concreta su questo tema — un onboarding andato male, una pratica di lettura che ti funziona, un disastro di manutenzione — scrivimi su LinkedIn. Sto raccogliendo casi reali, non opinioni.