The great software rewrite
AI coding agents are making it cheaper to rebuild software in Rust, Go, C, and C++. But faster code is only part of the story.
Every few weeks, another software project seems to announce some version of the same thing:
We rewrote it in Rust.
Or Go. Occasionally, C++ or Zig. Sometimes the announcement includes a benchmark chart so dramatic that the old implementation looks as if it were running on a refrigerator.
Microsoft is rebuilding the TypeScript compiler in Go. Python developers are adopting Rust-based tools such as Ruff and uv. JavaScript build systems are being replaced by native alternatives. Bun recently moved a large part of its codebase from Zig to Rust, using coding agents to help translate hundreds of thousands of lines of code.
It is easy to dismiss this as another cycle of programming-language fashion. Software engineers are, after all, perfectly capable of turning garbage collection into an identity question.
But there is a real trend here.
Performance-critical software infrastructure is increasingly being rebuilt in native systems languages. At the same time, coding agents are lowering the cost of these migrations, making rewrites that once looked reckless or financially irrational much more plausible.
The important question is not simply whether this is happening.
It is what the trend will actually change.
The trend is real, but narrower than it looks
We are not witnessing the wholesale disappearance of Python, JavaScript, Java, or C#.
Most ordinary business applications will continue to be built in high-level languages. A SaaS company does not need to rewrite its settings page in Rust because someone on Hacker News called JavaScript slow.
The strongest movement is happening in software that other software depends on:
Compilers
Type checkers
Bundlers
Linters and formatters
Package managers
Databases and query engines
Command-line tools
Proxies and networking infrastructure
Language runtimes
Performance-sensitive libraries
These tools often run thousands or millions of times. A small improvement in execution time, startup speed, or memory use can compound across every developer, build pipeline, server, and coding agent that relies on them.
That makes infrastructure a much better target for native rewrites than ordinary product code.
If a customer opens your invoicing page twice a week, reducing its execution time from 40 milliseconds to 10 milliseconds is unlikely to transform the business.
If a compiler runs hundreds of times a day across thousands of engineers and automated agents, the same improvement matters a great deal.
The movement started before coding agents
Coding agents did not create the desire for faster software.
Developers have been moving performance-sensitive work out of interpreted and dynamic languages for years. Parts of the Python ecosystem have always depended on C and C++. JavaScript runtimes are themselves largely written in C++. Databases, browsers, operating systems, and game engines have long lived close to the metal.
More recently, Rust and Go have made native development accessible to a wider group of engineers.
Rust offers native performance, predictable resource use, strong tooling, and protection against many memory-safety bugs. Go provides fast compilation, garbage collection, simple concurrency, and a relatively small language that teams can learn without first completing a philosophical retreat.
Projects such as esbuild, SWC, Ruff, uv, and Rolldown were built around a straightforward observation: many tools written in JavaScript or Python were becoming bottlenecks.
The newer change is not the motivation.
It is the economics.
Coding agents are making rewrites less irrational
For decades, “let’s rewrite it” has been one of the most dangerous sentences in software.
A mature codebase contains years of accumulated behavior, including obscure edge cases that may not be documented anywhere. Rewriting it means rebuilding not only the intended design, but also every accidental behavior that users and integrations have come to depend on.
This is why major rewrites so often fail. The new system looks cleaner, but takes longer than expected, falls behind the original product, and eventually discovers that the ugly old code was ugly for reasons nobody remembered.
Coding agents do not eliminate these risks. They do, however, change the cost structure.
Language migration is unusually suitable for AI-assisted development because it often has several useful properties:
The original implementation acts as a detailed reference.
The compiler provides immediate and structured feedback.
Existing tests define much of the required behavior.
Work can be divided into relatively small units.
Multiple agents can translate, review, benchmark, and repair code in parallel.
An agent does not need to invent the product. It can inspect a function in one language, produce an equivalent implementation in another, compile it, run tests, compare behavior, and revise the result.
That is still difficult work, but it is far more constrained than asking an agent to design an unfamiliar system from nothing.
Bun’s move from Zig to Rust is one of the clearest public examples. According to the company, it used dozens of continuously running Claude Code workflows to help port more than 500,000 lines of code. The team reached a passing cross-platform test suite in less than two weeks.
That does not mean the agents independently rewrote Bun during a long weekend while the engineering team enjoyed coffee.
The process required extensive tests, human supervision, porting instructions, compiler-driven task queues, fuzzing, benchmarking, and adversarial review. Regressions still appeared. Some unsafe Rust remained.
The lesson is not that agents make rewrites automatic.
It is that they can make them economically possible.
Will all these rewrites make software dramatically faster?
Sometimes.
But the answer depends heavily on what is being rewritten, what language it is coming from, and where the real bottleneck lives.
Moving from Python or JavaScript to native code can be transformative
Dynamic languages provide flexibility and developer speed, but they also carry runtime costs.
Depending on the workload, native implementations can avoid or reduce:
Interpreter overhead
Dynamic dispatch
Excessive object allocation
Garbage-collection pauses
Runtime startup costs
Serialization overhead
Single-threaded execution constraints
These differences matter most in CPU-intensive work such as parsing, compilation, compression, dependency resolution, static analysis, and query execution.
Microsoft’s native TypeScript effort is a strong example.
The company has reported roughly tenfold improvements in type-checking speed on some large projects after porting the compiler to Go. It has also reported faster editor startup and significantly lower memory consumption.
The improvement is not simply “Go is faster than TypeScript.”
The native implementation can also make better use of parallelism and shared memory. The architecture changed along with the implementation language.
The same is true of tools such as Ruff and uv. Their performance comes partly from Rust, but also from being designed as integrated systems rather than collections of separate scripts and subprocesses.
A rewrite often creates an opportunity to redesign the entire execution model.
That can matter more than the language itself.
Moving between native languages produces smaller gains
The story changes when the original software is already written in a native systems language.
Bun’s move from Zig to Rust reportedly produced performance improvements in the low single digits for many workloads, rather than a tenfold leap.
That should not be surprising. Both Zig and Rust compile to native machine code. Neither is dragging an interpreter behind it.
The more important benefits were elsewhere:
Better memory safety
Clearer resource ownership
Fewer leaks and crashes
Stronger static analysis
Improved maintainability
Easier long-term development
In other words, a native rewrite may improve the reliability of performance more than the best-case benchmark.
A program that is 3 percent faster is useful.
A program that stops consuming gigabytes of memory during repeated workloads is considerably more useful.
Peak speed makes attractive charts. Predictable resource use keeps production systems alive.
Architecture matters more than the logo on the language
Programming languages influence performance, but they do not determine it.
A poorly designed Rust program can be slower than a well-designed Python application that delegates its heavy computation to optimized native libraries.
A fast language cannot rescue an application that makes unnecessary database queries, serializes the same data repeatedly, or calls an external API twelve times for every user request.
Much of the performance attributed to newer tools comes from architectural choices:
Caching work instead of repeating it
Avoiding subprocesses
Processing data incrementally
Using more efficient data structures
Reducing memory allocations
Running tasks in parallel
Combining multiple tools into one process
Avoiding unnecessary network and disk access
uv, for example, does not become fast merely because it is written in Rust. Its caching model, dependency-resolution architecture, use of hard links, and reduction of repeated work are equally important.
The language enables some of those decisions. It does not magically produce them.
The processor remains stubbornly uninterested in which programming language has the most enthusiastic online community.
Most SaaS applications will not become ten times faster
This distinction is especially important for product teams.
Many web applications are not limited by the speed of their application language. They are limited by waiting.
They wait for:
A database query
An LLM response
A payment provider
An object-storage request
A third-party API
Another internal service
The network
Suppose a request takes 200 milliseconds.
If only 20 milliseconds are spent running TypeScript and the remaining 180 milliseconds are spent waiting for databases and external services, rewriting the application in Rust cannot produce a tenfold end-to-end improvement.
Even if the application code becomes twice as fast, the user may barely notice.
At enormous scale, those savings can still reduce infrastructure costs. But most companies do not operate at enormous scale, despite presenting every internal architecture discussion as if they were rebuilding Google before lunch.
Before rewriting anything, teams should profile the real system.
If CPU usage, memory allocation, garbage collection, startup latency, or runtime cost is the bottleneck, a native rewrite may be justified.
If the application mostly waits for PostgreSQL and OpenAI, the programming language is probably not the main problem.
The biggest effect may be on coding agents themselves
The most interesting consequence of faster developer infrastructure may not be faster software for end users.
It may be faster feedback for machines.
Coding agents continuously run compilers, tests, linters, type checkers, formatters, and build systems. A human developer might tolerate a 30-second build because it happens occasionally.
An autonomous agent may trigger that same build hundreds of times while completing one task.
For agents, tool latency compounds.
Faster infrastructure creates a reinforcing loop:
Faster tools lead to more iterations.
More iterations lead to earlier error detection.
Earlier error detection allows agents to handle larger tasks.
Larger tasks create more demand for fast tools.
This may explain why companies are investing heavily in native compilers, language servers, and build systems now.
The audience is no longer only the human developer sitting in an editor.
It is also an expanding population of agents that consume software tools at machine speed.
A tenfold-faster compiler does not merely save a developer several seconds. It can allow an agent to explore more alternatives, run more tests, and correct more mistakes within the same amount of time and compute.
That is a meaningful change in software economics.
Faster infrastructure will reduce costs too
Performance gains at the tooling and infrastructure layer can also lower operating costs.
Faster builds mean:
Shorter CI pipelines
Fewer compute minutes
Lower cloud bills
Greater throughput per server
Faster deployment cycles
More efficient hosted development environments
Lower memory use can allow more processes to share the same machine. Smaller binaries can improve deployment and cold-start time. Native single-file tools can reduce installation failures and dependency conflicts.
For an individual developer, these improvements may feel like convenience.
Across a large engineering organization, they become material financial savings.
Across an ecosystem used by millions of developers and agents, they become infrastructure.
The bottleneck moves from writing code to proving correctness
As coding agents make translation cheaper, a different constraint becomes more important.
Verification.
A codebase with a comprehensive test suite, stable interfaces, clear benchmarks, and well-defined behavior is much easier to migrate than one whose requirements live in the memories of three former employees.
Successful agent-assisted rewrites will depend on:
Unit and integration tests
Differential testing against the original system
Fuzzing
Security review
Performance profiling
Platform-specific testing
Compatibility suites
Human architectural judgment
The code may become cheaper to produce.
Confidence in the code does not automatically become cheaper at the same rate.
This creates an important strategic advantage for well-tested projects. A strong test suite is no longer merely protection against regressions. It is a machine-readable specification that allows agents to modify or reimplement the system safely.
Projects without one may discover that their real technical debt was never the old programming language.
It was the absence of a reliable description of what the software was supposed to do.
What happens next
I expect this trend to accelerate, but not in the simplistic form of every company rewriting everything in Rust.
The more likely future is hybrid.
High-level languages will remain dominant for product development, business logic, experimentation, and user-facing applications. They offer mature ecosystems, large talent pools, and rapid iteration.
Performance-critical components will increasingly move into native implementations.
A Python library may preserve its Python interface while moving its core execution engine to Rust. A TypeScript application may rely on a native compiler, bundler, parser, and database driver. A web service may remain in Go or Java while delegating specialized work to Rust or C++ components.
The interface stays familiar. The machinery underneath becomes faster.
We will also see more entire tools rewritten when three conditions are present:
The existing implementation has become a meaningful performance bottleneck.
The project has a strong and portable test suite.
Agents can translate the code while humans focus on architecture and verification.
Rust is likely to benefit most where memory safety, reliability, and native performance matter.
Go will remain attractive for compilers, network services, infrastructure, and command-line tools where simplicity and concurrency are priorities.
C and C++ will remain deeply embedded in systems software, even if they receive less attention in public rewrite announcements. They are not disappearing. They are simply old enough to have stopped posting about every project they power.
The real shift
The most important change is not that Rust or Go suddenly became fast.
They were already fast.
The change is that coding agents are reducing the labor required to move mature software into these languages.
That changes the calculation.
A rewrite that once required a large team and several years may increasingly be completed by a smaller team supervising fleets of agents. It may still be risky. It may still introduce bugs. It may still be the wrong decision.
But it is no longer automatically absurd.
The result will probably be faster compilers, faster package managers, faster developer tools, lower infrastructure costs, and more reliable software foundations.
It will not make every application ten times faster.
And it will not save a badly designed system from itself.
A poor architecture rewritten in Rust remains a poor architecture. It simply reaches the wrong answer more efficiently.
But at the infrastructure layer, where speed compounds across millions of executions and increasingly across millions of agent iterations, the great rewrite has already begun.