The Pulse

Microsoft descrive le migrazioni guidate dagli agenti in enormi basi di codice

Microsoft afferma che gli agenti di IA aiutano piccoli team a migrare basi di codice che si estendono per centinaia di milioni di righe, anche nell’ambito di lavori su Windows e Azure. Il suo approccio affianca alle modifiche automatizzate

AI.info Team · Scritto con l’IA · verificato · 2026-10-26

«Generare codice sta diventando la parte facile. La vera sfida è sapere se ci si può fidare.»

Sriram Rajamani, vicepresidente aziendale, Future of Scalable Software Engineering, CoreAI, Microsoft, e Tim Bozarth, vicepresidente aziendale, Eng Horizons, CoreAI & EngThrive, Microsoft

Piccoli team, migrazioni su vasta scala

Nel resoconto pubblicato il 26 ottobre sul lavoro di sviluppo software svolto con gli agenti, Microsoft descrive il passaggio dall’uso dei modelli linguistici come fasi di flussi di lavoro prestabiliti alla creazione di strumenti che gli agenti usano per pianificare ed eseguire le migrazioni. L’azienda afferma di applicare questo approccio a grandi basi di codice, tra cui quelle di Windows e Azure, dove le modifiche possono interessare centinaia di milioni di righe. Un esempio citato è la migrazione di 400 milioni di righe a una nuova toolchain di compilazione.

Microsoft definisce una migrazione come una modifica estesa a un’intera base di codice per raggiungere un obiettivo ingegneristico: aggiornare le dipendenze, adottare un compilatore, correggere i problemi rilevati dall’analisi statica o passare a una nuova piattaforma. Tra gli esempi che cita figurano il passaggio della base di codice di Windows, che descrive come composta da diverse centinaia di milioni di righe, alla toolchain Clang/LLVM; la risoluzione dei problemi rilevati da CodeQL, PREfast e dagli analizzatori Roslyn; e l’adattamento dei servizi da x86 ad ARM.

Invece di chiedere a migliaia di ingegneri di occuparsi delle correzioni nei rispettivi team, Microsoft sostiene che il lavoro dovrebbe essere guidato da un piccolo gruppo di esperti di migrazioni. Gli agenti esaminano un campione dei problemi rilevati e propongono una prima base di conoscenze su come risolverli. Un agente revisore valuta le correzioni proposte in base a correttezza, essenzialità, coerenza con le convenzioni dei singoli file e manutenibilità; gli esperti approvano le indicazioni, poi gli agenti le applicano all’intera base di codice.

Esaminare le regole, non ogni modifica

Questa organizzazione sposta la revisione umana verso le decisioni che stabiliscono o perfezionano le regole, oltre che verso i casi insoliti o ambigui. Microsoft afferma che il feedback dei revisori può migliorare la base di conoscenze, mentre raggruppare le correzioni simili facilita la valutazione delle modifiche ripetute. L’obiettivo dichiarato dell’azienda è evitare che un ingegnere debba esaminare singolarmente ogni modifica generata dagli agenti.

L’approccio dipende comunque dal giudizio delle persone sulla validità delle indicazioni e sulla necessità di prestare attenzione alle eccezioni. Un agente revisore può valutare una correzione in base a determinati criteri, ma queste valutazioni non dimostrano da sole che la modifica preservi il comportamento previsto di un sistema. L’attenzione di Microsoft ai test e ai metodi formali risponde a questa domanda più difficile.

La migrazione a Rust aggiunge controlli sul comportamento

Microsoft descrive anche gli sforzi per tradurre in Rust codice C e C++ preesistente. Il suo resoconto ripercorre i progressi compiuti: dal codice Rust che a gennaio 2025 non si compilava, a quello che entro giugno si compilava ma non funzionava correttamente o non superava i test. A settembre 2025, afferma l’azienda, i team avevano prodotto traduzioni funzionanti di circa 30.000 righe con indicazioni fornite manualmente; a partire da febbraio 2026, Microsoft afferma di aver iniziato a modernizzare grandi basi di codice con un notevole grado di automazione.

Microsoft preferisce tradurre una funzionalità alla volta anziché convertire un componente riga per riga. Ogni funzionalità rappresenta un comportamento visibile agli utenti che può essere verificato dall’inizio alla fine con test basati su scenari e dispone di un proprio controllo di validazione. I test differenziali confrontano i programmi originali e quelli tradotti, mentre i test non mostrati all’agente servono a verificare se la traduzione regge anche al di là degli esempi che ha visto durante lo sviluppo.

L’azienda afferma di aver anche iniziato a ricavare specifiche formali dal codice sorgente, a trasferirle in Rust e a usare Verus per dimostrare che il codice modernizzato le rispetta. Questi controlli forniscono ulteriori elementi di prova sulle proprietà definite; da soli, però, non dimostrano che tali proprietà comprendano tutti i requisiti che gli ingegneri intendevano far soddisfare al vecchio sistema.

Le specifiche possono ereditare vecchi errori

Microsoft individua direttamente questo limite nel suo articolo, parlando delle specifiche generate dagli agenti. Quando un agente deduce una specifica dal codice che dovrebbe controllare, la specifica può descrivere ciò che il programma già fa, anziché ciò che dovrebbe fare. L’azienda afferma che una discrepanza tra la traccia di un test e una specifica potrebbe indicare un difetto del codice, una specifica inesatta o un’ipotesi non valida alla base del test.

Per questo Microsoft presenta il lavoro come qualcosa di più della generazione automatizzata di codice: gli agenti possono proporre modifiche e contribuire a creare test o modelli formali, ma gli ingegneri devono comunque approvare le proprietà che questi strumenti usano per valutare il risultato. Il suo resoconto lascia aperta la questione di come i team debbano attribuire la responsabilità del codice quando gli agenti possono modificarlo oltre i confini tradizionali. La prova ingegneristica immediata è verificare se il piccolo gruppo di esperti riesce a convalidare le regole di migrazione e le eccezioni prima che tali regole vengano applicate a centinaia di milioni di righe.