Linear says coding agents have pushed its software bottleneck into continuous integration. Its test suites nearly quadrupled since the start of 2026, yet the company cut pull request wait time from more than six minutes to just over five. Runner time per test fell by roughly half.
The result came from changes across the pipeline rather than one faster test runner. Linear moved away from GitHub Actions runners, shortened critical-path jobs, removed repeated setup, and changed how it split tests across machines.
Faster code made feedback more expensive
Every pull request still has to pass the same checks, whether a person or an agent wrote the code. More generated code therefore raises both the demand for compute and the time developers or agents spend waiting for feedback.
Linear says agents now write the majority of its tests. The company also says it adds about 2,000 tests a week. Without its CI work, it estimates that the current suite would take roughly 11 minutes, close to twice the present wait.
Some of the first improvements came from faster infrastructure and tools. Moving to third-party runners made jobs 34% faster on average in a comparison of the two days before and after the switch. The native TypeScript compiler, tsgo, cut the weekly median type-check time by 73%. Rewriting custom lint rules so they no longer needed TypeScript’s type graph cut full-repository lint time by 55%.
Small gate jobs controlled the whole pipeline
Linear then focused on jobs that had to finish before other work could start. Its change-detection job had checked out more of the repository than it needed. Limiting or removing those checkouts cut the job’s median duration from 26 seconds to eight seconds and its 90th-percentile duration from 31 seconds to 12.
The company also moved a cache-marker write off the merge path, saving 42 seconds for API pull requests and merge-queue entries. These changes mattered because every test shard waited behind the same gate.
Limiting checkout cut the change-detection job from 26 seconds to 8 seconds at the median. Doubling the shards, from 4 to 8, was about 19% faster and about 19% cheaper in Linear's first benchmark.
Repeated setup created a different cost. Seven short checks each started a runner, checked out the repository, and installed dependencies. Linear combined them into two jobs and ran the checks concurrently inside those jobs. Based on June usage, it says the change saved about 87,000 runner-minutes a month, or 11.8% of total CI use.
Filtering package installation to the API workspace cut install time from 44 to 73 seconds down to 16 to 18 seconds. Restoring a node_modules cache took about 28 seconds, while a filtered install took roughly 7.5 seconds, so Linear stopped using that cache.
Lower setup costs made more shards worthwhile
After reducing fixed setup work, Linear doubled its API test shards from four to eight. Its initial benchmark found that configuration about 19% faster and 19% cheaper. A week later, the slowest shard had fallen from 5.25 minutes to 4.33 minutes.
The largest single saving came from letting selected Vitest files share a module registry instead of rebuilding the same application graph for every file. Linear made this an explicit opt-in because shared state can make tests affect one another. The slowest shard fell from roughly 300 to 379 seconds to about 195 seconds, while total API-shard runner time dropped from about 32.8 minutes to 22 minutes per run.
That change also reached the coding agents. Linear updated its agent instructions so newly generated tests follow the opt-in constraints.
