# Debito Tecnico dell'IA: Due Problemi Diversi, Non Uno

URL: https://codebasechat.com/it/journal/debito-tecnico-ia
Type: blog
Locale: it
Published: 2026-07-14
Updated: 2026-07-14

---

> Il debito tecnico dell'IA non è solo codice duplicato. La metà più pericolosa è invisibile: il debito cognitivo, il gap tra velocità di generazione e comprensione del team.

Affrontare il debito tecnico IA richiede di separare due problemi completamente diversi. Il primo è il debito di codice: duplicazione, pattern inconsistenti, codice che aggiunge superficie di attacco. Il secondo è il debito cognitivo: il gap tra quanto velocemente il codice viene generato e quanto velocemente il team capisce cosa fa. La maggior parte dei team non misura nemmeno il secondo.

## Il Debito Tecnico dell'IA È Due Problemi Diversi, Non Uno

Chiedi a cinque engineering manager di definire il debito tecnico dell'IA e ricevi cinque risposte, ma tendono a raggrupparsi in due categorie molto diverse.

La prima è il debito di codice: duplicazione, pattern inconsistenti, codice tecnicamente corretto ma che aggiunge superficie di attacco che nessuno ha chiesto. Questo è il settore per il quale i tool di analisi statica sono stati costruiti.

La seconda è il debito cognitivo: il gap tra la velocità con cui il codice viene generato e la velocità con cui il team costruisce davvero un modello mentale condiviso di cosa fa. L'indagine Sonar del 2026 "State of Code" ha trovato che l'88% degli sviluppatori segnala almeno un impatto negativo dell'IA sul debito tecnico, e il 53% dice che l'IA genera codice che sembra corretto ma nasconde difetti. Questo è debito di codice. Quello che l'indagine non cattura completamente è il secondo tipo, e la reportistica di LeadDev sul concetto è il trattamento più chiaro che abbiamo letto.

Tre team su cinque confondono i due. Ecco cosa fanno gli altri due diversamente: tracciavano il debito di codice con tool, e tracciavano il debito cognitivo con conversazioni.

## La Parte del Debito di Codice: Codice Che Sembra Giusto e Non Lo È

Il debito di codice è il tipo familiare. Il codice generato dall'IA tende a duplicare la logica che già esiste tre file più avanti, perché l'assistente non sa che la logica esiste a meno che non sia in context. L'indagine di Sonar mette un numero su di esso: il 40% degli sviluppatori dice che l'IA ha aumentato il debito generando codice non necessario o duplicato.

La variante pericolosa non è il codice che sembra sbagliato. È il codice che sembra giusto. Una funzione passa i suoi test, gestisce l'happy path in modo pulito, e legge come qualcosa che uno senior engineer avrebbe scritto, eccetto che silenziosamente butta via un edge case che l'implementazione originale gestiva. La review becca gli errori di digitazione. La review è molto peggio nel beccare una funzione plausibile che è sottilmente incompleta.

`// Generato dall'IA: passa i test, sembra pulito
function getActiveUsers(users) {
  return users.filter(u => u.status === "active");
}

// Cosa l'originale gestiva, tre file più avanti:
function getActiveUsers(users) {
  return users.filter(u => u.status === "active" && !u.deletedAt);
}`Niente qui butta un errore. Niente fallisce la CI. Il gap appare solo quando un utente soft-deleted riappare in un report tre settimane dopo, e chiunque viene chiamato deve grep, blame, e chiedere in giro per trovare quale versione è corretta e perché. Questo loop grep-e-chiedi è il costo vero, ed è misurabile in ore, non in un vago senso che qualcosa non va.

Tool di docs-as-code che si siedono accanto al repo piuttosto che in un wiki separato riducono quanto spesso quel loop succede, perché il reasoning dietro una funzione vive un click lontano dalla funzione stessa invece che nella memoria di qualcuno.

![Primo piano di mani su una tastiera con un diff rosso e verde visibile sul schermo sfocato dietro](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/eaeaef-inline1.webp)

## La Parte del Debito Cognitivo: Quando il Team Perde il Filo

Dr. Margaret-Anne Storey, professoressa di computer science all'University of Victoria, ha coniato "debito cognitivo" in ottobre 2025 dopo aver osservato i suoi studenti shippare velocemente con l'IA e poi lottare per agire sul loro stesso feedback utente. Sua diagnosi: gli studenti non avevano perso la traccia del codice, avevano perso la traccia di cosa stavano costruendo e perché, e chi nel team sapeva cosa.

Questo framing prende in prestito dal vecchio argomento di Peter Naur che il software non è veramente il codice, è la teoria condivisa nelle teste delle persone che l'hanno costruito. Quando il codice viene generato più velocemente di quanto il team possa costruire quella teoria, la teoria non si forma mai. Puoi avere una codebase pulita e completamente testata e comunque avere un debito cognitivo significativo se le persone che l'hanno shippata non riescono a spiegarlo completamente, o se solo una persona può.

Questa è la parte che le metriche standard di debito tecnico dell'IA mancano completamente, perché i dashboard tracciano il codice, non la comprensione. La domanda che vale la pena fare nella tua prossima retro è diretta: metti su un diagramma dell'architettura, e chiedi chi nel team può spiegare ogni box. Se la risposta è "una persona, e è in vacanza questa settimana," hai debito cognitivo indipendentemente da quello che dice il tuo linter.

Un wiki interno vivo non risolve il debito cognitivo da solo. Dà al team un posto dove scrivere il "perché" prima che viva solo nella testa di una persona, che è un inizio.

![Tre ingegneri in piedi di fronte a una lavagna che disegnano un diagramma dell'architettura di un sistema insieme](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/e90110-inline2.webp)

## Perché la Code Review Non Riesce a Stare al Passo Con la Velocità di Generazione

Ecco il problema meccanico sottostante entrambi i tipi di debito: l'IA permette a un singolo ingegnere di generare una settimana di codice prima di pranzo, ma la capacità di review non è scalata affatto. Il collo di bottiglia si è spostato dallo scrivere al leggere, e leggere è la parte che nessuno ha accelerato.

Questo è dove il confronto dei tool veramente importa, e vale la pena essere specifico invece di vago. Copilot e Cursor sono veloci nel generare codice dentro il file che hai già aperto, che è esattamente perché sono bravi nel produrre più codice di quanto un team possa revieware. Cody e Continue.dev si appoggiano di più sul retrieval attraverso il repo prima di generare, che aiuta ad evitare il problema di duplicazione sopra, ma nessuno sostituisce il passo umano di decidere se il nuovo codice si adatta a come il sistema è supposto funzionare. Nessuno di loro ti dice se la persona che sta mergendo il PR veramente capisce cosa è cambiato, che è una domanda diversa da se il diff è sintatticamente fine.

Tool di ask-your-codebase esistono specificamente per questo gap: il modo più veloce di revieware il codice generato dall'IA bene è essere in grado di chiedere, in linguaggio naturale, "dove altrove esiste questo pattern" o "cosa già gestisce questo caso," prima che appruvi il merge. Quella domanda soleva prendere a un ingegnere senior venti minuti di grep e blame. Non dovrebbe.

C'è anche un effetto sulla dimensione del repo che vale la pena nominare. Su un servizio di 5.000 righe, un reviewer può tenere la maggior parte del sistema nella loro testa, così una funzione plausibile si distingue perché non corrisponde al modello mentale del reviewer. Su un monorepo di 80.000 righe toccato da sei team, nessun reviewer singolo ha più quel modello mentale, così il codice plausibile passa semplicemente perché nessuno nella sala ha il contesto per notare che è sbagliato. Più grande il repo, più il collo di bottiglia di review dipende dai tool invece che dalla memoria di un ingegnere senior.

## I Junior Pagano Questo Debito Per Primo, E Più Velocemente

Anthropic ha gestito uno studio controllato a gennaio 2026, un trial randomizzato con 52 sviluppatori junior, e ha trovato che quelli che usavano assistenti IA hanno segnato il 17% più basso nei test di comprensione del codice, circa due gradi in meno. Il team di ingegneria interna di Infobip, gestendo un programma di stage dal 2022 attraverso 225 stage, ha visto lo stesso pattern nei dati longitudinali reali: le coorti pre-IA sono cresciute di una media di 2,50 punti in abilità tecnica auto-valutata durante uno stage; le coorti dell'era IA sono cresciute di 1,56.

Il meccanismo non è l'uso dell'IA stesso. Due stage nella più recente coorte di Infobip hanno usato l'IA alla stessa frequenza, con risultati opposti. Uno ha fatto domande di follow-up e ha potuto spiegare completamente quello che l'IA ha prodotto; la loro crescita è stata la più alta della coorte. L'altro ha accettato l'output con revisione minima, l'ha trattato come una black box, e ha cresciuto di zero. Il tool era identico. La relazione con esso non era.

Registrare le sessioni di pairing e i walkthrough dell'architettura, e renderli ricercabili dopo, dà ai junior qualcosa a cui tornare invece di ri-chiedere la stessa domanda a chiunque sia libero. Non sostituirà un mentor, ma abbassa il costo di chiedere due volte.

![Un ingegnere senior che punta a uno schermo di laptop mentre un ingegnere junior si piega per seguire](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/ec3aa0-inline3.webp)

## Salta il Fix "Ban IA per i Junior"

Ogni roundup su questo argomento finisce per sbarcare sulla stessa raccomandazione eventualmente: ristrivi l'accesso all'IA per gli ingegneri junior finché non l'hanno "guadagnato." Salta quella. Non corrisponde a quello che i team che hanno veramente misurato il problema hanno trovato, e scambia una modalità di fallimento con un'altra; i junior che non possono usare i tool che il loro team shippare con cadono indietro in un modo diverso, altrettanto reale.

Quello che ha funzionato per Infobip invece era sequenziamento, non banning: prova il problema prima, verifica con l'IA secondo, così l'abitudine del pensiero indipendente si forma prima che l'IA diventi la mossa di default. Hanno aggiunto checkpoint senza IA, non come punizione ma come calibrazione, così sia lo stage che il mentor sanno dove l'abilità veramente sta. I mentor hanno anche spostato da reviewing i pull request a tracciare il processo: chi ha chiesto cosa, chi è rimasto bloccato dove, chi ha spiegato il suo stesso cambio senza aiuto.

I punteggi di soddisfazione sono saliti tutto il tempo mentre la crescita delle abilità stava cadendo, che è il vero avvertimento nei loro dati: se sei solo tracciando come le persone si sentono riguardo ai tool, non vedrai questo venire. Il venti percento degli stage nella più recente coorte di Infobip non sapeva cosa era aspettato di uno junior engineer al loro livello nel primo posto, che ha reso l'auto-valutazione quasi senza significato. Non puoi misurare un gap contro un punto di riferimento che nessuno ha scritto.

## Cosa Cambieremmo Realmente Questo Sprint

Inizia con la domanda di retro sopra: chi può spiegare ogni parte del sistema, ad alta voce, adesso. Quella singola domanda surfaccia più debito cognitivo in dieci minuti di quanto qualsiasi dashboard farà.

Per il debito di codice, mantieni l'analisi statica nel loop. L'indagine Sonar del 2026 mostra il 70% degli sviluppatori lo usa già, e i team che lo eseguono riportano risultati significativamente migliori sui costi di rework dei team che lo saltano. Non è una raccomandazione controversa, è solo una che i team saltano quando si muovono velocemente perché l'output dell'IA sembrava fatto.

Il fatica che l'IA rimuove dallo scrivere il codice non scompare. Sonar chiama questo il "grande shift di fatica": riappare downstream, nella gestione del debito e nella correzione dell'output dell'IA. Automatizzare le parti ricorrenti di quel triage, flaggare i PR stantii, routare le richieste di review, inseguire i follow-up, libera il tempo senior per la parte che veramente richiede un umano: decidere se il team capisce quello che ha appena shippato.

Misura la traiettoria, non la soddisfazione. Un team che si sente bene riguardo all'IA e non riesca a spiegare la sua stessa architettura in sei mesi non ha risparmiato tempo. L'ha preso in prestito, a un tasso che nessuno ha scritto.

## FAQ

### Qual è la differenza tra debito di codice e debito cognitivo?

Il debito di codice è codice duplicato o pattern inconsistenti che un linter può rilevare. Il debito cognitivo è il gap tra quanto velocemente l'IA genera codice e quanto velocemente il team costruisce una comprensione condivisa di cosa fa. Il primo è un problema di tooling; il secondo è un problema di team.

### Come misuro il debito cognitivo del mio team?

Chiedi nella prossima retro: 'Chi può spiegare ogni box di questo diagramma architetturale?' Se la risposta è 'una persona, e è in vacanza,' hai debito cognitivo significativo indipendentemente da quello che dice il linter.

### L'IA nuoce agli junior developer?

Non è l'IA in sé — è come la usi. Gli studi mostrano che i junior che chiedono follow-up e capiscono l'output crescono quanto i loro pari. Quelli che accettano output senza revisione crescono zero. Il sequenziamento (prova il problema prima, poi IA) funziona meglio del banning.

### Dovrei vietare l'IA ai developer junior?

No. I team che misurano davvero hanno trovato che il sequenziamento funziona meglio del banning: prova il problema indipendentemente, poi usa l'IA per verificare. Aggiungi checkpoint senza IA come calibrazione, non come punizione.

### Come evito il debito tecnico dell'IA?

Per il debito di codice: mantieni l'analisi statica nel loop (70% dei developer già lo usa). Per il debito cognitivo: registra i pairing e i walkthrough, rendili ricercabili, e misura la traiettoria di comprensione, non solo la soddisfazione.

### Qual è il 'grande shift di fatica' di cui parla Sonar?

La fatica rimossa dalla scrittura di codice riappare nella gestione del debito e nella correzione dell'output dell'IA. Automatizzare le parti ricorrenti di questo triage (flagging PR stantii, routing review, chase follow-up) libera tempo senior per decidere se il team capisce quello che ha appena shippato.