Linear says AI-assisted coding made its pull-request validation lag behind code production. According to the company’s account, its test suite nearly quadrupled while average PR wait time fell from more than six minutes to just over five and runner time per test dropped by roughly half. These are Linear’s own reported measurements, not an independent benchmark.

The company’s main lesson is that CI speed is a system problem. Faster runners helped: Linear says jobs ran 34% faster on average after moving workloads to infrastructure with quicker CPUs, storage, and caching. But it also shortened checkout steps, removed unnecessary work from the merge path, preinstalled shared dependencies, and installed only the packages each job needed. Per-shard setup fell about 44%, from 110–140 seconds to 67–73 seconds.

GitHub Actions workflow timings comparing two test-api CI runs
Linear’s GitHub Actions comparison shows the test-api run falling from 4m 57s to 3m 14s.linear.app

The step-by-step timings make the pipeline-speed gains concrete after the discussion of faster runners, shorter setup, and reduced critical-path work.

The largest gains came from changing how tests ran, not merely where they ran. Linear split large test files, moved from four API shards to eight, and introduced an opt-in shared Vitest module registry for files that could safely use it. The company says the slowest shard dropped from roughly 300–379 seconds to about 195 seconds, while API-shard runner time fell from about 32.8 to 22 minutes per run.

Before-and-after CI pipeline batching workflow with execution timings
A before-and-after workflow view illustrates how batching and dependency changes shortened CI stages.linear.app

This figure supports the article’s explanation that reorganizing work and dependencies, not only changing hardware, contributed to faster validation.

Module state caching diagram comparing individual and shared state
The shared-state diagram illustrates the optimization behind Linear’s Vitest module registry.linear.app

The before-and-after structure clarifies how sharing one state reduced redundant rebuilds while the article also notes isolation requirements for unsafe files.

That optimization carries a correctness cost. Shared module state can expose fake timers or other state interactions, so Linear kept unsafe files isolated, added teardown, and updated guidance for generated tests. The practical takeaway is narrower than “buy faster runners”: when AI increases change volume, CI gains often come from reducing repeated setup, shortening critical-path jobs, and parallelizing only where isolation rules remain safe.