What Faster Type Checks Left Me Wondering

When I first saw a measurement saying TypeScript 7’s type checks were four or five times faster, my first question was, “Which app?” A large speedup can mean very different wait times depending on whether a check used to take one second or sixteen.

So I compared 18 apps and services in Firstage that run a type check. For each app and service, I ran its type-check command three times on both TypeScript 6 and TypeScript 7, with incremental caching disabled, and used the median runtime. All 18 passed on both versions. The speedup ranged from 2.15× to 6.24×, with a median of 4.84× across packages.

Check	TypeScript 6 → 7	Speedup	Time saved per run
asset-service	4.65 → 0.75 sec	6.24×	3.90 sec
Journey app	11.55 → 2.62 sec	4.42×	8.93 sec
Journey worker	15.99 → 5.88 sec	2.72×	10.11 sec
Journey API	16.17 → 6.70 sec	2.41×	9.46 sec

asset-service had the largest speedup. The biggest reduction in one run was in the Journey worker: 10.11 seconds saved, even though the speedup was 2.72×. The Journey API saved 9.46 seconds with a speedup of 2.41×. The ranking by speedup was not the same as the ranking by time saved.

Seven checks that originally took less than three seconds had a median speedup of 5.57×, but the median time saved per run was only 1.39 seconds. For the eight checks that took between three and ten seconds, the two medians were 4.84× and 4.18 seconds. For the three checks that took more than ten seconds, they were 2.72× and 9.46 seconds. These are observations from this sample. They do not show that TypeScript 7 has less impact on larger checks. One second may still matter if a short check runs many times a day, but I have not measured how often these checks run.

Time developers spend waiting

For me, a type check is one way to get early feedback after changing code. When the result comes back quickly, I can make another change while the code I just touched is still fresh in my mind. Even when AI produces a draft quickly, I still have to check that the code works as intended and fix what does not. These days, I pay as much attention to how long reliable feedback takes as to how quickly code gets written.

I measured only local type checks. I did not include builds, tests, CI queues, or review time. The asset-service type check becoming 6.24 times faster does not mean that its build or the time to finish a change also became 6.24 times faster.

Two clocks a founder has to consider

In a small team, both people’s focused time and computing resources are limited. But treating them as the same number can lead to the wrong priorities. The weight of one or ten seconds depends on how often a check runs and whether it prevents another check from starting. These measurements do not show run frequency or the actual CI path, so neither the highest speedup nor the longest duration is enough to decide what to invest in next.

I did not measure total CPU time, memory, or CI runner charges either. If the time people wait on screen falls to a quarter, that does not mean computing costs also fell to a quarter. We need to track the time returned to people separately from the resources used by machines.

A question I took from Linear’s write-up

In its recent article, “AI coding has made CI a bottleneck, so we reworked ours to keep up”, Linear said the weekly median for tsc checks fell by 73% after it moved to native TypeScript. But the part I kept thinking about was the change-detection job. Its median dropped from 26 seconds to 8 because this small step was blocking eight API test shards from starting. Even a short check can hold up everything behind it when it sits on the critical path.

Linear also looked separately at PR CI wait time and runner time per test. While the test suite had grown to almost four times its size at the start of the year, PR wait time fell from more than six minutes to just over five, and runner time per test fell by roughly half. The team made several changes together, so we should not read the 73% improvement in tsc as the improvement across all of CI. I cannot assume the same numbers apply to Firstage.

Running tests in parallel can reduce how long people wait while increasing runner usage. That is why I noticed that Linear reduced setup time before splitting up the tests. I read that as a separate decision about where to spend more computing resources to save time and where to remove waste first.

What I want to find out at Firstage is which checks actually make developers wait. I need to know how often each one runs, whether it blocks the next CI step, and how long it occupies a runner. Only then can I say what TypeScript 7 changed for my work and for the resources the team uses.