Il debito tecnico nell’uso dell’AI può emergere quando devi modificare codice che funziona, ma che il team non sa spiegare. “Fra due anni” è un modo per guardare alla manutenzione futura, non una scadenza prevista da uno studio. La domanda che mi interessa è: chi saprà ricostruire il motivo delle scelte?
Generare codice e comprenderlo sono due attività
Un assistente può proporre una modifica, e i test possono passare. Prima del rilascio rimane una domanda: abbiamo verificato che il comportamento sia quello richiesto e che il codice sia sostenibile nel nostro progetto? La review formale non risponde da sola.
Non lo attribuirei a una categoria di sviluppatori. È un rischio del processo: se accettiamo modifiche più velocemente di quanto riusciamo a valutarle, la comprensione può restare indietro. Non serve assumere un aumento di produttività uguale per tutti per riconoscere il problema.
Cognitive debt: un debito che non si vede nei test
Qui uso “debito di comprensione” per descrivere codice che il team fatica a spiegare e modificare. È una chiave di lettura del problema, non un indicatore standard o un risultato attribuito a ricerche non citate. Può accompagnare il debito tecnico anche quando la funzione sembra corretta.
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.
Uno scenario di manutenzione da usare come prova
Immagina un collega che entra in un progetto e chiede perché una funzione aggiorni i dati in un certo ordine. Questo è uno scenario ipotetico, non il racconto di un onboarding realmente avvenuto.
Il codice è leggibile e i test passano, ma non è chiaro quale vincolo abbia motivato la sequenza. Prima di cambiarla, il team deve ricostruire comportamento, alternative e conseguenze. È qui che l’assenza di contesto diventa lavoro concreto.
Userei questa prova durante la review: qualcuno riesce a spiegare cosa succede, perché e cosa potrebbe rompersi? Se manca una risposta, può servire una verifica, una nota di progetto o un test più significativo. Non necessariamente un refactor.
Una pratica da provare: leggere il diff senza generare altro
Una proposta semplice è dedicare una sessione alla lettura del diff prima di chiedere altre modifiche all’assistente. L’obiettivo è separare comprensione e produzione: dati in ingresso, effetti, errori, dipendenze e ragioni della soluzione.
La durata dipende dalla modifica. Non la trasformerei in un rituale cronometrato: una correzione piccola e un cambio di architettura richiedono attenzioni diverse. Conta che la revisione risponda ai rischi reali.
Il mestiere che cambia: da scrittori a revisori
Nell’uso degli assistenti, una parte del lavoro si sposta verso valutazione e verifica delle proposte. Non significa che progettazione e scrittura scompaiano: rimane la responsabilità di capire il sistema che stiamo cambiando.
Anche la revisione automatica ha limiti: GitHub segnala problemi mancati e falsi positivi, raccomandando una verifica umana delle osservazioni di Copilot. È un motivo per usare la review AI come supporto, non come prova conclusiva. Fonte: limiti degli agenti GitHub Copilot.
Nel mio lavoro uso l’AI per costruire e ragionare sui prodotti. Non ho la pretesa che esista una formula definitiva: mi interessa capire quali pratiche rendano il codice più facile da modificare anche per chi arriva dopo.
La skill che (forse) varrà di più: leggere lentamente
Penso che saper leggere con attenzione diventi ancora più importante quando generare una proposta è facile. È una valutazione personale: il valore sta nel riconoscere ipotesi errate, vincoli nascosti e conseguenze prima di accettare la modifica.
- Leggi il diff in relazione al comportamento richiesto.
- Spiega a un collega perché la soluzione rispetta i vincoli.
- Documenta le motivazioni non evidenti, senza dare per scontato che l’AI le ricostruisca.
- Usa le domande di chi entra nel progetto per individuare il contesto mancante.
Cosa fare oggi nel tuo team
Questi sono spunti operativi da adattare al team e alla criticità delle modifiche:
- Individua le aree importanti che nessuno sa spiegare con sicurezza.
- Rivedi le modifiche prima del rilascio e verifica i comportamenti critici.
- Documenta vincoli e motivazioni nei punti dove non sono ricavabili dal codice.
- Usa le domande di manutenzione e onboarding per migliorare test e documentazione.
Una domanda aperta
Alla quantità di codice affiancherei una domanda sulla manutenzione: quanto è difficile capire e modificare ciò che abbiamo accettato? Non è un argomento contro l’AI. È un modo per valutare il lavoro oltre la prima versione che sembra funzionare.
Nel tuo team, chi sa spiegare le parti più importanti del sistema? Se quella persona non fosse disponibile, dove trovereste le ragioni delle scelte? È una domanda utile oggi, senza aspettare che si presenti un problema.
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.
Fonti
Scritto da
Matteo Lucrezio
Startupper | Lead Software Engineer