Nel mondo del software moderno, è emerso un nuovo tipo di lavoratore: un'intelligenza artificiale capace di scrivere codice, correggere errori e costruire programmi autonomamente. Questi sistemi, spesso chiamati agenti di codifica, sono stati addestrati su vaste librerie di istruzioni scritte da esseri umani e hanno dimostrato una straordinaria abilità in linguaggi di programmazione general-purpose come Python. Possono risolvere enigmi che un tempo richiedevano ore per essere decifrati dagli ingegneri umani. Tuttavia, il mondo reale del software aziendale è raramente così semplice. Gran parte delle infrastrutture critiche che gestiscono il commercio globale si basa su linguaggi specializzati progettati per settori specifici, dove le regole sono diverse, gli strumenti sono unici e la posta in gioco è alta. Uno di questi ambienti è il mondo dei sistemi di pianificazione delle risorse aziendali (ERP), dove le aziende gestiscono tutto, dall'inventario alla gestione delle paghe. Qui, il software parla un linguaggio chiamato AL, un dialetto specializzato utilizzato per gestire il sistema Business Central di Microsoft. Per anni, è rimasto il dubbio se questi potenti agenti di IA potessero navigare in questo panorama complesso e proprietario o se il loro successo nella programmazione generale fosse un fenomeno destinato a svanire di fronte alle reali restrizioni aziendali.

Per rispondere a questa domanda, i ricercatori di Microsoft hanno creato un nuovo banco di prova chiamato BC-Bench. Non hanno inventato un enigma teorico; al contrario, hanno scavato nel codice reale e vivo di due enormi repository software che alimentano vere attività commerciali. Da questi archivi digitali, hanno selezionato con cura 101 compiti specifici che gli ingegneri avevano risolto in passato. Non si trattava di esempi inventati, ma di problemi reali: un bug che causava il fallimento di un record cliente, una funzione mancante in un report di vendita o un test che doveva essere scritto per intercettare un errore. I ricercatori hanno poi chiesto a diversi dei più avanzati agenti di IA al mondo di tentare questi stessi compiti. Agenti ricevevano la descrizione originale del problema, che talvolta includeva screenshot dell'errore, e uno snapshot del codice così come esisteva prima della correzione. Il loro obiettivo era scrivere esattamente le modifiche al codice necessarie per risolvere il problema, proprio come farebbe un ingegnere umano. Il sistema eseguiva poi il software in un ambiente simulato per vedere se il nuovo codice risolvesse effettivamente il problema senza rompere nient'altro.

I risultati hanno rivelato un panorama in cui l'identità del modello di IA contava molto più dello strumento specifico utilizzato per svolgere il lavoro. Quando i ricercatori hanno confrontato diverse versioni degli agenti, hanno scoperto che la scelta del "cervello" sottostante — il grande modello linguistico — aveva un impatto molto maggiore sul successo rispetto alla scelta del "wrapper" software, o "harness", che lo guidava. Ad esempio, uno dei modelli più recenti, Claude Opus 4.6, ha risolto quasi il 69 percento dei compiti di correzione dei bug quando accoppiato con uno strumento standard, mentre una versione precedente dello stesso modello ne ha risolti solo circa il 58 percento. Al contrario, sostituire lo strumento mantenendo invariato il modello ha prodotto differenze minime e statisticamente insignificanti. Ciò suggerisce che, per questi complessi compiti aziendali, l'intelligenza del modello sia il principale motore del successo, non l'interfaccia specifica attraverso cui accede al codice.

La scoperta più sorprendente è stata che i miglioramenti osservati nei test di codifica generale non si traducono automaticamente in questo mondo specializzato. Nel mondo più ampio dell'ingegneria del software, i modelli più recenti mostrano spesso progressi costanti e prevedibili rispetto ai loro predecessori. Eppure, in questo specifico ambiente aziendale, un modello che aveva recentemente superato il suo predecessore nei benchmark generali non ha mostrato lo stesso vantaggio qui. Un modello che era migliorato significativamente nei compiti generici non ha performato meglio del suo predecessore quando affrontato con questi enigmi di logica aziendale. Ciò indica che le competenze richieste per correggere uno script Python generico non sono le stesse necessarie per correggere un calcolo finanziario in un sistema aziendale specializzato. La natura specializzata del linguaggio, con le sue regole rigide su come fluiscono i dati e come viene validata la logica aziendale, crea una barriera che l'addestramento generale non può facilmente superare.

I ricercatori hanno anche esaminato da vicino il motivo per cui gli agenti fallivano. Hanno scoperto che le macchine raramente fallivano perché non riuscivano a costruire il software o perché il codice non compilava; tali ostacoli tecnici venivano superati facilmente. Inveve, i fallimenti riguardavano quasi sempre la comprensione del problema. In quasi la metà dei tentativi falliti, l'agente guardava la parte sbagliata del codice, modificando file che non avevano nulla a che fare con l'errore. In un altro grande gruppo di fallimenti, l'agente trovava il file giusto e la sezione di codice corretta, ma applicava comunque la logica errata, implementando una soluzione che sembrava corretta ma che non risolveva effettivamente la regola aziendale. Ad esempio, un agente poteva identificare correttamente che mancava il numero d'ordine di un cliente, ma poi scriveva codice che assegnava il tipo di numero sbagliato, lasciando il sistema guasto. Questi errori suggeriscono che gli agenti faticano a navigare nella profonda e interconnessa rete di regole aziendali che definiscono il funzionamento di un'azienda, perdendo spesso il contesto sottile che un ingegnere umano coglierebbe immediatamente.

Anche la complessità del compito giocava un ruolo decisivo. Quando la correzione richiedeva la modifica di un solo file o di un piccolo numero di righe, gli agenti erano piuttosto efficaci. Tuttavia, non appena la soluzione richiedeva la modifica di più file o la scrittura di più di qualche decina di righe di codice, il tasso di successo diminuiva drasticamente. Questo calo è stato netto, con l'accuratezza che è scesa di oltre venti punti percentuali quando il compito coinvolgeva più di un file. Sembra che, sebbene questi agenti possano gestire piccole riparazioni isolate, abbiano ancora difficoltà a coordinare i cambiamenti all'interno di un sistema ampio e interconnesso. Inoltre, il tipo di area aziendale era rilevante: gli agenti sono stati più efficaci nel correggere problemi nella gestione dell'inventario rispetto alla logistica di magazzino, suggerendo che i loro dati di addestramento potrebbero essere più ricchi in alcuni domini aziendali rispetto ad altri.

Lo studio conclude che, sebbene l'intelligenza artificiale abbia compiuto passi da gigante nella codifica generale, il percorso verso un'ingegneria completamente autonoma negli ambienti aziendali specializzati non è ancora chiaro. Gli strumenti esistono e i modelli sono potenti, ma il divario tra capacità generale e padronanza specifica del dominio rimane ampio. I ricercatori sottolineano che, per progredire, l'industria deve concentrarsi su questi benchmark specializzati piuttosto che affidarsi a test generici. Evidenziano inoltre che i limiti attuali non riguardano solo l'intelligenza pura, ma la capacità di comprendere il contesto, navigare in codebase complesse e applicare la corretta logica aziendale. Man mano che questi sistemi evolvono, la speranza è che possano eventualmente imparare a navigare nelle intricate regole del software aziendale con la stessa facilità che mostrano ora nella programmazione generale, ma per ora, l'ingegnere umano rimane essenziale per guidarli attraverso le complessità del mondo reale.