The news
Linear published its continuous integration rebuild on 21 September 2026 after a sharp rise in test work from faster software delivery. The company says its test suites grew to 3.7 times their January size while machine time per test fell 46 percent.
Pull-request wait time moved from more than six minutes to just over five minutes. Linear says it also cut runner time per test roughly in half. Those results came from infrastructure, toolchain, scheduling and test-execution changes across a TypeScript codebase.
The useful part of the post is the sequence. Linear first changed runners and compilers. It then removed small jobs from the critical path, cut repeated setup and increased useful parallelism.
Caption: Linear reports that tests per pull request reached 3.7 times the January level while machine time per test fell 46 percent · Source: Linear, 21 September 2026 · link
Who is bound
The post applies most directly to teams where coding agents have increased pull-request volume and test coverage. Every generated change still waits on checkout, setup, compilation, lint and tests. Small delays multiply when the queue grows.
Linear's repository is primarily TypeScript. Its exact tool choices will not transfer to every stack. The operating method does: measure the critical path and total runner time separately, then remove repeated work before adding more shards.
The findings also matter to platform teams that pay by runner-minute. A faster test wall clock can consume more machines. Linear tracked both developer wait and compute use, which exposed optimizations that a single duration number would hide.
What's new
Linear moved workloads from GitHub Actions-hosted runners to third-party runners with faster processors, storage and cache infrastructure. In a two-day comparison around the switch, jobs ran 34 percent faster on average. The TypeScript compiler check fell 52 percent for some workloads.
A move to tsgo, the native TypeScript compiler, cut the weekly median compiler check by 73 percent. Linear also rewrote custom lint rules to use syntax trees without the TypeScript type graph. It reports a 68 percent reduction in application programming interface lint time and 55 percent for the full repository.
The scheduling work produced smaller but broadly repeated gains. A change-detection job fell from a 26-second median to eight seconds after shallow, sparse and blobless fetches. Moving a cache-marker write away from the merge gate removed 42 seconds from the critical path for application programming interface pull requests.
Linear also combined seven short checks into two jobs and ran the tasks concurrently inside them. Based on June usage, the company attributes about 87,000 saved runner-minutes per month to that change, equal to 11.8 percent of its continuous integration use.
What it does not settle
These are internal measurements from one repository and one delivery system. The post gives useful before-and-after numbers, but it does not provide a controlled benchmark or a public reproduction package.
The runner comparison spans two days around a provider change. Workload mix and queue conditions can move at the same time. The larger trend across the year is clearer, though it still belongs to Linear's codebase and test design.
The article also links agent-driven output to growing integration load without isolating the agents as the only cause. Test suites expanded, tooling changed and delivery volume rose together. Teams need their own queue, cache and runner telemetry before assigning a cause.
What to do now
Measure two values for every required check: elapsed time on the pull-request critical path and total runner time. Rank work by how often it runs and how many downstream jobs it blocks.
Then inspect the pipeline in this order:
- Remove full checkouts from jobs that need only metadata.
- Use shallow, sparse or blobless fetches where a working tree is required.
- Bake stable system dependencies into the runner image.
- Consolidate tiny checks so setup cost is paid fewer times.
- Move cache writes and reporting work off the merge gate.
- Increase test shards only after fixed setup cost falls.
Agent adoption makes this audit more urgent because the same fixed cost is paid across more changes. The first target should be repeated setup and blocked fan-out. Those costs waste both human time and machine time.