An Agent Wrote a TypeScript Compiler in Three Weeks. The Reason Why Matters More Than the Speed.
Synergised Consulting Ltd
Last Updated: 21 October 2026
An AI agent has written a working Rust port of the TypeScript compiler, one of the most heavily tested programs in software, and Microsoft has already shipped some of the port's discoveries into its own TypeScript 7.1. What made this possible was not a smarter model. It was a test suite that could tell the agent, case by case, whether it was right, and that mechanism is the part worth copying into any business running agents today.
What tsrs actually is
tsrs is a drop-in replacement for the TypeScript 7 compiler and language server, written in Rust, now stewarded by Cloudflare and VoidZero inside the Oxc toolchain [1]. It is not a fork, and the distinction is doing real work here: the project tracks the main branch of Microsoft's TypeScript, and both Cloudflare and the TypeScript team have been explicit that Microsoft stays in charge of the language's direction [1]. The port began on 30 September at Owner.com, where engineer Max Schwenk asked a model whether it could one-shot the port, and later confirmed he wrote none of the code himself, directing more than 20 subagents instead [3].
To picture the scale: TypeScript is the type checker sitting under most of the web's JavaScript code, and Microsoft itself rebuilt it from JavaScript into Go partly because the original had grown slow at large scale. A faithful port is not a fresh start. It has to reproduce, exactly, the errors the original produces, including the order they appear in, or every project that depends on those errors breaks silently. That is what "faithful" means here, and it is why the result is more surprising than the usual agent-written demo.
What the speed numbers compare, and what they do not
The headline figures come with a fixed comparison, not a moving one: at the same number of type-checker threads, Cloudflare reports tsrs up to 8x faster and using about 70% less memory than TypeScript 7.0 [1]. Owner's own backend, roughly 37,000 TypeScript files checked as one program, went from an 80-second single-threaded check needing 19 GiB of memory on TypeScript 7.0 to about 7 seconds in CI on tsrs [3]. Microsoft's independent numbers land in the same territory from the other direction: TypeScript 7.1 beta cut the mui-docs codebase from 22.2 seconds to 11.9 seconds, a 1.9x speedup, and nearly halved memory on that project [2].
Measure (mui-docs, 4 checker threads) | TypeScript 7.0 | TypeScript 7.1 beta |
|---|---|---|
Check time | 22.2s | 11.9s (1.9x) |
Peak memory | 8,093 MiB | 4,079 MiB (49.6% less) |
What the numbers do not say is that Rust beat Go in a straight race. Daniel Rosenwasser, Microsoft's principal product manager for TypeScript, said publicly that a lot of the speed does not just come down to language choice, and that some of what makes 7.1 faster was discovered in tsrs first [4]. The comparison is between one implementation that has been tuned for three weeks by an agent running experiments around the clock and one that has been tuned by humans between feature releases. The gap says something about iteration speed, not about which language wins.
Why an agent could do this at all
The reason is specific: the project inherited 15,197 conformance test cases left behind by TypeScript's earlier JavaScript-to-Go migration, and Schwenk's team treated that suite as the specification, the one thing that told every agent whether its work was right [3]. On the first end-to-end run, 78% of the error baselines matched byte for byte; after a type printer was added, the match rate reached 99.97%, all but four of 13,462 [3]. Every optimisation landed only if it cut single-threaded instructions by at least 1%, wall time by 2% or peak memory by 5%, with byte-identical output, a written bar that stopped the agents grinding the codebase into pointless micro-optimisations [3].
The loop itself is worth reading closely, because it is ordinary and that is the point. Take a baseline. Read the profile. Change one thing. Diff the output against the original. Benchmark. Keep it or throw it away, and write the decision down so no agent tries the same experiment twice [3]. That is a disciplined engineering process with the typing outsourced. The model supplied effort and breadth; the oracle supplied truth. Schwenk put the same caution plainly: a faster compiler that finds fewer errors is a broken compiler with good marketing [4].
In discovery workshops, the work that turns out to be worth automating is almost never the glamorous judgement calls. It is the repetitive, screen-shaped bundles that come with a check attached, where someone can say unambiguously whether the output is right or wrong. The tsrs result is that observation scaled up to a compiler: the port succeeded where the answer to "is this correct?" could be produced mechanically, 15,197 times, on demand.
What tsrs is not for yet
It is explicitly experimental, and the gaps are stated rather than hidden. The repository says the goal is a stable release against TypeScript 7.1 with full conformance, but that some differences from upstream remain today, including the order in which diagnostics print, and that commands like --init and --showConfig are not supported [5]. Cloudflare's own benchmark caveats note that much of the headline gap comes from memory headroom at higher thread counts rather than raw speed [1], and the project has closed pull requests for now because the small team cannot review them [5]. Owner.com runs it across its monorepo in production, but that is one company with a verification harness built around it, not a general recommendation.
The practical test before any business adopts a tool like this is the same one the port itself passed. Deliberately introduce known errors and confirm the tool still catches every one. Run the memory-safety checker against the optimised build, because that is where tsrs's own reviewers found a bug the debug build hid [4]. A tool that is fast but silent about what it misses is worse than a slow one, and the teams behind tsrs clearly know it.
The part that already reached Microsoft
Within a day of Cloudflare's announcement, Microsoft shipped the TypeScript 7.1 beta, up to 2.5x faster than 7.0, and acknowledged that some of those optimisations were upstreamed from tsrs [1]. The two teams now share performance work while keeping the implementations in sync, and Cloudflare plans to run the same nightly agent-based syncing process it uses to track Next.js changes for its own reimplementation [1]. An agent-written derivative is now feeding improvements back into the original, with the original's maintainers still steering. That arrangement, contribution rather than replacement, is the least-discussed and most transferable part of the story.
What this changes for teams running agents
Strip away the compiler and the lesson is small enough to act on this week: agent output quality tracks the quality of the check the agent works against, not the size of the model. Before adding capability to an agent workflow, ask what tells the agent it is wrong. If nothing does, build that first, even if it is crude. Our own delivery work with coding agents has the same shape: the value concentrates on the testing side, the harness that proves a change is safe, and the discoveries from agent experiments are worth feeding back into the human-documented standard rather than living only in the agent's own context. The teams getting real returns from agents are not the ones with the most powerful model. They are the ones who made being wrong cheap and being right verifiable, and then let the machine iterate against that.
Sources
- [1] Cloudflare blog, "Introducing tsrs: a Port of TypeScript to Rust", 20 October 2026,
- [2] Microsoft TypeScript blog, "Announcing TypeScript 7.1 Beta", 20 October 2026,
- [3] Owner.com engineering blog (Max Schwenk), "tsrs", 19 October 2026,
- [4] The New Stack, Paul Sawers, "We are not forking TypeScript: Cloudflare spearheads Rust port written by agents, for agents", 20 October 2026,
- [5] oxc-project/tsrs repository,
