If you have seen headlines claiming that the TypeScript compiler was ported to Rust by an LLM, you have encountered a garbled version of one of the most interesting compiler stories in recent years. The real story is different in important details, but the underlying trend it points to — AI-assisted migration of massive codebases to faster languages — is very real and directly relevant to your daily tooling. This article untangles what actually happened with the TypeScript compiler, why the language choice matters, what role AI tooling realistically played, and what lessons you can apply to your own large-scale refactoring projects.
The Real Story: TypeScript Native Went to Go, Not Rust
In early 2025, Microsoft announced that the TypeScript compiler and language service were being ported to a native language, with the result made available as the @typescript/native-preview package on npm. The target language was Go, not Rust. Anders Hejlsberg, the original creator of TypeScript and Turbo Pascal, explained the decision in detail: the team evaluated Rust carefully but found that the compiler's architecture — which relies heavily on shared mutable data structures, cyclic references, and garbage-collected object graphs — mapped far more naturally onto Go than onto Rust's ownership model.
The port reportedly delivered roughly an order-of-magnitude improvement in build performance on large codebases, along with dramatically faster editor responsiveness in tools like Visual Studio Code. You can follow the project in the official TypeScript repository and read about the native preview on the TypeScript website.
So where did the "Rust" and "LLM" parts of the claim come from? Two separate trends got blended together:
- Rust-based tooling has been eating the JavaScript ecosystem: SWC for transpilation, Rspack and Turbopack for bundling, Biome for linting and formatting, and Oxc for parsing and minification. Many developers reasonably assumed TypeScript would follow the same path.
- LLM-assisted code migration is genuinely being used for large mechanical rewrites, which made the "an AI did it" framing plausible to readers who had seen AI handle smaller ports.
Neither piece is wrong on its own — they were just stitched together incorrectly.
Why Go Instead of Rust: A Decision Worth Understanding
The language choice is the most instructive part of the story, because it is a textbook example of matching a rewrite target to the existing code's architecture rather than to the trendiest option.
The existing TypeScript compiler is a large, imperative, object-oriented codebase. Types, symbols, and nodes reference each other in dense, often cyclic graphs. In Rust, that structure fights the borrow checker: shared mutable graphs typically require Rc<RefCell<T>>-style patterns, arena allocation with careful index management, or a significant architectural redesign. Any of those choices would have made a faithful port slower, riskier, or semantically different.
Go, by contrast, offers garbage collection, simple pointer semantics, and a low-friction porting path. Hejlsberg described a largely mechanical translation process where the team could preserve the compiler's structure and behavior while gaining native performance from better memory layout, real multithreading, and elimination of JavaScript runtime overhead.
The practical takeaway for your own projects: when migrating a large system, the "best" language is the one that minimizes semantic distance from what you already have — not the one with the best benchmarks in unrelated workloads. A rewrite that forces you to redesign core data structures is a rewrite that introduces new bugs, and in a compiler, correctness is the product.
What Role Did LLMs Actually Play in Large-Scale Ports?
There is no credible public evidence that an LLM autonomously ported the TypeScript compiler. The port was a human-led engineering effort. That said, the broader question — can an LLM do this kind of work? — deserves a sober answer, because teams are actively using AI for migrations of this shape.
LLM-assisted migration works well when the transformation is mechanical and locally verifiable: translating statement-by-statement between languages with similar semantics, updating API call sites after a library rename, or converting class-based code to a different module pattern. It works poorly when the transformation requires global invariants: managing ownership across a shared mutable graph, preserving subtle performance characteristics, or maintaining correctness in code where the tests are incomplete.
A realistic workflow for AI-assisted migration looks like this:
- Establish a strong verification baseline — tests, type checks, and ideally differential testing against the original implementation's output.
- Decompose the migration into small, independently verifiable units (a file, a module, a subsystem).
- Use an LLM such as Claude or ChatGPT Plus to draft translations per unit, with a human reviewing anything touching shared state or concurrency.
- Run the verification suite after every unit and reject changes that alter observable behavior.
The bottleneck is never the translation itself — it is verification. That is the honest limitation behind both the real Go port and the mythical LLM port.
What the Native TypeScript Compiler Means for Your Workflow
Regardless of how the port was done, the practical consequences for web developers are significant and worth preparing for.
The native preview ships as an npm package, so adoption in a project is intentionally low-friction. The key caveat is that during the preview phase, it does not implement every feature of the JavaScript-based compiler, and the team has been explicit that behavior differences are possible. For production CI, you should treat the native compiler as an opt-in experiment until it reaches stable release parity.
A typical trial looks like this:
# Install the native preview alongside your existing TypeScript setup
npm install --save-dev @typescript/native-preview
# Run a type check with the native compiler
npx tsgo --noEmit
# Compare against the classic compiler to spot divergences
npx tsc --noEmit
A useful technique during evaluation is differential checking: run both compilers on your codebase and diff their diagnostics. Any discrepancy is either a preview bug you should report or a place where your code depends on unspecified compiler behavior — and both findings are valuable.
Where you will feel the difference most:
- Large monorepos, where full type checks that took tens of seconds can drop dramatically.
- Editor experience, since faster language-service responses reduce the "red squiggle lag" that plagues big TypeScript projects.
- CI pipelines, where type checking is often the slowest non-test step.
If your project is small, the practical benefit is modest; the classic compiler is already fast enough at that scale. If you maintain a large codebase, this is one of the most impactful tooling upgrades on the horizon.
Lessons for Your Own AI-Assisted Refactors
The TypeScript story — real and rumored versions alike — offers a reusable playbook for modernizing large codebases with AI in the loop.
First, pick the target that fits your architecture. Before reaching for Rust because it is fast, ask whether your data model can survive the borrow checker. Go, C#, Zig, or even a well-structured modernization within your current language may deliver 80% of the benefit at 20% of the risk.
Second, invest in verification before automation. An LLM can generate thousands of translated lines per hour, but only a trustworthy test suite can tell you whether any of them are correct. Teams that skip this step are not accelerating migration; they are accelerating the arrival of subtle bugs.
Third, keep humans on the invariants. Let AI handle the mechanical bulk, but have experienced engineers own the data-structure design, concurrency model, and public API surface. Tools like GitHub Copilot and AI-native editors such as Cursor are force multipliers for this kind of work — but the multiplier applies to whatever quality of plan you start with.
Finally, be skeptical of compressed tech headlines. "Ported to Rust by an LLM" is a catchier sentence than "ported to Go by a legendary compiler engineer and his team, with careful architectural reasoning" — but the second version contains the lessons actually worth learning.
Frequently Asked Questions
No. The TypeScript compiler was ported to Go by Microsoft’s TypeScript team, led by Anders Hejlsberg, and announced as a native preview in 2025. The Rust and LLM elements appear to be distortions that spread through social media: Rust because many other JavaScript tools have been rewritten in Rust, and LLMs because AI-assisted migration is a real and growing practice. There is no public evidence that an LLM performed the port.
The compiler’s architecture relies on shared mutable object graphs with cyclic references, which Go handles naturally through garbage collection and simple pointers. In Rust, the same structures would require significant redesign to satisfy the borrow checker, increasing risk and potentially changing semantics. Go offered a more faithful, lower-risk porting path while still delivering native performance and real parallelism.
You can install the preview package `@typescript/native-preview` and run it via the `tsgo` command. However, during the preview phase it does not yet implement every feature of the JavaScript-based compiler, so you should test it on your codebase, compare its diagnostics against the classic `tsc`, and keep it out of critical CI gates until it reaches stable parity.
Partially. LLMs are effective at mechanical, locally verifiable translations between languages with similar semantics, especially when the work is decomposed into small units with strong test coverage. They are not reliable for changes requiring global reasoning about ownership, concurrency, or subtle behavioral invariants. The realistic model is AI-assisted drafting with human review and automated verification at every step.
Only if profiling shows the runtime language is genuinely your bottleneck and the rewrite cost is justified. For most teams, adopting existing fast native tools — such as SWC for transpilation or Rspack for bundling — delivers the performance benefits without the maintenance burden of owning a rewrite. Measure first, and prefer the target language that minimizes architectural distance from your current code.
Conclusion
The viral claim that the TypeScript compiler was ported to Rust by an LLM compresses two real trends into one inaccurate headline. The actual port targeted Go, chosen deliberately because it preserved the compiler's architecture, and it was executed by a human team with deep compiler expertise. Meanwhile, LLMs genuinely are changing how large migrations get done — as drafting assistants under strict human verification, not as autonomous engineers. The actionable next step for you: try the native TypeScript preview on a non-critical branch of your largest project, diff its output against the classic compiler, and see whether the speedup justifies early adoption in your workflow.
Transparency Note: Links in this article are not affiliate links. I recommend these tools and platforms based on their relevance to the topic, and no compensation is received for including them.