Un team di ricercatori del MIT ha mappato le sfide dell’AI nello sviluppo del software e ha delineato un programma di ricerca per la crescita del settore.
Un articolo dei ricercatori del Computer Science and Artificial Intelligence Laboratory (CSAIL) del MIT e di diverse istituzioni collaboratrici sostiene che il potenziale futuro dell’AI richiede uno sguardo attento alle sfide odierne. Intitolato “Sfide e percorsi verso l’intelligenza artificiale per l’ingegneria del software”, il lavoro mappa le numerose attività di ingegneria del software oltre alla generazione di codice, identifica gli attuali ostacoli e evidenzia le direzioni di ricerca per superarli, con l’obiettivo di consentire agli esseri umani di concentrarsi sulla progettazione di alto livello, mentre il lavoro di routine viene automatizzato.
Armando Solar-Lezama, professore di ingegneria elettrica e informatica al MIT, ricercatore principale del CSAIL e autore senior dello studio, sostiene che le narrazioni popolari spesso riducono l’ingegneria del software alla “parte di programmazione universitaria: qualcuno ti fornisce le specifiche per una piccola funzione e tu la implementi, o a risolvere colloqui di programmazione in stile LeetCode”. La pratica reale è molto più ampia. Include refactoring quotidiani che perfezionano il design, oltre a migrazioni radicali che spostano milioni di righe da COBOL a Java e rimodellano intere aziende. Richiede test e analisi continui – fuzzing, test basati sulle proprietà e altri metodi – per individuare bug di concorrenza o correggere falle zero-day. E comporta la manutenzione: documentare codice vecchio di dieci anni, riassumere le cronologie delle modifiche per i nuovi membri del team e rivedere le pull request per stile, prestazioni e sicurezza.
Gli aspetti dell’AI da migliorare
L’ottimizzazione del codice su scala industriale – si pensi alla ricalibrazione dei kernel GPU o agli incessanti perfezionamenti multilivello del motore V8 di Chrome – rimane ostinatamente difficile da valutare. Le metriche principali odierne sono state progettate per problemi brevi e autonomi e, sebbene i test a risposta multipla dominino ancora la ricerca sul linguaggio naturale, non sono mai stati la norma nell’intelligenza artificiale per il codice. Il parametro di riferimento de facto del settore, SWE-Bench, riguarda solo poche centinaia di righe di codice, rischia la fuga di dati dai repository pubblici e ignora altri contesti del mondo reale: refactoring assistiti dall’intelligenza artificiale, programmazione in coppia uomo-intelligenza artificiale o riscritture critiche per le prestazioni che si estendono su milioni di righe. Finché i benchmark non si espanderanno per catturare questi scenari ad alto rischio, misurare i progressi – e quindi accelerarli – rimarrà una sfida aperta.
Se la misurazione è un ostacolo, la comunicazione uomo-macchina è un altro. Il primo autore Alex Gu, laureato in ingegneria elettrica e informatica al MIT, vede l’interazione odierna come “una sottile linea di comunicazione”. Quando chiede a un sistema di generare codice, spesso riceve un file di grandi dimensioni e non strutturato e persino una serie di test unitari, ma questi test tendono a essere superficiali. Questa lacuna si estende alla capacità dell’IA di utilizzare efficacemente la più ampia gamma di strumenti di ingegneria del software, dai debugger agli analizzatori statici, su cui gli esseri umani fanno affidamento per un controllo preciso e una comprensione più approfondita. “Senza un canale attraverso cui l’IA possa esprimere la propria sicurezza – ‘questa parte è corretta… questa parte, forse ricontrolla’ – gli sviluppatori rischiano di fidarsi ciecamente di una logica allucinata che si compila, ma crolla in produzione. Un altro aspetto critico è che l’IA sappia quando rimettersi all’utente per chiarimenti” continua Gu.
La scalabilità aggrava queste difficoltà. Gli attuali modelli di IA hanno difficoltà con basi di codice di grandi dimensioni, che spesso si estendono su milioni di righe. I modelli di base apprendono dal GitHub pubblico, ma “la base di codice di ogni azienda è in un certo senso diversa e unica”, afferma Gu, rendendo le convenzioni di codifica proprietarie e i requisiti di specifica fondamentalmente esclusi dalla distribuzione. Il risultato è un codice che sembra plausibile ma che richiama funzioni inesistenti, viola le regole di stile interne o non supera le pipeline di integrazione continua. Questo porta spesso a un codice generato dall’IA che “allucina”, ovvero crea contenuti che sembrano plausibili ma non sono in linea con le convenzioni interne specifiche, le funzioni di supporto o i modelli architetturali di una determinata azienda. I modelli spesso vengono recuperati in modo errato, perché recuperano codice con un nome simile (sintassi) anziché funzionalità e logica, che è ciò di cui un modello potrebbe aver bisogno per sapere come scrivere la funzione.
Foto: AdobeStock