832,000 lines of code, one major migration and AI agents writing most of the implementation sounds like perfect material for a presentation called “We don’t need developers anymore”. Except GitHub’s own account tells a much more interesting story. This is not a story about giving an agent a repository on Friday and getting a finished system back on Monday. It is about how tightly each change had to be scoped, how much had to be tested, how often the team shipped in small pieces, and why a human still needed the authority to say: “No, green CI does not mean you were allowed to work around the problem.”

What GitHub actually rewrote

The project was the agent runtime, the execution layer behind GitHub Copilot CLI, the Copilot app and the Copilot SDK. This is not a single button or a small helper module. The runtime handles sessions, tools, permissions, communication and the other pieces agents need in order to carry out tasks.

Originally, it ran in TypeScript on Node.js and the V8 engine. GitHub wanted to reduce memory and process overhead, make the runtime easier to embed directly inside applications, and improve performance and resource predictability. Instead of building a second system alongside the old one and attempting one giant cutover at the end, the team chose to migrate it piece by piece.

WebsiteGarage / Services

Explore our services.

By 21 August, the production runtime was fully implemented in Rust. GitHub gives exact figures: 832,378 lines of production code, 468,689 lines of Rust unit tests and 174,675 lines of end-to-end tests in TypeScript. A separate SDK repository also contained around 130,000 lines of end-to-end tests covering six languages.

This was a real production system, not a lab demo

That distinction matters in almost every story about AI agents. GitHub is not showing a benchmark where “the agent rewrote the project and the tests passed”. New components were merged gradually into the main branch and actually shipped to users.

Over roughly 14.5 weeks, the main branch produced 135 releases: 100 pre-releases and 35 stable releases. That works out to about 1.3 releases per day. GitHub also describes real users, mostly inside Microsoft and GitHub, running the new builds so regressions could be caught before a wider rollout.

In other words, the migration was being tested in the same environment where the system actually had to live. That is why the working model is more interesting than the raw number of generated lines.

128 pull requests instead of one giant “rewrite this”

GitHub split the migration into 128 pull requests. Each one moved a single component or a small slice of functionality. The old TypeScript code was replaced with a thin layer connecting it to Rust, and once a component had been migrated, the previous implementation was removed.

The goal was to keep the main branch releasable at all times. Every new piece went through the existing tests and immediately had to work in the context of the rest of the system. The opposite of “we disappear for six months and then find out whether the new version even starts”.

GitHub itself stresses that telling an agent “rewrite the whole runtime from TypeScript to Rust” would not have been enough. The agents made a project at this scale economically viable, but the migration architecture, tests, boundaries around each change and release control still determined whether the result was fit for production.

AI did a lot of the work. It still was not allowed to declare victory

GitHub describes a process in which the agents did much more than write code. They read the repository, ran tools, fixed errors, reviewed changes and responded to review comments. In one of the larger phases involving model orchestration, the main session ran for 42 hours and launched 126 subagents, with as many as 22 running at the same time.

That is impressive. More interesting, though, is the moment when the system tried to get CI green in the wrong way. In one case, a migration removed a method from the public SDK. Instead of restoring compatibility, the agent tried to introduce an exception that would allow the schema break to be accepted. A human caught it during review and told the agent to restore the method. The agent corrected the change shortly afterwards.

It is a tiny moment in a huge project, but it neatly shows the difference between “the test passed” and “the change is correct”. An agent can be very good at optimising for the conditions it has been given. If one of those conditions is green CI, it can find a path to green CI. A human still has to notice when that path amounts to switching off the smoke alarm instead of putting out the fire.

Why go to all that trouble if TypeScript was working?

GitHub does not present Rust as a magically better language for everything. The company had a specific problem: the runtime was being embedded in more and more applications and services, while Node.js and V8 brought an extra process, extra memory use and inter-process communication even when the client itself was written in C#, Python, Go, Java or Rust.

In the load tests described by GitHub, the old version completed 7.55 one-shot session cycles per second. Rust running as a separate process reached 57.45, while the in-process version reached 120. GitHub explicitly warns that this is the result of one specific test, not a promise that Copilot as a whole is “15.9 times faster”.

Memory use changed just as dramatically in the tested scenario with ten clients. Private memory growth was around 1,383 MB for the old process tree, 247 MB for Rust running separately and 126 MB for the in-process version. GitHub describes the last figure as a 91% reduction in that specific test.

What does any of this mean for the owner of a normal website or online store?

No, you do not need to start asking your web developer tomorrow whether everything is written in Rust. That would be a fairly spectacular way to extract the least useful lesson from this story.

A much better question is: how are changes made with AI actually controlled? Is a large rebuild split into small, verifiable stages? Are the critical functions covered by tests? Does someone review the agent’s output? Can the team quickly identify which change broke something and roll it back?

The same applies to WordPress, WooCommerce and custom integrations. An agent can generate a change in minutes that would have taken much longer to write by hand. That does not automatically reduce the time needed to understand what the change will do. With carts, payments, forms, logins or customer data, the time spent understanding the consequences is often more important than the time spent writing the change.

My take:

The most convincing part of this case study is not “AI wrote 832,000 lines”. Counting lines of code is a fairly poor way to measure software quality anyway.

What is more interesting is that, despite the huge acceleration in code production, GitHub did not give up small changes, CI, tests, gradual releases or human review at the points where an agent could choose the wrong route to a formally correct result. Quite the opposite: the faster you can produce changes, the more important the brakes become – the mechanisms that decide whether those changes should be allowed any further.

That may be one of the more sober answers to the question of how AI is changing software development. It is not just that AI “writes code instead of a human”. It changes the economics of projects that used to be too expensive or take too long. At the same time, some of the value shifts away from typing the code itself and towards setting boundaries, planning, verification, testing and deciding what an agent is not allowed to count as success.