The Verifier Got Cheap: What TypeScript 7 Actually Changes for Coding Agents

TypeScript 7 shipped on July 8, the completion of a Go rewrite of the compiler. Microsoft claimed 8x to 12x. I didn’t want the launch benchmarks, which are all run on codebases I don’t have, so I ran it against two repos I do: this blog, and the Next.js app behind famecake.com.

Both numbers landed in the claimed band. The interesting parts were elsewhere.

The Measurements

Apple M5 Max, 18 logical cores, median of five warm runs each, --incremental false so nothing is cached between runs.

This blog (Astro, 9,140 lines, 1015 files loaded including lib and @types):

FameCake (Next.js 16, 1,006 files, 159,320 lines):

That’s 8.0x on the blog and 9.8x on FameCake, comparing configurations that produce identical diagnostics. The bigger codebase got the bigger multiple, which is what you’d expect once process startup stops being a meaningful share of the run.

Two controls, because a speedup is only real if both sides do the same work. On the blog, both versions loaded exactly 1015 files, and the only difference in the file list was that 7.0.2 reads its libs from a native platform package. On both repos the diagnostics were identical: same errors, same codes, same line and column, same order. On FameCake the only textual difference in the output was the relative path prefix.

Where the Speed Comes From

We quickly realized we could get 10x, half of it from being native code, and the other half from being able to take advantage of shared memory concurrency.

— Anders Hejlsberg, on the TypeScript 7 rewrite

You can see that split in the CPU columns. TypeScript 5.9.3 pulled 156% utilisation, roughly one and a half cores on a machine with eighteen. TypeScript 7 pulled 422% while burning three times less total CPU time. It is doing less work, and what work remains it spreads across cores that were previously sitting idle.

Single-threaded JavaScript was leaving most of the machine unused. That was the ceiling, and no amount of optimising the old compiler was going to lift it.

Why This Compounds

A 10x on a build step is a nice-to-have. A 10x on the innermost loop of a process that now runs continuously and unattended is a different thing.

An agent’s loop is edit, verify, correct. The cost of verification determines the shape of that loop:

• At 7.67 seconds you batch. The agent makes ten or twenty edits and then checks, because checking after each one dominates the wall clock. Errors surface far from the edit that caused them.
• At 0.78 seconds you don’t. The agent checks after every meaningful change, and an error surfaces while the reasoning that produced it is still in context.

The difference isn’t the seven seconds. It’s that batched verification means the agent spends tokens re-deriving which of twenty edits broke things, and keeps building on a foundation it doesn’t yet know is broken. Every edit made on top of an undetected type error is work that may need unwinding. That’s the compounding: not one faster check, but a shorter distance between a mistake and the signal that it was a mistake, repeated a few hundred times a session.

Type errors are also the cheapest high-signal feedback an agent can get. No test harness to write, no fixtures, no tokens spent interpreting a failure. The compiler either accepts it or points at a line.

The Migration Trap Is in 6, Not 7

This is the part I did not expect, and it inverts the usual advice.

Going from 5.9.3 to 6.0.3 on FameCake bought no speed at all (7.67s to 7.32s, inside the noise) and produced 37 new errors. Going from 6.0.3 to 7.0.2 bought 10.8x and produced zero new errors.

The 37 weren’t real type problems. Every one traced to the google namespace, and @types/google.maps was installed the whole time. TypeScript 6 changed the types default from “include everything in @types” to an empty array. FameCake’s tsconfig has no types field, so a dependency that was already there silently stopped being loaded. Passing --types google.maps takes it straight back to zero.

Then it caught me a second time on this blog. Turning the check on, import.meta.dir stopped resolving and did not come back until I put "types": ["bun"] in the tsconfig. Same default, different dependency, same twenty minutes of confusion. Two repos, two hits, neither of them an actual type error.

So the scary version number is a drop-in, and the boring one is where your afternoon goes. If you’re planning an upgrade, budget for the config semantics of 6 and expect 7 to be uneventful.

What It Doesn’t Solve

• It only catches type errors. A verifier this cheap is tempting to over-trust. It will not catch a wrong sort order, an off-by-one, or a misunderstood requirement. It complements tests, it doesn’t replace them.
• Editors are still on the old compiler for a lot of us. TypeScript 7 doesn’t expose a stable programmatic API yet, so Volar-based tooling stays on 6. That’s Vue, Svelte, Angular templates, MDX and Astro. This blog is Astro plus MDX, so the editor path here gets none of this until 7.1, expected around October.
• Watch mode already existed. Incremental rechecks were never seven seconds. The honest claim is about cold full checks becoming cheap enough to run unattended, in CI, and on every agent turn, not that nobody could get fast feedback before.
• Speed was not my actual bottleneck. Setting this up revealed that my blog had no type-check step at all. No tsc, no astro check, and six real type errors sitting in the repo unnoticed. TypeScript 5.9.2 was in node_modules transitively, unused. 2.56 seconds was never what stopped me.

That last one is worth sitting with. The compiler getting 10x faster is only load-bearing if you were running it. A lot of projects, including mine, skipped that step entirely and never noticed, because nothing in the build was going to tell them.

So I fixed it rather than just recommending it. The six errors are cleared, there’s a typecheck script, a PostToolUse hook runs tsc after any agent edit to a .ts file and feeds failures straight back into the session, and the Docker build runs astro sync && typecheck so a type error fails the deploy instead of reaching the site. The hook is the piece that only makes sense at 0.32 seconds. At 2.56 it would have been an annoyance I’d have deleted inside a day, which is the whole argument in one config file.

The Takeaway

• The 8-12x claim survives independent measurement. I got 8.0x and 9.8x on unrelated repos with controlled file counts and identical diagnostics.
• Upgrade through 6 carefully, then through 7 casually. The breaking changes live in the release nobody is talking about.
• Check your types field explicitly. If your tsconfig omits it, you’re relying on a default that changed.
• If you run agents, wire up a type-check and put it in the loop. Sub-second full verification is new, and it’s most valuable to the worker that never gets bored of running it.

The compiler didn’t just get faster. It got fast enough to move from a gate you pass at the end to a sense you check continuously, which is a different tool wearing the same name.