800,000 Lines of Code Rewritten with AI: Is Software Migration Changing?

Migrating a large software system from one technology to another has always been an expensive, slow, and high-risk process. It is not simply a matter of translating code from one programming language into another. The system’s behavior, integrations, performance, security, and compatibility with the products that depend on it must all be preserved.

The use of Artificial Intelligence is changing the scale at which such projects can be carried out.

On September 16, 2026, with an update published on September 23, GitHub explained how Copilot was used to rewrite its runtime from TypeScript to Rust. The result included more than 800,000 lines of production Rust, integrated through 128 pull requests. According to GitHub, most of the code was written by AI agents, while the migration was completed gradually rather than through a single replacement of the entire system.

This case demonstrates that AI-powered software migration is no longer merely an experiment involving small code fragments. Coding agents can participate in the transformation of large systems, but the outcome still depends on architecture, testing, and human oversight.

Migration Is Not Simply Code Translation

When a system moves from TypeScript to Rust, the process cannot be reduced to replacing one syntax with another.

The two languages have different execution models, memory management approaches, methods for handling state, and ways of organizing dependencies. A translated function may produce the same result in a simple test but behave differently when interacting with other components.

For this reason, large migrations require more than code generation. Teams must understand the purpose of each component, its contract with the rest of the system, and the behavior that must be preserved after the change.

AI Coding Agents can accelerate the production of new code, but they do not eliminate the need to understand the existing system.

Why GitHub Moved the Runtime to Rust

The GitHub Copilot runtime was originally built with TypeScript, Node.js, and the V8 engine. This architecture had supported the rapid development of the product, but it created limitations when the runtime needed to be used across different products and environments.

According to GitHub, using it through the SDK required launching a separate process that hosted Node.js and V8. This introduced additional memory consumption, inter-process communication, and more elements that needed to be monitored.

Rust was chosen to create a runtime with fewer dependencies, more predictable resource usage, and the ability to be embedded directly into applications written in different languages.

However, this decision does not mean that every TypeScript application should be migrated to Rust. The choice of technology must be connected to the system’s specific requirements, the objectives of the migration, and the long-term cost of maintenance.

AI Agents Make a Different Scale of Work Possible

One of the most important aspects of this project is its scale.

The initial migration was estimated on the basis of approximately 130,000 lines of TypeScript, but the system continued to evolve while the migration was underway. In the end, approximately 430,000 lines of TypeScript passed through the process, while the new runtime reached more than 832,000 lines of production Rust.

In a traditional project, a transformation of this scale could have required a large team and a much longer period. GitHub explains that the work was completed primarily by one developer within a few months, with the help of GitHub Copilot and coding agents, while the rest of the team continued developing new capabilities.

This does not mean that AI completed the migration independently. The agents produced a large portion of the code, but the project still required a technical strategy, an ordered sequence of components, clear instructions, and continuous verification.

Incremental Migration Reduced the Risk of Change

GitHub did not build an entirely new system and replace the old one in a single step.

The migration was completed component by component. Each pull request replaced part of the TypeScript implementation with its corresponding Rust version. In this way, the project’s main branch remained functional, and new versions could be tested throughout the process.

This approach made each change smaller, easier to understand, and simpler to review. When a problem appeared, it could be connected to a limited set of changes and corrected without analyzing the entire migration.

For large projects, this is one of the most important lessons. AI can produce code quickly, but changes must be divided into units that can be reviewed, tested, and reversed if necessary.

Tests Become the Contract for System Behavior

When code is rewritten in another language, the central question is not whether the new version resembles the old one. The question is whether it preserves the same behavior.

For this reason, the existing tests played a central role in the migration. End-to-end tests were run against the new Rust components at every stage. If a change failed to meet the defined requirements, it was not integrated into the main branch.

In AI-powered software migration, tests are not used only to identify errors. They provide both the agent and the team with a verifiable definition of the behavior that must be preserved.

As the automation of code generation increases, the quality of the tests becomes even more important. If the tests are incomplete, generated code may pass the checks without guaranteeing that the system will function correctly in real-world situations.

Regressions Do Not Disappear Simply Because AI Produces the Code

During the migration, regressions related to correctness and performance were discovered. Some were identified during development, others in prerelease versions, and some only after the changes had reached wider use.

This demonstrates that rapid code generation does not eliminate risk. An agent may create an implementation that appears correct, passes a set of tests, and still changes the system’s behavior in a scenario that was not anticipated.

Verification must therefore include more than automated testing. Code review, performance analysis, post-release monitoring, and mechanisms for connecting problems to the changes that caused them are also required.

AI can shorten implementation time, but responsibility for the quality of the system remains with the team that designs and approves the change.

The Architecture Must Be Prepared for Migration

Before the most complex part of the runtime was translated, the project was divided into more manageable components.

Elements containing pure logic and no shared state were handled first. More interconnected components, such as session orchestration, were left for later stages, after the patterns for integration, testing, and communication between TypeScript and Rust had been proven.

This shows that the success of a migration does not depend only on the ability of AI to write code. It also depends on how the architecture divides the system into parts that can be transformed without interrupting the entire product.

A system with clear boundaries between components is easier to migrate, regardless of whether the work is carried out by people or with the help of AI agents.

Coding Speed Is Not the Same as Migration Speed

AI agents can rapidly produce a large amount of code. However, a migration is complete only when the new code has been tested, integrated, released, and proven in real-world use.

If generation moves faster than the team’s capacity to review the changes, a new bottleneck is created. Code review, testing, and regression analysis can become the slowest parts of the process.

This means productivity should not be measured only by the number of lines produced. It should be measured by the number of components migrated safely, the problems prevented, and the real improvements achieved in performance, maintainability, and stability.

In this model, AI increases implementation capacity, while the developer must maintain the balance between speed and reliability.

The Developer’s Role Shifts Toward Strategy and Verification

In a traditional migration, a large portion of the time may be spent manually rewriting repetitive functions and structures.

When this work is supported by AI Coding Agents, the developer can focus more on sequencing the migration, defining architectural boundaries, selecting the tests, and analyzing cases in which the two implementations do not behave in the same way.

This makes the developer’s role less focused on manually producing every line of code and more focused on directing the technical transformation.

However, to perform this role, the developer must understand the system in depth. Without knowledge of the architecture, execution models, and product requirements, it becomes difficult to determine whether the generated code is genuinely suitable.

AI-Powered Migration Requires Documented Accountability

For Soft&Solution Group, the use of AI in large migrations should be accompanied by a clear accountability process.

For every component, it should be possible to determine why it is being migrated, which instructions were given to the agent, which tests were used, which changes were approved, and how its behavior was monitored after release.

This documented history becomes particularly important when code is generated at scale. Without traceability, the team may find it difficult to understand why a decision was made or which change caused a problem.

As Ermal Beqiri, founder of Soft&Solution Group, explains:

“Artificial Intelligence can significantly accelerate the rewriting of a system, but migration is not measured by the number of lines produced. It is measured by the behavior that is preserved, the problems that are prevented, and the confidence with which the new system enters production. The agent may write the code, but the architecture, oversight, and accountability must remain clear.”

The rewriting of the GitHub Copilot runtime demonstrates that AI agents can also be used in software transformations of a scale that would previously have required considerably more time and resources.

However, the main lesson is not that AI can produce 800,000 lines of code. The lesson is that such a migration becomes possible when automation is combined with careful system decomposition, continuous testing, incremental releases, and human oversight.

AI-powered software migration does not remove complexity. It changes the way that complexity is managed.