Claude ported the TypeScript compiler to Rust without anyone reading the code: why it worked

You probably have a migration in your project that you keep putting off because it touches everything: swapping the date library across two hundred files, moving from an old framework to a new one, changing the database. You know a coding agent could do most of it, but you don’t dare leave it alone with something that big, because afterwards you’ll have to review every line.

On October 7, someone did exactly that with something much bigger: he let Claude Opus 5.5 translate the entire TypeScript compiler into another language. The result passes all 184,749 tests of the original, and its author wrote on the project’s front page: “I’ve never read a line of this code.” Below is what happened, what’s overhyped about it, and above all why it worked, because the key wasn’t the model. It was how the work around it was set up, and you can use that structure for your next migration. Setting it up costs more than writing the code; that’s exactly where your time should go.

What happened

The project is called ts-rust (opens in a new tab) and comes from Ping, the company of Theo Browne, known for the T3 stack and his YouTube channel. Understanding it takes a bit of context.

The TypeScript compiler is the program that checks the types in your code and gives your editor autocomplete and the red squiggles. Microsoft rewrote it in Go for TypeScript 7, and it got several times faster than the previous one. ts-rust translates that Go version into Rust, another language, to see if it could be made even faster.

The numbers, according to the project’s own README:

• The first attempt used OpenAI models (GPT-5.6 Sol and GPT-6 Astra). Over several months they wrote more than 1.3 million lines, spent the equivalent of over $400,000 in model usage, and never got past 84% compatibility.
• Then he tried Claude Opus 5.5, which didn’t build on the earlier work: it started from scratch. It had a working first version in 10 hours.
• Over two weeks it spent about $24,000, between nine and ten times the weekly limit of a $200 subscription.
• The result passes all 184,749 tests of the Go compiler. On 60 open-source projects it reports exactly the same errors as the original, and it checks types in half the time.

What’s overhyped

Before drawing conclusions, it’s worth cooling down a little, as many did in the Hacker News discussion (opens in a new tab).

It isn’t a new compiler: it’s a translation. The hardest part, deciding how the compiler should work, had already been done by Microsoft’s team. The model had the Go code in front of it and had to do the same thing in another language. One comment put it wryly: the honest title would be “Rust port of Go rewrite of Typescript compiler”.

The real gain is small. On a project as large as VS Code, type checking drops from 9.6 to 4.8 seconds; on medium-sized apps, the saving is under a second. And it isn’t the fastest: Bun’s checker beats it on four of the six apps they measured.

Nobody knows if it can be maintained. The author himself warns: “I have no idea if this will actually work.” One of the comments put it bluntly: “Now you have a codebase no one has read. Good luck adding new code to it.” Another pointed at something subtler: the tests cover what the original authors thought needed testing, and there may be holes exactly where they thought it was obvious.

Even so, Daniel Rosenwasser, from the TypeScript team, wrote in the same discussion: “this is impressive work, and it’s honestly crazy that 3 of these ports have popped up in the last week!”

Why it worked

The interesting question is why the same kind of tool failed for months with one model and worked in weeks with another. Part of it is the model. But the repository documents the rules the agents worked under, and that’s where the other part is.

1. A reference that decides what’s right

In software testing, an oracle is something that, for any input, tells you the correct result. Here the oracle was the Go compiler: you give both the same project and compare. If the Rust one reports an error the Go one doesn’t, it’s wrong. There’s no possible debate about what’s “correct”, and the agent doesn’t have to guess anything.

2. Tests nobody can touch

The rules say every test that passed has to keep passing, one by one. If a change makes ten new tests pass but breaks an old one, it’s rejected: “New passes do not compensate for lost ones.” And the agents are forbidden from changing what a test expects as a result. That’s the most common trick of a rushed agent: if the test fails, “fix” it by changing what it expects.

3. Whoever writes isn’t whoever approves

Each batch of work has three agents with different roles: one writes the code, another reviews it independently, and a third looks for what broke. Neither the reviewer nor the auditor can edit code. It’s the same as on a human team: whoever wrote the change doesn’t approve it themselves.

4. Memory lives in files

Weeks of work don’t fit in one conversation. The agents keep the state in two files: one with the current situation and another that only gets lines appended, with every decision and every result. When an agent starts fresh, the first thing it does is read them.

5. Rules drawn from what went wrong

Many rules carry the date of the problem that caused them. One example: when the agent works alone, it’s forbidden from asking questions and has to record the decision it made, because “Three questions stopped a goal for 4.3 hours.”

The first attempt shows what happens without this. According to the project’s history, the OpenAI models landed hundreds of changes before the system for comparing against Go existed. When it was built, 70 tests were failing and the compiler was up to 3.4 times slower than the original.

How to use the same idea in your project

You don’t need a compiler to take advantage of this. It works for any large migration: swapping a library across the project, moving an API from one framework to another, replacing hand-written queries with an ORM.

1. The net first, the code second. Before the agent touches anything, build tests that record what the system does today, right or wrong. They’re called characterization tests. If you’re migrating an API, for example, save the responses to fifty real requests and compare against them after every change. If you’re switching date libraries, write a test that runs a hundred real dates from your database through each formatting function and saves how they look today, including the odd ones: end of month, leap years, daylight saving changes. The old version of the code is your oracle.

2. Define “done” with a number. “It works” isn’t enough. “All 312 tests pass and the fifty responses are identical” is.

3. Make sure the agent can’t touch the tests. Say so in the project’s instructions file and, if you use Claude Code, block it with a permission rule in .claude/settings.json:

{
  "permissions": {
    "deny": ["Edit(tests/**)"]
  }
}

4. Have someone else review. Open a new session, without the previous one’s history, and ask it to compare the change against the old version without editing anything. An agent that didn’t write the code finds things the one that wrote it takes for granted.

5. Save progress in a file. A list of what’s migrated, what’s left, and what decisions were made. If the session drops or the context fills up, the next one starts by reading it.

Someone did read it: whoever wrote the tests

The line “I’ve never read a line” is true, but it’s a bit misleading. Those 184,749 tests were written by people over years, and each one is a decision about how the compiler should behave. The author didn’t skip review: he moved it. Instead of reading the code, he relied on tests that others had already thought through carefully.

That connects with the study showing that review is the new bottleneck when working with agents. If you don’t want to read every line your agent writes, the answer isn’t to read less: it’s to put that effort in earlier, into tests worth writing and a clear reference for what’s right. Without that, what ts-rust did isn’t a feat: it’s a gamble.