How Theo Used AI Agents to Port TypeScript to Rust

I am announcing TS Rust, also called tsc-rs: an agent-built Rust port of the TypeScript compiler, checker and language server. I spent months experimenting. The early Codex attempts consumed what I estimate as $400,000 worth of tokens without finishing; a later Opus 5.5 effort got much further in about two weeks. I have not personally read the code line by line.

I chose this as a playground because it looked impossible. Earlier OpenAI-model attempts reached roughly 84% compatibility, but the remaining edge cases were increasingly difficult. The finished project is available as an npm package, though my claims about compatibility and speed should be understood in the context of the tests I ran.

In my comparisons, it is about twice as fast as Microsoft's Go-based TypeScript 7 and substantially faster than the older TypeScript 6 on selected workloads. Bun also released Bun check, which is faster in many cases. My interest is not just speed: I want to explore a developer environment that can run inside a JavaScript isolate.

TypeScript adds a type system to JavaScript. The compiler can turn TypeScript source into JavaScript that browsers and other runtimes understand, but stripping annotations and checking whether a program's types are consistent are different jobs.

Removing the TypeScript syntax is comparatively straightforward. Tools such as esbuild sped up the development loop by handling transpilation, bundling and related work in a native tool. But fast transpilation by itself does not tell you whether the types are correct.

Type checking is much more demanding. At Twitch, I remember a development server taking minutes to start and a change taking tens of seconds to appear. Separating the path that serves the code from the path that checks types helped us bring the feedback time down dramatically.

TypeScript's type system is flexible enough to represent much of JavaScript's unusual behavior; someone even implemented Doom in the type system. Faithfully encoding those semantics in another language is hard because the port must reproduce many details of how JavaScript programs behave.

Microsoft nevertheless chose Go for its native TypeScript rewrite. I have criticized Go plenty, but I think it was a sensible choice for this job: goroutines support concurrency, its syntax helped the team compare implementations, and garbage collection reduced the amount of manual memory management during a large port.

Garbage collection can introduce pauses and hurt latency-sensitive requests, even if the language is otherwise fast. For a compiler running a long batch, I argue that occasional collection overhead may be less consequential than it is for a service trying to keep every response under a tight deadline. The outcome still depends on the workload and implementation.

The agent did not make an idiomatic Rust redesign from scratch. It took Microsoft's Go port and translated it very faithfully, even recreating pieces of Go's standard library and runtime in Rust. I only noticed the extent of that choice after someone pointed it out to me.

That Go implementation was a critical intermediate step: the Microsoft team had already translated TypeScript's behavior into Go by hand. The first Rust result was two to three times slower than Go, so I gave the agents a further goal of making it at least twice as fast and let them iterate.

The headline cost needs context. I estimate the Opus work at roughly $24,000 at full API prices, not $24,000 actually billed through an API. Across six subscriptions, my logs suggested roughly 925%–983% of one account's weekly allowance; accounting for a free reset, I estimated around $500 worth of subscription usage. These are my estimates, not a reproducible price for every user.

The earlier $400,000 figure describes the unsuccessful prior experiments in token-value terms; it should not be confused with the later subscription estimate. Nor does this mean Microsoft's port was wasted effort: I do not believe the agents would have made this Rust port as effectively without that Go starting point.

I describe the result as close to a drop-in replacement for the targeted TS Go version. When my agent and I looked at six reported issues, we attributed one to the Rust port and five to behavior already present in the target version. That is encouraging evidence, but a handful of issue reports is not proof of universal compatibility.

On T3 Code, I measured about a twofold improvement over TS Go and much larger gains against TypeScript 6 in particular checks. These are project-specific measurements, not a promise that every repository will see the same ratio.

Effect is a TypeScript library that needs additional diagnostics. I built those checks into TS Rust. In the T3 Code chart, a full check with Effect took 11.13 seconds for tsc-rs, 21.07 seconds for TypeScript 7 with the Effect integration, and 37.60 seconds for Bun check plus a separate Effect pass. The TypeScript 6 plugin shown uses a different rule set.

Without the Effect checks in that same chart, Bun check was faster: 4.07 seconds versus 7.25 seconds for tsc-rs. I also tried projects including tRPC, Sentry, Excalidraw and Effect. I saw Bun report errors in some projects that the targeted checker did not, while acknowledging how fast Bun is.

For many users, I would still recommend Bun check because I have more confidence in its long-term maintenance. My own port aims for faithful compatibility and the particular features I need. A benchmark and a small set of test repositories cannot establish either tool's behavior across every codebase.

I did not start this primarily to win a speed contest. One reason was playful: I wanted an apparently impossible task to test model capabilities. The more consequential reason was WebAssembly and the possibility of running the TypeScript developer loop in environments that do not offer a conventional operating system.

A JavaScript implementation can already run wherever the JavaScript runtime supports it. Go programs can target WebAssembly, but their runtime and garbage collector affect bundle size and behavior. Rust is attractive to me for a compact WASM build that can participate in an isolate-based workflow.

I also expect inference prices at a given measured capability level to fall. The Artificial Analysis chart I show compares cost per intelligence-index task; I cite Opus 5 at $5.86 and GPT-6.1 Sol at $0.32 for a similar index threshold. These benchmark prices are snapshots, not guaranteed prices for all tasks or providers.

Inference is only one bill. An agent that writes software also needs somewhere to run code, access files and test its changes. A cloud coding session may need a VM and memory even while it waits for the next model response, so execution infrastructure can become a larger share of the cost as inference gets cheaper.

I use cloud coding environments as an example, but I am uncertain about the precise memory allocation in the service I mention. The general tradeoff is separate from the exact number: reserving isolated machines for many concurrent sessions consumes resources, and free or bundled access may not remain free forever.

Agents are accustomed to a real shell, filesystem, search tools, Git and native processes. Those capabilities make existing development workflows convenient, but the isolation and compute needed to provide them have a cost. I want a cheaper execution layer for the cases that do not need an entire machine.

Cloudflare Workers illustrate one alternative: code runs in V8 isolates rather than giving each workload a conventional full VM. Isolates can be lightweight, but their capabilities and security boundaries depend on the host. In particular, a normal native filesystem or arbitrary native processes are not automatically available inside the isolate.

That creates an apparent mismatch. Isolates are attractive for hosting JavaScript, while coding agents expect the tools and files of a development machine. The question is whether enough of the development environment can be implemented inside the isolated runtime to support useful work.

The just-bash library provides a simulated shell and virtual filesystem in JavaScript. It can give an agent familiar commands without exposing a normal host filesystem. To build an application, however, the environment also needs tools for compiling and checking the code; that is where the WASM-capable TypeScript port becomes interesting.

In my demo, GPT-6.1 Sol built an app while the agent-side execution environment, virtual filesystem and TypeScript tooling ran inside a V8-based setup. The demo was running in Node on a server, and I believe it could also be adapted for a browser. Model inference itself was external and is not included in the local compute I am describing.

I reported one run using under 216 MB of RAM and peaking around 4% CPU, while a later screenshot shows a different memory reading. These are observations from my demo, not a general resource guarantee. A second version that included esbuild used more memory in my comparison.

The property I care about is that the working filesystem in this demo lives in memory: I say it would keep working if the host filesystem were made read-only. That is different from proving that it runs unchanged on every isolate host or supports every native development tool.

To explain the potential savings, I sketch the layers from hardware and operating system to applications and contrast machine-level isolation with V8 isolates. That drawing is a simplified mental model: containers and virtual machines have different implementation and isolation properties, and they should not be treated as the same thing.

Many isolates can share a runtime while retaining boundaries between workloads. That can reduce overhead compared with provisioning a full machine for each small job, although the precise costs and security guarantees are platform-dependent. A browser tab and a database container are illustrative examples, not equivalent workloads.

A restricted JavaScript environment cannot simply execute arbitrary native tools or access the host filesystem. The simulated shell supplies part of the interface, and the Rust-to-WASM compiler supplies another. I say this could eventually run in a Cloudflare Worker; the video shows a Node-hosted demo, not a completed Worker deployment.

The economics also depend on scheduling. An agent often waits for inference or network responses, and an event-driven platform can schedule other work while it waits. Actual billing depends on provider rules, memory, CPU and other resources; waiting is not a universal guarantee of zero cost.

TS Rust is one of the missing pieces I wanted for an end-to-end TypeScript development experience inside an isolate. I am interested in how this might relate to Lakebed, but I am not announcing the details here.

The prompts behind the port were less magical than the setup. I asked agents to read project guidance and accountability notes, improve compatibility and performance, and keep parallel workers operating independently. When the process kept stopping too early, I specified a clearer target: at least twice the speed of the Go build.

Resource management became part of the work. Runs crashed or ran out of capacity, so I adjusted the environment and gave the agents access to additional machines. The effort was not merely one prompt followed by an unattended result; it involved observing repeated failures and changing the conditions under which the agents worked.

My role resembled management: find bottlenecks, give the team what it needs, and prevent parallel efforts from stepping on each other. Once the environment and coordination improved, the work moved faster. The lesson I take is that orchestration and feedback matter more than a clever incantation.

I have wanted an end-to-end development experience inside V8 since seeing browser-based environments such as StackBlitz. Previously, many of these ideas remained thought experiments or depended on finding someone else with time to build them. Agents now let me try them and see what happens much more directly.

I have asked an agent to investigate whether the demo can actually run on Cloudflare, but at the time of the video that remains something to test. I am excited by how much the tools can attempt, even though this project still needs independent evaluation and maintenance before anyone can rely on it broadly.

I am proud of the experiment not because I think everyone should immediately adopt this compiler, but because it let me explore an idea that used to feel out of reach. The most interesting result is the ability to test ambitious ideas and learn from the limits as well as the successes.