Cos'è un AI code smell?

L'AI code smell è un difetto ricorrente nel codice scritto da un modello di linguaggio o da un agente: non un errore che blocca la compilazione, ma un pattern che compila, passa i test e costa caro in manutenzione. Sono la firma riconoscibile della macchina: eccezioni generiche, funzioni lunghissime, codice morto, numeri magici, import inesistenti in rami mai eseguiti. Non sono difetti nuovi: sono i code smell del catalogo di Fowler, con una frequenza diversa. Uno studio su quattro modelli mostra che il codice generato ne contiene il 63,34 per cento in più rispetto a una baseline umana (Ghosh Paul et al., 2025), e una rilevazione trova almeno un difetto nel 60,9 per cento delle unità generate, con il metodo troppo lungo al 40 per cento (Sousa e colleghi, ENIAC 2025). Riconoscerli serve a stimare la bonifica prima di accettare il codice: il conto arriva comunque, solo dopo.

Leggi anche: Debito tecnico · La metafora di Ward Cunningham: ogni scorciatoia nel codice è un prestito, e gli interessi si pagano a ogni modifica successiva.

I pattern che ritornano

Il catalogo classico ritorna: eccezioni gestite in modo generico; codice morto e rami mai eseguiti; numeri magici al posto di costanti con nome; funzioni lunghissime che fanno dieci cose insieme. A questi si aggiungono i difetti nativi: import di librerie che non esistono, mascherati in rami mai eseguiti e inventati per far tornare il codice, e il Modular Mirage, cioè file ben separati senza coesione logica, con una correlazione di 0,94 tra righe generate e difetti architetturali (Zhu, Tsantalis e Rigby, 2026). La misura conferma: su due modelli diffusi, dieci difetti su tredici superano le soglie di rilevamento (CodeSmellEval, Velasco et al., 2024), e un analizzatore statico ne rileva ventidue specifici del machine learning su 890 sistemi Python (SpecDetect4ML, Mahmoudi et al., 2025). Lo stesso gruppo di CodeSmellEval usa quella metrica per un'analisi causale: contano strategia di generazione, dimensione e architettura del modello e formulazione del prompt, e i fattori decisivi sono prompt e architettura (Velasco et al., 2025). I dati dei fornitori, da leggere come tali, concordano: Veracode e Apiiro vedono più difetti nel codice generato, CodeRabbit, su 470 pull request, conta in quelle scritte con l'AI circa 1,7 volte i problemi segnalati in quelle scritte solo da persone.

Un esempio enterprise

Una PMI manifatturiera chiede la stima per il rescue di un gestionale da ventimila righe, in parte scritte da un agente su istruzioni del fornitore precedente. La demo funzionava. L'analisi trova il quadro tipico: tre funzioni oltre le cinquecento righe, eccezioni catturate in modo generico e ignorate nei moduli, un connettore che importa una libreria inesistente e neutralizzato con un ramo morto, soglie scritte come numeri magici e credenziali hardcoded nel sorgente. La stima separa due voci: ciò che si tiene e si copre con test, e ciò che si riscrive perché modificarlo costerebbe più che riscriverlo. È la differenza che questa voce mette in un preventivo: senza il nome dei pattern, la bonifica resta una riga generica che il cliente legge come ricarico.

Perché conta per chi decide

Chi valuta un rescue o un'acquisizione deve prevedere la bonifica, o il costo emerge dopo la firma. Questi difetti rientrano nel debito tecnico, che resta la cornice, ma sono concentrati e misurabili: un analizzatore statico ne intercetta la parte visibile nella forma, si contano e si datano al commit che li ha introdotti; l'attribuzione richiede la policy di dichiarazione sotto descritta. La difesa non è vietare gli assistenti, ma governarli: una policy sui contributi generati dice cosa entra nel repository e con quale dichiarazione, il controllo in pipeline li intercetta prima del merge, e la revisione umana resta sull'architettura, dove il modello sbaglia di più. Il resto del vicinato va tenuto distinto: il vibe coding è farsi scrivere il codice conversando, l'AI slop è l'output mediocre in generale, gli strumenti di analisi restano il mezzo, non la diagnosi.