tsc-rs Passes 181,711 Tests and Nobody Has Read the Code. The Test Suite Is Now the Spec

pingdotgg/ts-rust is an LLM-written Rust port of the TypeScript compiler, and its README is the most useful document yet on what that kind of software actually promises

There is a new TypeScript compiler written in Rust, and the person who published it says, in its README, "I've never read a line of this code."

That sentence would have ended a project's credibility two years ago. Today it sits in the Warnings section of pingdotgg/ts-rust, a port of Microsoft's Go-based TypeScript compiler, checker and language server, published to npm as tsc-rs and tagged v0.1.0 on October 7. The same README says "All 181,711 ported Go tests pass" and claims "100% compatibility in every real world project we have tested."

Both statements can be true at once. The interesting question is what they add up to, because this is the shape a lot of software is about to take.

The stakes: who holds the spec when nobody reads the code

For as long as compilers have existed, the spec lived in two places: a document and the heads of the people who maintained the code. Tests were a safety net under both.

An LLM-written port with no human reader removes one of those places entirely. Nobody on the project can tell you why a given branch exists, which edge case a function is guarding, or what the original Go authors assumed was too obvious to test. What remains is the test suite. It stops being a safety net and becomes the definition of correct.

My position: that is a workable trade for some uses and a dangerous one for others, and the way to tell them apart is to read the project's list of known failures more carefully than its list of wins. tsc-rs, to its credit, publishes both.

What the README actually claims

Strip away the Hacker News reaction and the claims are specific.

On correctness, all 181,711 ported Go tests pass, and on two named projects (TanStack Query core and Hono) the diagnostics are "identical to Go's." On speed, the README reports that across 60 open-source projects, type checking takes "about half of Go's time (geometric mean)," with a real-world table measured on an Apple M4 Pro with 12 cores and 48 GB under macOS 26.5.1.

On how it got built, the numbers get dramatic. The author writes that an earlier attempt with OpenAI models cost "over $400,000 in API priced tokens with GPT-5.6 Sol and GPT 6 Astra," and elsewhere that GPT models "wrote over 1.3m lines of Rust over multiple months of /goal loops and never got past like 84% compat." Then: "Opus 5.5 started from scratch. It got further than Astra in 1/10th the time." The Opus run's total was "~$24,047 of API spend over 2 weeks." Across both attempts the author puts the cost at over $420,000 in tokens, adding "you could probably have done it for ~$20k."

Install is two lines:

npm install -D tsc-rs
npx tsc-rs -p tsconfig.json

Licensing is clean for a project like this. The LICENSE file is MIT, held by T3 Tools Inc., and a NOTICE file carries the upstream Apache-2.0 notice for TypeScript and BSD-3-Clause for the Go standard library code.

The Known problems list is the real spec sheet

Here is the part worth slowing down for. Directly under the "100%" line, the README lists four known problems.

In some monorepos, where a workspace package's source files are reachable two ways, tsc-rs can emit more output files and report TS6059 for them. The README notes that tsc's own result varies between runs in that situation.

Under tsc -b, when one project imports another project's output without a project reference, tsc-rs can read stale or missing output and throw TS2305 or TS2307. Adding the reference fixes it.

In the editor, memory grows slowly during long sessions, "about 20 MiB per 1,000 edits." The README adds that memory starts 12 to 24 percent above tsc and drops below it after about 20 edits in its measured sessions.

And tsc-rs --version prints the TypeScript version it ports (7.1.0-dev), not the npm package version.

None of these is a disaster. Every one of them is a place where the test suite did not encode a behavior that real projects depend on. Monorepo reachability, build-mode ordering, long-session memory, version reporting: these are the behaviors that live in maintainers' heads and in bug trackers, not in unit tests. That is exactly where an unread port will drift, because there is nobody to notice the drift except users.

So the "100%" claim is accurate in the narrow sense the README states it: every real-world project the author tested. The Known problems section tells you the boundary of that sentence. Read together, they describe a compiler that matches the reference on everything the reference's tests and the author's sample projects exercise, and an unknown amount beyond that.

What the HN thread got right, and wrong

The Hacker News discussion split along a predictable line. One commenter argued that LLMs keep fixing compile errors until tests pass, leaving "a codebase no one has read" that is hard to extend later. Another asked whether a reimplementation checked against years of human tests will still miss behaviors the original authors assumed were obvious. Others answered that humans introduce the same kind of gaps, and pointed at the speed numbers.

Both camps are partly right, and the README itself settles the argument better than either. The skeptics are right that the test suite is now carrying the whole spec. The optimists are right that it carries a lot: 181,711 tests is a serious body of encoded behavior, and the README shows real projects passing. The question is never "does it work." The question is "where does it stop working, and will you find out before your users do."

One more thread detail worth noting: a commenter on the TypeScript side called the work "impressive" and said the team was hoping to learn more. That is the right tone. A port like this is most valuable as an experiment that tells the original maintainers which of their behaviors were never written down.

Put this into practice

If you want to try tsc-rs, treat it as a second opinion, not a replacement.

Run it beside tsc, not instead of it. Install it as a dev dependency, run npx tsc-rs -p tsconfig.json next to your normal type check, and diff the diagnostics. Any difference is either a tsc-rs bug or an undocumented tsc behavior. Both are worth knowing.

Check your repo against the four known problems first. If you run a monorepo with packages reachable two ways, or use tsc -b with cross-project imports that skip project references, you are in the documented failure zone. Add the missing references before you judge the tool.

Benchmark on your own machine. Every number in the README comes from the author's own runs on one Apple M4 Pro, some against preview or patched builds. Your CI box will tell you something different.

Watch the platform list. tsc-rs ships for Linux x64 and macOS arm64 only. Windows and Linux arm64 are not available yet, which rules it out for many CI fleets today.

Apply the lesson to your own agent-written code. This is the bigger takeaway. If your team ships code an agent wrote and nobody reviewed line by line, your test suite is now your spec. Ask what lives in your heads and your issue tracker but not in your tests, then write those tests before the next agent run.

The honest limitations

The author is candid, and you should take the candor at face value. The README calls this "an early release" and says "I have no idea if this will actually work." That is not modesty. It is an accurate description of a codebase with no human reader.

The cost figures are not a recipe. The $420,000 figure includes a failed earlier attempt priced at API rates, and the HN thread pushed back on reading it as actual spend. The number that matters for anyone thinking of repeating this is the roughly $24,047 Opus run, and even that is one person's experiment, not a reproducible process.

The benchmarks are self-run. The real-world comparison table, the "half of Go's time" figure and the speedups against tsc and bun check all come from the author's setup. They may hold up, but nobody independent has reported them yet.

Maintenance is the open question. One HN commenter put it bluntly: "Is this going to be maintained? Nope" The README does not answer that. A compiler you adopt is a compiler you depend on through every TypeScript release, and a port with no human who understands its internals has to be regenerated or patched by agents each time upstream moves.

And the deepest limit is structural. A test suite can tell you that the port matches the reference on every case someone thought to write down. It cannot tell you about the cases nobody wrote down, which is precisely where the Known problems list came from.

Read the list, then decide

tsc-rs is a remarkable artifact: a working TypeScript compiler, faster than the reference on the author's benchmarks, written by models in weeks, published with a straight face about how little any human understands it. It is also a preview of how a lot of ports and rewrites will arrive from here on.

The useful habit it teaches is simple. When software arrives with a headline number like "100%," scroll down to the section where the authors list what breaks. That list is the spec nobody wrote, and it tells you whether your codebase lives inside the tested world or just outside it.

Sources: pingdotgg/ts-rust README · tsc-rs on npm · Hacker News discussion

Medium metadata

Title: tsc-rs Passes 181,711 Tests and Nobody Has Read the Code. The Test Suite Is Now the Spec
Subtitle: pingdotgg/ts-rust is an LLM-written Rust port of the TypeScript compiler, and its README is the most useful document yet on what that kind of software actually promises
Tags: TypeScript, Rust, AI Coding, Claude, Software Engineering
Canonical URL: import from the fervorai.dev post
Reading time: about 8 minutes