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ì.
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.
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.
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.
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.
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.
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.
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à.
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.
Scritto da
Startupper | Lead Software Engineer