This week Theo Browne published tsc-rs, a Rust port of the TypeScript 7 compiler, type checker and language server. The README says Claude Opus wrote it. It took about two weeks, and the later stage cost roughly $24,000 in API spend. The repo reports that all 181,711 ported Go tests pass.

That is a headline number. But the more useful number is the one that came before it.

The failed attempt matters more than the win

According to the project's own write-up, an earlier attempt with OpenAI's Codex ran for around five months, produced over 1.3 million lines of Rust, and stalled at roughly 84% compatibility. The token bill for that attempt was reported at $400,000 or more. Then a fresh start with Opus reached a working version in about ten hours.

Different models, sure. But the same target and the same tests. Nobody argued about whether the second attempt was "right". A number went up.

We'd be careful with the cost figures. The README mixes API spend with subscription-limit estimates, so don't treat them as a clean benchmark. The shape of the story holds either way.

What made this possible

A TypeScript compiler is about the best possible case for agent work, and not because it is easy. It is the opposite of easy. It works because:

There is a reference implementation (Microsoft's Go port) that defines correct behavior.
There are 181,711 tests that encode that behavior, including ugly edge cases nobody remembers writing.
Pass or fail is binary. An agent never has to guess whether it is done.

Take those away and the same model on the same task gives you a confident pile of plausible code. The tests are the spec. The model is the labor.

What this means for your product

Most teams don't have 181,711 tests. Most teams have a wiki page, three people who remember why things work the way they do, and a staging environment that sort of mirrors production.

So before you point an agent at a migration, a rewrite, or a big refactor, ask one question: what is the oracle? What tells the agent, without a human in the loop, that the output is correct?

If the answer is "a person will review it", you've built a review bottleneck, not an automation. If the answer is "the old system's behavior, captured as tests we can run in seconds", you are in the zone where a fixed-scope rewrite stops being a quarter-long project.

Some practical places to start:

Characterization tests first. Before touching a legacy module, record what it actually does on real inputs and lock that in. Let the agent chase those tests.
Keep the old system runnable. Differential testing against the old implementation is a cheap oracle you probably already have.
Budget for the failed attempt. The five-month run is a reminder that an agent without a tight feedback signal can burn a lot of money while looking busy. Cap spend per attempt and check the pass rate early.

Also worth saying: passing the ported tests is not the same as being production ready. It is a strong signal, and a good reason to run it against your own real projects next. But the bar was at least well defined.

The takeaway

The model gets the credit in the headlines. The test suite deserves it. If you want agents to do big, boring, high-value work for you, invest in the thing that tells them when they're right.

We're here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you're looking to build something, get in contact with us today!