TypeScript compiler ported to Rust "without reading a single line": about $24,000 and two weeks with Opus 5.5, then a "4–5x slower" report the next day

Haru here. The project that gave me the most to think about this week was ts-rust (tsc-rs), released by Theo Browne, best known for t3.gg. It is a complete rewrite of the TypeScript compiler (the tool that checks your code and turns it into something that runs) in a different language, Rust. And its author writes that he has "not read a single line of this code." I didn't run it myself. Instead I went through the repository, the issues, the Hacker News thread and the write-ups. My takeaway is that the interesting part isn't that AI wrote it. It's that nobody has yet settled who is responsible for it now that it exists.

A port that $400,000 couldn't finish was done for $24,000 in two weeks

The source of the port is TypeScript 7, the new compiler rewritten in Go. It is a full package, including the type checker (which verifies that variable types line up) and the LSP (the protocol that delivers completions and error messages to editors). Copying all of that into Rust is a very large job. Theo, of Ping Labs, had agents working on the port for five months.

The first phase used OpenAI models (GPT-5.6 Sol and GPT 6 Astra). Even after they had written more than 1.3 million lines of Rust, compatibility with the original stalled at about 84%. API token spending came to about $400,000–$420,000, a figure that captures Tokenmaxxing (brute-forcing progress by burning huge numbers of tokens) at its most extreme.

He then switched to Claude Code and Opus 5.5, and had it rewrite the port from scratch instead of building on the earlier 1.3 million lines. A first version ran within 10 hours, and within two weeks it passed every test. The cost was about $24,047 at API list prices. Work that had stalled at 84% after more than $400,000 reached 100% for roughly one-seventeenth of that. On the numbers alone, it's hard not to ask whether the choice of model really makes that much difference.

The amount actually paid was reportedly far below list price, because usage ran through a subscription. That figure doesn't line up, though: the HN thread put it at about $7, while Theo's stream put it at around $500. The safest reading is "about $24,000 at list price."

On speed, type checking is 1.61–1.89x faster than tsc 7 (written in Go) by geometric mean, depending on the outlet. Against the previous tsc 6, it is 9.2–15.6x faster. The repository was created on October 7, 2026, and as of October 10 it had about 816 stars and 52 forks. For a project three days old, that is a lot of attention.

The key: something to check the answers against

So why did the second phase go so well? The Vibelog reportedly argued that the deciding factor was less the difference between models and more the presence of referees: a correct reference implementation and its tests.

Put simply, most development starts with working out what to build in the first place. A port is different. The model to follow (TypeScript 7 in Go) already exists, and it comes with a huge test suite. The AI only has to loop: write, run the tests, fix whatever fails. Because the goal is visible as a number, the work can move forward without a human reading the code.

It may be the clearest example yet of what is increasingly called harness engineering (designing tests and rules to constrain and steer autonomous coding AI). What keeps the AI in check here isn't human review but a mountain of tests. According to the repository, the port passes all 181,711 tests ported from Go.

That faithfulness had side effects. Theo said in a post that, in trying to reproduce Go's behavior exactly, the port had copied most of Go's standard library (the toolbox that ships with the language) into Rust. Because it also carries over how Go handles strings, some argue it may not be getting the full speed Rust can offer. Tests are good at enforcing matching output, but they can't tell you what natural code in a given language looks like.

A "slower, actually" report on launch day

This is where it matters. On launch day, October 7, a user named Strate posted results from trying it on a real project in Issue #15.

The project used contentMappers (a setting that transforms file contents before they are loaded). In the file-loading stage (parsing), tsc 7 took 2.67 seconds and tsc-rs took 12.73 seconds, 4–5x slower on that step alone. Overall, tsc 7 took 7.52 seconds and tsc-rs took 16.44 seconds: not faster, but about 2x slower. The cause was that the transforms ran one at a time. The Go version handled them in parallel, and the port had not carried that over.

The response was quick. Maintainer t3dotgg called it a gap left in the port and changed the code to process in parallel, as the Go version does. The fix landed on main the next day, October 8, as commit d6484ff, cutting parse time for the reproduction case from 22.4 seconds to 2.6 seconds. A fix within a day of the report is genuinely impressive.

That doesn't settle everything, though. According to a secondhand account via AIWeekly, on a private Vue workspace (2,901 .vue files and 3,283 .ts files), tsc 7 reportedly took 4.7 seconds while tsc-rs took 8.6 seconds. The README itself describes this as an early release and lists known issues: TS6059 errors in monorepos (setups that keep several projects in one repository), bugs in concurrent builds with tsc -b, memory that keeps growing when an editor stays open for a long time, and no Windows support. Only two platforms work: Linux x64 and macOS arm64.

The speed figures themselves aren't settled either: 1.61x, 1.89x and about 2x, depending on the source. LAVX News and others reported an average of about 2x across 60 public projects (versus tsc 7), and, versus tsc 6, 13x for VS Code, 25x for Playwright and 29x for Excalidraw. All of these are the author's own measurements. The 180,000 tests check whether the answers are correct, not whether it is fast in every real-world setup.

Who looks after code nobody has read?

On Hacker News, "Port of the TypeScript compiler, checker and lsp to Rust, by LLM" drew 112 points and 211 comments. Daniel Rosenwasser of the TypeScript team commented as well: "Impressive work. Honestly, it's remarkable that three ports like this have appeared in the past week." That kind of praise from someone on the original project means a lot.

The same thread had plenty of more skeptical voices. The one that hit me hardest asked how you add new code to a codebase that no one has ever read. TypeScript gains new syntax every year, so the compiler has to change each time. The worry is whether it's OK that, when that happens, no human knows how it works inside.

Others pointed to the tests. The 180,000 tests were written by people who deeply understood the original implementation. Passing all of them doesn't prove the AI understands the code. If a bug sits in a gap the tests don't cover, nobody will notice. The missing parallelism in Issue #15 was exactly that kind of problem: correct output, just slow, and invisible to the tests.

There is also a more deflating view: the percentages look dramatic, but the actual savings may be only 1–3 seconds per compile. That matters to someone who builds hundreds of times a day. Whether it's worth the maintenance uncertainty will vary from person to person.

Here is my conclusion. Given a correct reference implementation and 180,000 tests, a port can be written. That has now been shown in practice. What hasn't been decided is who answers the bug reports once it's written, and who keeps up with new TypeScript features. This time, Theo fixed the problem the next day. Whether the project keeps leaving the work to agents, or a human eventually reads the code, is the open question.