Why TypeScript 7's VS Code Benchmark Won't Predict Your CI Build Times
A reported 11.9x faster VS Code build with TypeScript 7 is a real-looking compiler result, but it is one multiplier on one codebase with no published hardware, flags, cache state or run count. This video walks through what that means for your pipeline. We use extended diagnostics to find what fraction of your compile sits in check time, the phase that parallelizes worst, then put that fraction into Amdahl's law. Even a compiler that took zero seconds leaves most of a CI job untouched: install, bundling, tests and checkout don't move. In the editor the language service keeps a program in memory; in CI every run rebuilds from scratch on a couple of shared vCPUs, and cross-commit incremental builds are harder than they look. The takeaways: measure your own tsc share of wall clock, report p50 and p95 instead of one lucky run, watch instantiation counts before blaming the compiler, and change the compiler and the bundler in separate commits. Full write-up with the timing harness, the projection table and the migration checklist: https://hackyjs.com/posts/why-typescript-7s-vs-code-benchmark-wont-predict-your-ci-build-times Note: numbers shown on screen for diagnostic output and CI phase shares are illustrative placeholders. Projections use the speedup formula from the post with s = 11.9.