L'AI non sa debuggare, parola di Microsoft

L'integrazione degli strumenti di IA nel processo di scrittura del codice rappresenta solo la punta dell'iceberg di un cambiamento più profondo, che vede gli sviluppatori dedicare sempre meno tempo alla scrittura pura e sempre più alla supervisione e ottimizzazione di codice generato automaticamente. Questa transizione, già in corso, sta ridefinendo il ruolo dello sviluppatore software e apre nuovi scenari sulla creazione di strumenti che possano migliorare non solo la generazione, ma anche il debugging del codice attraverso un'interazione intelligente con l'ambiente di sviluppo.

Le previsioni di Thomas Dohmke, CEO di GitHub, sono chiare e dirette: presto l'80% del codice sarà scritto da Copilot o strumenti simili. Non si tratta di una visione futuristica, ma di un processo già in atto. Garry Tan di Y Combinator ha rivelato che per un quarto delle startup della loro ultima serie, il 95% del codice è stato scritto da modelli linguistici di grandi dimensioni. Questo spostamento di paradigma ha profonde implicazioni sul ruolo dello sviluppatore.

In realtà, la maggior parte dei programmatori spende già oggi più tempo a correggere bug che a scrivere nuovo codice. Come manutentori di repository open-source popolari, molti sviluppatori trascorrono innumerevoli ore a risolvere problemi, esaminare pull request e correggere errori. La vera domanda diventa quindi: cosa succederebbe se un'intelligenza artificiale potesse proporre correzioni per centinaia di problemi aperti, lasciando agli sviluppatori solo il compito di approvarle prima dell'integrazione?

Questa prospettiva ha motivato i ricercatori a esplorare il potenziale degli strumenti di IA non solo nella generazione di codice, ma soprattutto nel debugging, ovvero quel processo interattivo e iterativo di identificazione e correzione degli errori che rappresenta la parte più impegnativa dello sviluppo software.

Gli attuali strumenti di IA per la programmazione aumentano certamente la produttività e sono eccellenti nel suggerire soluzioni per i bug basandosi sul codice disponibile e sui messaggi di errore. Tuttavia, a differenza degli sviluppatori umani, questi strumenti non cercano informazioni aggiuntive quando le soluzioni proposte falliscono, lasciando irrisolti alcuni problemi più complessi. Un semplice esempio di questa limitazione si manifesta quando una colonna di dati è etichettata in modo errato: l'IA resta bloccata senza la capacità di indagare oltre l'informazione iniziale fornita.

Debug-gym: un ambiente per insegnare all'IA a cercare attivamente le informazioni

Per superare queste limitazioni, è nato debug-gym, un ambiente che consente agli agenti di riparazione del codice di accedere a strumenti per un comportamento attivo di ricerca delle informazioni. Questa piattaforma espande lo spazio di azione e osservazione di un agente IA con feedback derivanti dall'uso di strumenti specializzati, permettendo di impostare punti di interruzione, navigare nel codice, stampare valori di variabili e creare funzioni di test.

Gli agenti possono interagire con questi strumenti per investigare il codice o riscriverlo quando sono sufficientemente sicuri della soluzione. Il debugging interattivo con strumenti appropriati può potenziare gli agenti di codifica nell'affrontare compiti reali di ingegneria del software, rappresentando un elemento centrale nella ricerca sugli agenti basati su modelli linguistici di grandi dimensioni (LLM).

Debug-gym è stato progettato per gestire informazioni a livello di repository, essere robusto e sicuro attraverso l'esecuzione del codice in container Docker isolati, facilmente estensibile con nuovi strumenti, e basato su testo per essere completamente compatibile con gli agenti moderni basati su LLM. Tra le caratteristiche più interessanti, vi è la possibilità di specificare un percorso di cartella per lavorare con qualsiasi repository personalizzato e valutare le prestazioni dell'agente di debugging.

Inoltre, debug-gym include tre benchmark di codifica per misurare le prestazioni degli agenti basati su LLM nel debugging interattivo: Aider per la generazione di codice a livello di funzione semplice, Mini-nightmare per esempi di codice difettoso brevi e creati manualmente, e SWE-bench per problemi di codifica reali che richiedono una comprensione completa di una base di codice di grandi dimensioni.

Dai primi esperimenti alle prospettive future

I primi esperimenti con debug-gym hanno fornito risultati promettenti ma anche evidenziato sfide significative. Un semplice agente basato su prompt è stato dotato di accesso a strumenti di debug come eval, view, pdb, rewrite e listdir, utilizzando nove diversi LLM come base. Anche con questi strumenti, l'agente raramente risolve più della metà dei problemi SWE-bench Lite.

Questa limitazione è probabilmente dovuta alla scarsità di dati che rappresentano comportamenti decisionali sequenziali (come le tracce di debugging) nel corpus di addestramento attuale degli LLM. Tuttavia, il significativo miglioramento delle prestazioni rispetto agli agenti privi di strumenti di debugging conferma che questa è una direzione di ricerca promettente.

Per il futuro, i ricercatori ritengono che l'addestramento o il fine-tuning degli LLM possa migliorare notevolmente le loro capacità di debugging interattivo. Questo richiederà dati specializzati, come i dati di traiettoria che registrano gli agenti che interagiscono con un debugger per raccogliere informazioni prima di suggerire una correzione. A differenza dei problemi di ragionamento convenzionali, il debugging interattivo comporta la generazione di azioni a ogni passo che innescano feedback dall'ambiente.