Cos'è il debugging basato sull'AI?

Il 9 settembre 1947, gli ingegneri del computer Harvard Mark II trovarono una falena in uno dei suoi relè e la annotarono nel loro registro come “primo caso effettivo di individuazione di un 'bug' (letteralmente, insetto)”, una pagina ora conservata allo Smithsonian.¹ L'informatica Grace Hopper, membro del team del Mark II, rese famosa questa storia, sebbene il termine fosse già in uso prima di lei: Thomas Edison si lamentò dei “bug” in una lettera del 1878, e l'Oxford English Dictionary fa risalire questo uso ingegneristico agli anni '70 e '80 del XIX secolo.²

I bug ingegneristici si presentano in genere in tre tipologie.³ Gli errori di sintassi violano la grammatica di un linguaggio di programmazione (un esempio potrebbe essere una parentesi mancante) e vengono individuati prima che il programma venga eseguito. Gli errori di runtime si verificano quando un codice valido fallisce durante l'esecuzione, come nel caso della divisione per zero. Gli errori logici sono i più insidiosi: il programma funziona senza problemi ma fornisce un risultato errato.

Gli sviluppatori possono contrastarli con i test automatizzati (test unitari che verificano ogni piccolo frammento di codice rispetto ai risultati attesi) e con i debugger, che mettono in pausa un programma in esecuzione per consentirne l'ispezione. Un punto di interruzione (una riga contrassegnata in cui l'esecuzione si arresta) consente allo sviluppatore di rivedere il programma passo dopo passo, esaminando le variabili; il pdb integrato in Python ne è un tipico esempio. Un arresto completo del sistema produce solitamente una traccia dello stack, ovvero un resoconto delle chiamate alle funzioni che hanno portato all'errore.⁴

Uno studio del 2013 della Cambridge Judge Business School ha stimato che gli sviluppatori dedicano in media metà del loro tempo di programmazione alla ricerca e alla correzione dei bug, con un costo globale di circa 312 miliardi di dollari all'anno.⁵ La promessa del debugging assistito dall'AI, ovviamente, è ridurre tale costo.

Un LLM è un sistema di apprendimento automatico addestrato su enormi quantità di testo e codice per prevedere il “token” successivo (parola, parte di parola o simbolo): la stessa tecnologia di elaborazione del linguaggio naturale alla base dei chatbot AI come ChatGPT o Claude. Durante la fase di addestramento, il sistema ha effettivamente “letto” miliardi di righe di codice pubblico, oltre ai messaggi di errore, alle segnalazioni di bug e alle correzioni correlate. Quando un LLM arriva sul mercato, probabilmente ha già visto milioni di bug e ne ha assimilato le soluzioni. 

I dati di addestramento open-code documentati includono le conversazioni relative a “issue” e “pull request” su GitHub (registrazioni in cui gli sviluppatori segnalano bug e correzioni) fornendo a modelli appositamente addestrati l'accesso a una traccia documentale che mostra come il codice difettoso venga riparato dai programmatori umani.

In un comune workflow di debugging basato sull'AI, lo sviluppatore fornisce al modello il codice pertinente e il messaggio di errore o la traccia dello stack; il modello spiega quindi la causa probabile e suggerisce possibili soluzioni. I sistemi di ricerca come ChatDBG vanno oltre, collegando i modelli di linguaggio di grandi dimensioni (LLM) a debugger standard come GDB, LLDB e pdb di Python, in modo che uno sviluppatore possa porre domande in linguaggio naturale — “perché x è nullo?” — mentre il modello ispeziona il programma in esecuzione, esegue l'analisi delle cause principali e propone soluzioni.6.

Esistono alcune limitazioni di cui chi è alle prime armi con il debugging basato sull'AI dovrebbe essere consapevole. Innanzitutto, il contesto è fondamentale: una pratica associata al Prompt Engineering. I prompt vaghi tendono a produrre diagnosi vaghe; un approccio più utile consiste nel fornire l'errore esatto, il test fallito e un frammento di codice sospetto. Gli utenti devono inoltre tenere conto della finestra di contesto del modello: la quantità massima di testo (misurata in “token”, ovvero blocchi di pochi caratteri ciascuno) che un modello può considerare contemporaneamente. I bug reali nelle basi di codice complesse spesso si estendono su più file, come dimostra il benchmark SWE-bench relativo a problemi reali su GitHub, e un modello che non riesce a far rientrare tutto il codice rilevante nel proprio contesto potrebbe avere difficoltà a ragionarvi sopra.

Il debugging basato sull'AI avviene solitamente tramite assistenti di AI coding integrati nell'ambiente di codifica dello sviluppatore o costruiti attorno ad esso, tipicamente un ambiente di sviluppo integrato (o IDE). GitHub Copilot, ad esempio, è un assistente di programmazione in grado di suggerire codice all'interno di IDE popolari; Cursor e Windsurf sono ambienti di codifica orientati all'AI che pongono un'assistenza simile al centro dell'esperienza di programmazione.⁷ E man mano che l'ascesa dell'“ingegneria agentica” diventa la norma, alcuni software vengono progettati con la finestra di chat dell'assistente di codifica intesa come pannello principale in cui l'utente umano interagisce con l'IDE; questo è uno dei modi per utilizzare IBM Bob, tra gli altri.

Spesso gli assistenti di codifica sono indipendenti dal modello; GitHub Copilot, ad esempio, può utilizzare modelli di provider quali OpenAI, Anthropic e Google; anche xAI ha descritto il proprio modello Grok Code Fast 1 come progettato per i workflow degli agenti di codifica e disponibile tramite strumenti quali Copilot, Cursor e Windsurf.^{8 9} Da parte sua, IBM Bob utilizza vari modelli, indirizzando automaticamente le query al modello appropriato in base alla complessità e al costo; I materiali di presentazione del 2026 fanno riferimento a “un mix di modelli all'avanguardia, tra cui Anthropic Claude, i modelli open source Mistral e IBM Granite, insieme a modelli specializzati e ottimizzati per il ragionamento sul codice, la sicurezza e la previsione della modifica successiva.”

Alcuni agenti di debugging basati sull'AI sono generalisti; altri sono specialisti. Sul versante generalista, l'agente di codifica Copilot di GitHub, introdotto nel 2025, può ricevere in assegnazione un issue di GitHub, lavorare in background utilizzando GitHub Actions e inviare le modifiche proposte sotto forma di pull request (un pacchetto di modifiche al codice che uno sviluppatore umano dovrà revisionare).¹⁰ Con il suo mix di modelli, anche IBM Bob tende ad essere generalista. Sul versante specialista, si trova Copilot Autofix, che si concentra specificamente sulle vulnerabilità di sicurezza. Lo fa abbinando CodeQL, il motore di scansione del codice di GitHub, a spiegazioni generate dall'AI e a correzioni suggerite. Il risparmio di tempo può essere notevole; GitHub riporta un tempo medio di correzione di 28 minuti contro 1,5 ore se effettuato manualmente.¹¹

Sebbene impressionanti, i risultati all'avanguardia dell'AI generativa sono disomogenei. Un recente studio condotto da IBM su 2.000 amministratori delegati ha rilevato che solo il 25% delle iniziative di AI ha generato il ritorno sull'investimento previsto negli ultimi anni.

I risultati contrastanti valgono anche per il debugging basato sull'AI. In uno studio di DebugBench del 2024, i ricercatori hanno scoperto che i modelli closed-source erano ancora complessivamente inferiori alle prestazioni umane e che gli errori logici erano significativamente più difficili da correggere rispetto agli errori di sintassi e di riferimento.¹²

Tuttavia, strumenti migliori e più specializzati stanno migliorando le prospettive. ChatDBG, ad esempio, collega un LLM a un debugger in tempo reale, fornendo visibilità su ciò che il programma stava facendo esattamente al momento del malfunzionamento (anziché limitarsi al solo testo del codice sospetto). In una valutazione, una singola query su ChatDBG ha prodotto una soluzione attuabile per i programmi Python nel 67% dei casi; consentendo una sola domanda di approfondimento, la percentuale è salita all'85%.¹³

A complicare il quadro, i criteri di valutazione dei modelli cambiano continuamente. SWE-bench Pro, un successore più impegnativo del famoso SWE-bench¹⁴, è stato progettato per essere più realistico e resistente alla contaminazione; in una recente valutazione, i migliori modelli all'avanguardia sono rimasti al di sotto del 25%, con GPT-5 al 23,3%.¹⁵  

Il comportamento degli sviluppatori potrebbe cambiare più rapidamente di quanto sia possibile misurarlo scientificamente. Uno studio randomizzato condotto da METR all'inizio del 2025 ha rilevato che gli sviluppatori open source esperti impiegavano il 19% di tempo in più quando utilizzavano strumenti di AI, ma METR ha rapidamente definito quei risultati obsoleti; un seguito condotto nel 2026 ha trovato alcune prove di un'accelerazione della produttività, aggiungendo che tale accelerazione era difficile da misurare con precisione.¹⁶ La spiegazione fornita da METR riguardo a tale difficoltà è significativa: “Abbiamo osservato un aumento significativo degli sviluppatori che hanno scelto di non partecipare allo studio perché non desiderano lavorare senza l'AI, il che probabilmente distorce al ribasso la nostra stima dell'accelerazione assistita dall'AI.” 

Lo sviluppo e il debugging assistiti dall'AI non sono chiaramente destinati a scomparire. Ma per ora, gli strumenti di debugging basati sull'AI vanno probabilmente considerati come potenti assistenti, non come autopiloti affidabili. Sono in grado di spiegare le tracce dello stack, individuare errori di sintassi e redigere rapidamente bozze di patch. Tuttavia, i casi più difficili (errori logici, codebase complesse e codice sensibile dal punto di vista della sicurezza) richiedono ancora test, breakpoint e la revisione da parte di un esperto prima che la correzione venga integrata nella codebase.