800.000 righe di codice riscritte con l’AI: la migrazione del software sta cambiando?

La migrazione di un grande sistema software da una tecnologia a un’altra è sempre stata un processo costoso, lento e ad alto rischio. Non si tratta semplicemente di tradurre il codice da un linguaggio di programmazione a un altro. È necessario preservare il comportamento del sistema, le integrazioni, le prestazioni, la sicurezza e la compatibilità con i prodotti che dipendono da esso.

L’utilizzo dell’Intelligenza Artificiale sta cambiando la scala con cui possono essere realizzati progetti di questo tipo.

Il 16 settembre 2026, con un aggiornamento pubblicato il 23 settembre, GitHub ha spiegato come Copilot sia stato utilizzato per riscrivere il proprio runtime da TypeScript a Rust. Il risultato comprendeva più di 800.000 righe di Rust utilizzate in produzione e integrate attraverso 128 pull request. Secondo GitHub, la maggior parte del codice è stata scritta da agenti AI, mentre la migrazione è stata realizzata progressivamente e non attraverso la sostituzione completa del sistema in un’unica operazione.

Questo caso dimostra che la migrazione del software con l’AI non è più soltanto un esperimento che riguarda piccoli frammenti di codice. Gli agenti di programmazione possono partecipare alla trasformazione di grandi sistemi, ma il risultato continua a dipendere dall’architettura, dai test e dalla supervisione umana.

La migrazione non consiste semplicemente nella traduzione del codice

Quando un sistema passa da TypeScript a Rust, il processo non può essere ridotto alla sostituzione di una sintassi con un’altra.

I due linguaggi presentano modelli di esecuzione, metodi di gestione della memoria, modalità di gestione dello stato e sistemi di organizzazione delle dipendenze differenti. Una funzione tradotta può produrre lo stesso risultato in un test semplice, ma comportarsi diversamente quando interagisce con altri componenti.

Proprio per questo motivo, le migrazioni di grandi dimensioni richiedono più della semplice generazione di codice. È necessario comprendere lo scopo di ogni componente, il suo contratto con il resto del sistema e il comportamento che deve essere preservato dopo la modifica.

Gli agenti AI di programmazione possono accelerare la produzione del nuovo codice, ma non eliminano la necessità di comprendere il sistema esistente.

Perché GitHub ha trasferito il runtime a Rust

Il runtime di GitHub Copilot era stato inizialmente sviluppato con TypeScript, Node.js e il motore V8. Questa architettura aveva favorito lo sviluppo rapido del prodotto, ma creava alcuni limiti quando il runtime doveva essere utilizzato in prodotti e ambienti differenti.

Secondo GitHub, il suo utilizzo attraverso l’SDK richiedeva l’avvio di un processo separato che eseguiva Node.js e V8. Ciò comportava un consumo aggiuntivo di memoria, comunicazioni tra processi e un maggior numero di elementi da monitorare.

Rust è stato scelto per creare un runtime con meno dipendenze, un utilizzo più prevedibile delle risorse e la possibilità di essere integrato direttamente in applicazioni scritte in linguaggi diversi.

Tuttavia, questa decisione non significa che tutte le applicazioni TypeScript debbano essere migrate a Rust. La scelta della tecnologia deve essere collegata ai requisiti concreti del sistema, agli obiettivi della migrazione e ai costi di manutenzione a lungo termine.

Gli agenti AI rendono possibile una diversa scala di lavoro

Uno degli elementi più importanti di questo progetto è la sua portata.

La migrazione iniziale era stata stimata sulla base di circa 130.000 righe di TypeScript, ma il sistema continuava a evolversi mentre la migrazione era in corso. Alla fine, circa 430.000 righe di TypeScript sono passate attraverso il processo, mentre il nuovo runtime ha raggiunto più di 832.000 righe di Rust utilizzate in produzione.

In un progetto tradizionale, una trasformazione di queste dimensioni avrebbe potuto richiedere un team numeroso e un periodo molto più lungo. GitHub spiega che il lavoro è stato realizzato principalmente da uno sviluppatore nell’arco di pochi mesi, con l’aiuto di GitHub Copilot e degli agenti di programmazione, mentre il resto del team continuava a sviluppare nuove funzionalità.

Ciò non significa che l’AI abbia realizzato la migrazione in modo indipendente. Gli agenti hanno prodotto una parte significativa del codice, ma il progetto richiedeva comunque una strategia tecnica, un ordine preciso per la gestione dei componenti, istruzioni chiare e una verifica continua.

La migrazione progressiva ha ridotto i rischi del cambiamento

GitHub non ha costruito un sistema completamente nuovo per sostituire quello precedente in un’unica operazione.

La migrazione è stata realizzata componente per componente. Ogni pull request sostituiva una parte dell’implementazione in TypeScript con la corrispondente versione in Rust. In questo modo, il branch principale del progetto rimaneva funzionante e le nuove versioni potevano essere testate durante l’intero processo.

Questo approccio ha reso ogni modifica più limitata, più comprensibile e più facile da controllare. Quando emergeva un problema, poteva essere collegato a un insieme ristretto di modifiche e corretto senza dover analizzare l’intera migrazione.

Per i progetti di grandi dimensioni, questa è una delle lezioni più importanti. L’AI può produrre codice rapidamente, ma le modifiche devono essere suddivise in unità che possano essere esaminate, testate e annullate, se necessario.

I test diventano il contratto che definisce il comportamento del sistema

Quando il codice viene riscritto in un altro linguaggio, la domanda principale non è se la nuova versione assomigli a quella precedente. Bisogna stabilire se conserva lo stesso comportamento.

Per questo motivo, i test esistenti hanno svolto un ruolo centrale nella migrazione. I test end-to-end sono stati eseguiti sui nuovi componenti in Rust in ogni fase. Quando una modifica non rispettava i requisiti definiti, non veniva integrata nel branch principale.

Nella migrazione del software con l’AI, i test non servono soltanto a individuare gli errori. Forniscono all’agente e al team una definizione verificabile del comportamento che deve essere preservato.

Più la scrittura del codice viene automatizzata, più la qualità dei test diventa importante. Se i test sono incompleti, il codice generato può superare i controlli senza garantire che il sistema funzioni correttamente nelle situazioni reali.

Le regressioni non scompaiono semplicemente perché il codice è prodotto dall’AI

Durante la migrazione sono state individuate regressioni legate alla correttezza e alle prestazioni. Alcune sono state rilevate durante lo sviluppo, altre nelle versioni preliminari e alcune soltanto dopo che le modifiche erano state distribuite più ampiamente.

Questo dimostra che la generazione rapida del codice non elimina i rischi. Un agente può creare un’implementazione apparentemente corretta, superare una serie di test e modificare comunque il comportamento del sistema in una situazione che non era stata prevista.

La verifica deve quindi includere più della semplice esecuzione automatica dei test. Sono necessari anche la revisione del codice, l’analisi delle prestazioni, il monitoraggio successivo alla pubblicazione e meccanismi che permettano di collegare i problemi alle modifiche che li hanno provocati.

L’AI può ridurre i tempi di implementazione, ma la responsabilità della qualità del sistema rimane nelle mani del team che progetta e approva la modifica.

L’architettura deve essere preparata alla migrazione

Prima che venisse tradotta la parte più complessa del runtime, il progetto è stato suddiviso in componenti più facili da gestire.

Gli elementi caratterizzati da logica pura e privi di stato condiviso sono stati trattati per primi. I componenti più interdipendenti, come l’orchestrazione delle sessioni, sono stati riservati alle fasi successive, dopo la validazione dei modelli di integrazione, test e comunicazione tra TypeScript e Rust.

Questo dimostra che il successo di una migrazione non dipende soltanto dalla capacità dell’AI di scrivere codice. Dipende anche dal modo in cui l’architettura suddivide il sistema in parti che possono essere trasformate senza interrompere l’intero prodotto.

Un sistema con confini chiari tra i suoi componenti è più facile da migrare, indipendentemente dal fatto che il lavoro venga svolto dalle persone o con l’aiuto degli agenti AI.

La velocità di programmazione non equivale alla velocità di migrazione

Gli agenti AI possono produrre rapidamente una grande quantità di codice. Tuttavia, una migrazione si conclude soltanto quando il nuovo codice è stato testato, integrato, pubblicato e verificato in condizioni di utilizzo reali.

Se la generazione procede più rapidamente della capacità del team di controllare le modifiche, si crea un nuovo collo di bottiglia. La revisione del codice, i test e l’analisi delle regressioni possono diventare le parti più lente del processo.

Ciò significa che la produttività non deve essere misurata soltanto in base al numero di righe prodotte. Deve essere valutata in base ai componenti migrati in modo sicuro, ai problemi evitati e ai miglioramenti reali ottenuti nelle prestazioni, nella manutenzione e nella stabilità.

In questo modello, l’AI aumenta la capacità di implementazione, mentre lo sviluppatore deve mantenere l’equilibrio tra velocità e affidabilità.

Il ruolo dello sviluppatore si sposta verso la strategia e la verifica

In una migrazione tradizionale, una parte significativa del tempo può essere dedicata alla riscrittura manuale di funzioni e strutture ripetitive.

Quando questo lavoro viene supportato dagli agenti AI di programmazione, lo sviluppatore può concentrarsi maggiormente sull’ordine della migrazione, sulla definizione dei confini architetturali, sulla selezione dei test e sull’analisi delle situazioni in cui le due implementazioni non si comportano allo stesso modo.

Il suo ruolo diventa quindi meno incentrato sulla produzione manuale di ogni riga di codice e più orientato alla direzione della trasformazione tecnica.

Tuttavia, per svolgere questo ruolo, lo sviluppatore deve comprendere il sistema in profondità. Senza una conoscenza dell’architettura, dei modelli di esecuzione e dei requisiti del prodotto, diventa difficile stabilire se il codice generato sia realmente adeguato.

La migrazione con l’AI richiede una responsabilità documentata

Per ALSoft, l’utilizzo dell’AI nelle migrazioni di grandi dimensioni deve essere accompagnato da un processo chiaro di responsabilità.

Per ogni componente, è necessario sapere perché viene migrato, quali istruzioni sono state fornite all’agente, quali test sono stati utilizzati, quali modifiche sono state approvate e come è stato monitorato il suo comportamento dopo la pubblicazione.

Questa documentazione diventa particolarmente importante quando il codice viene generato su larga scala. Senza tracciabilità, il team può avere difficoltà a comprendere perché sia stata presa una decisione o quale modifica abbia provocato un problema.

Come spiega Ermal Beqiri, fondatore di ALSoft:

«L’Intelligenza Artificiale può accelerare notevolmente la riscrittura di un sistema, ma una migrazione non si misura dal numero di righe prodotte. Si misura dal comportamento preservato, dai problemi evitati e dal livello di affidabilità con cui il nuovo sistema viene introdotto in produzione. L’agente può scrivere il codice, ma l’architettura, il controllo e la responsabilità devono rimanere chiaramente definiti.»

La riscrittura del runtime di GitHub Copilot dimostra che gli agenti AI possono essere utilizzati anche in trasformazioni software di una portata che in precedenza avrebbe richiesto molto più tempo e molte più risorse.

Ma la lezione principale non è che l’AI possa produrre 800.000 righe di codice. La lezione è che una migrazione di questo tipo diventa possibile quando l’automazione viene combinata con una suddivisione accurata del sistema, test continui, pubblicazioni progressive e supervisione umana.

La migrazione del software con l’AI non elimina la complessità. Trasforma il modo in cui viene gestita.