Molte aziende vivono con applicazioni interne che non osano più toccare. Il codice funziona ma si basa su una tecnologia obsoleta che non è più mantenuta. Non ci sono più aggiornamenti di sicurezza, e quindi le vulnerabilità si accumulano (le password sono memorizzate con MD5 senza salting per esempio). Se la questione di un aggiornamento tecnico si è posta regolarmente, il passo non è mai stato compiuto e il debito si è accumulato. La codebase dell'azienda è quindi conservata senza essere mantenuta, in mancanza di meglio.
Tuttavia, il 16 luglio 2026, l'azienda americana Anthropic ha
annunciato di aver riscritto integralmente
Bun in Rust con l'aiuto del suo Large Language Model Claude. Nell'era dell'IA generativa, l'equilibrio è cambiato. Per i sistemi multi-agente e gli ultimi Large Language Model, la scala della codebase è stata raggiunta. La
migrazione di un backend di 100.000 righe di codice da parte di modelli di IA è un compito
accessibile in
due settimane.
L'obiettivo della migrazione è molteplice: si aggiorna lo stack tecnico, ci si assicura che la migrazione cambi solo la sintassi (e non il comportamento) del codice, e si rilevano al passaggio bug o vulnerabilità. La migrazione si svolge nel modo seguente:
Si mappano gli endpoint del codice legacy: questi sono i punti d'ingresso da cui si avvia la migrazione
Per ciascuno degli endpoint, agenti IA generano test per costruire un “Golden master”
Si procede quindi alla migrazione del codice vero e proprio, con workflow IA che rispettano una logica di percorso in profondità per ogni endpoint
Ogni agente itera affinché il codice migrato rispetti esattamente i test del Golden master
I diversi workflow vengono ricomposti per fattorizzare il codice e rilevare errori di compilazione
Alla fine, si ottiene un rapporto che descrive i bug rilevati dai diversi agenti e i test a cui si è volontariamente derogato (perché si trattava di bug che non si sono voluti riprodurre)
Garantire un comportamento identico
Come assicurarsi della
esattezza della migrazione ? È l'idea del metodo del
Golden master. Affinché il comportamento sia lo stesso, è necessario che ogni richiesta abbia la stessa risposta, anche se si tratta di un errore 500 (internal server error). È necessario che tutte le risposte, inclusi bug ed errori, persistano nello stesso stato, prima e dopo la migrazione. Questi errori devono essere segnalati, ma è necessario che la correzione di ciascuno sia controllata.
Il cambiamento di comportamento deve rimanere un'eccezione. È quindi necessario scrivere
un massimo di test : test unitari, test di integrazione e test end-to-end. Testare anche la gestione degli errori e dei casi patologici.
Per rafforzare la robustezza e la pertinenza dei test, si adotta una struttura “avversariale” : un agente attaccante e uno difensore. L'attaccante ha accesso solo ai contratti delle funzioni (quali argomenti accetta? cosa restituisce? a cosa serve?). Il suo obiettivo è scrivere test: gli happy path, ma anche e soprattutto i casi patologici. D'altra parte, l'agente difensore è colui che è responsabile della migrazione vera e propria. Sarà quindi necessario che il difensore iteri se necessario finché la migrazione non soddisfi i test che l'attaccante avrà generato.
L'idea dietro questa struttura attaccante/difensore è impedire il fenomeno di compiacenza (
sycophancy) degli agenti IA nella scrittura dei test. Non dando all'attaccante altro che i contratti e non il codice delle funzioni che deve testare, si evita che i test siano tautologici e che siano solo la trascrizione del codice.
Scrivere test è anche un'assicurazione per il futuro : in caso di aggiunta di funzionalità future, test robusti ed esaustivi già presenti permettono di assicurarsi della compatibilità delle modifiche con il resto dell'applicazione.
Migrare la tua codebase
Per la migrazione, il sistema multi-agente è architettato nel modo seguente: un orchestratore genera sotto-agenti per migrare ciascuno degli endpoint. Ha anche il ruolo di fattorizzare il codice e di mettere in comune i risultati alla fine della migrazione.
Ogni sotto-agente ha la responsabilità di un endpoint. Deve trascriverlo nel nuovo linguaggio. Ad esempio, presso Galadrim, un modello Model-View-Controller (
MVC) in NET 4.8 è stato migrato verso un backend in .NET 9 e un frontend in React.
Claude Code, dell'azienda Anthropic, è un framework efficace per questo tipo di compito: un agente principale (l'orchestratore) genera automaticamente i sotto-agenti incaricati della scrittura dei test e della migrazione. Procediamo per ondate: a ogni ondata, 3 sotto-agenti sono incaricati di migrare gli endpoint. Ogni sotto-agente ha la responsabilità di un gruppo di endpoint (ad esempio, quattro endpoint CRUD fanno parte dello stesso gruppo, che un sotto-agente dovrà migrare).
Potrebbe essere necessario, per far girare una codebase vecchia, utilizzare una VM Windows (è il caso del .NET 4.8 per esempio) al fine di generare i test end-to-end. Gli agenti incaricati di generare i test si connettono quindi automaticamente alla VM per inviare la richiesta e recuperare la risposta del legacy per costruire il Golden Master.
Una volta terminate tutte le ondate di migrazione, l'orchestratore è incaricato di ricomporre i pezzi e di fattorizzare il codice. È il caso in particolare se delle funzioni sono state duplicate durante la migrazione perché necessarie per più endpoint. È anche l'occasione per verificare che non ci siano problemi di compilazione (che la semplificazione potrebbe causare) e che l'applicazione migrata si avvii correttamente.
Rilevare bug e vulnerabilità di sicurezza
Scandagliando il codice di test, si possono anche rilevare bug maggiori passati sotto silenzio finora, e di falle di sicurezza. Ad esempio, abbiamo scoperto nell'applicazione legacy che un endpoint era esposto pubblicamente, senza necessità di autenticazione (a differenza di tutti gli altri), e quindi che i dati a cui dava accesso potevano essere letti senza restrizioni. Un passaggio esaustivo nel codice permette anche di rilevare codice morto, che non servirebbe e che inquinerebbe il resto. Questo può manifestarsi in particolare con tabelle presenti nel database ma che sono invisibili all'applicazione perché inutilizzate.
In sintesi, fare la migrazione della tua codebase con l'aiuto di un sistema multi-agente, è da un lato aggiornare il tuo codice per garantirne la manutenibilità e la velocità, ma è anche rilevare al passaggio irischi di sicurezza e i bug maggiori presenti in un codice che non è più mantenuto.
Bilancio: con l'IA, due settimane per migrare la tua codebase
Quanto costerebbe un progetto del genere? La migrazione manuale costerebbe decine o addirittura centinaia di migliaia di euro e richiederebbe diversi mesi. È per questo motivo che le codebase non evolvono e rimangono nello stesso stato a lungo termine.
L'approccio multi-agente, al contrario, riduce drasticamente gli ordini di grandezza. In Galadrim, convertiamo un backend di 120 000 lignes in due settimane. Con il modello Opus 4.8 di Anthropic, gli ordini di grandezza sono i seguenti:
2,5 milliards de tokens (per la maggior parte dei token di cache, meno costosi dei token di input o di output)
1 800 $ di costo API
4 000 tests generati
40 ore di inferenza circa, parallelizzate per la maggior parte (quando 3 agenti girano per 1h in parallelo, questo rappresenta 3h di inferenza per 1h di tempo reale)
