AI Coding Has Made CI a Bottleneck, So We Reworked Ours to Keep Up

Linear ran into a familiar problem: code was moving faster than the machinery that checks it. Agents made it easier to ship changes, but every pull request still had to pass CI, and that was turning into the slow, expensive part. Tuomas, the CTO, even filed the issue himself: “CI costs are high.”

The team attacked the problem from several angles, and the wins added up. By moving workloads off GitHub Actions onto third-party runners with faster CPUs, better storage, and stronger cache infrastructure, they got jobs to run 34% faster on average in a like-for-like comparison. Some workloads did even better. The tsc check dropped 52% on that switch alone, and later changing to tsgo, the native TypeScript compiler, cut the weekly median of tsc by 73%.

They also pulled TypeScript out of linting where they could. A few custom rules had been relying on type information, which forced ESLint to build the full type graph before it could even start. Rewriting those rules to work on syntax instead cut API lint time by 68% and full-repository lint time by 55%. After that, Oxlint became easier to adopt because syntax-only rules are much simpler to port.

The biggest theme, though, was that tiny jobs were sitting on the critical path and wasting everyone’s time. Linear trimmed change-detection jobs by fetching less, or nothing at all, when a working tree wasn’t needed. It replaced checkout with a retrying composite action after network hangs showed up on the third-party runners. It moved cache writes off the merge path, saving 42 seconds for every API pull request and merge-queue entry. Even those small changes mattered because none of the eight API test shards could start until the gatekeepers finished.

Then came the boring work that usually decides whether CI feels snappy or miserable: setup. Installing the same Postgres client in every shard, installing the full pnpm workspace when only the API package was needed, caching node_modules when rebuilding was faster — all of that got pared back. The result was a roughly 44% reduction in per-shard setup time, from 110-140 seconds to 67-73 seconds. Seven short checks were collapsed into two jobs, saving roughly 87,000 runner-minutes a month, or 11.8% of total CI usage.

And with the fixed costs down, Linear could shard more aggressively. Eight shards made the critical job roughly 19% faster and 19% cheaper in the initial benchmark, and an opt-in Vitest mode with isolate: false became the largest single performance gain. The slowest shard fell from roughly 300-379 seconds to about 195 seconds, while total API-shard runner time dropped from about 32.8 to 22 minutes per run. That’s the real lesson here: CI doesn’t get faster from one clever trick. It gets faster when a team keeps removing friction until the whole system can breathe again.