AI coding has made CI a bottleneck — how Linear reworked its pipeline

Linear has published an account of how it reworked its continuous integration (CI) pipeline after AI coding agents made shipping code so fast that validating changes became the slowest part of the process. The post, on the company's Now blog of September 21, is signed by Mufeez Amjad and began with an issue his CTO, Tuomas, assigned him: "CI costs are high".

Why CI became the bottleneck

Agents ship code far faster than before, but validation has not kept pace: every pull request still passes through CI, so infrastructure costs rise and feedback is delayed. Linear optimized two numbers — pull request wait time on CI and runner time per test. Despite test suites nearly quadrupling since January, wait time fell from over six minutes to just above five, and runner time per test roughly halved.

Faster infrastructure and lint

Moving workloads off GitHub Actions to third-party runners made jobs 34% faster, with the tsc typecheck dropping 52%. Switching to tsgo, the native TypeScript compiler, cut weekly-median typechecking by 73%. Type-dependent lint rules were rewritten as static analysis over the syntax tree, letting ESLint drop TypeScript: API lint time fell 68% and repository-wide lint 55%.

Trimming the critical path and repeated setup

Capping fetch depth took the slowest gating job from 94 to 20 seconds, and jobs that never needed a working tree skipped checkout entirely (27 to 7 seconds); the change-detection job's median fell from 26 to 8 seconds. Moving one cache-marker write off the merge path saved 42 seconds for every API pull request and merge-queue entry.

Repeated setup was cut next: pnpm install was restricted to the API package (44-73 seconds down to 16-18) and per-shard setup fell from 110-140 seconds to 67-73. Batching seven short checks into two jobs saved roughly 87,000 runner-minutes a month — 11.8% of CI usage — and eight test shards instead of four made the critical job 19% faster and cheaper.

Test execution and the bottom line

The biggest single gain came from an opt-in Vitest project with isolation disabled: about 17% in monthly savings, the slowest shard down from 300-379 seconds to roughly 195, and API-shard runner time from about 32.8 to 22 minutes per run. It also carried the highest correctness risk. Without the work, today's suite would take about 11 minutes, close to double what developers wait now, and with 2,000 tests added weekly the effort continues.