Linear CI Optimization: Solving the AI-Driven Development Bottleneck

AI-driven coding agents have exponentially increased the speed of shipping code, but validation pipelines have not kept pace. At Linear, this discrepancy turned Continuous Integration (CI) into a primary bottleneck, increasing infrastructure costs and delaying feedback for both developers and agents. By implementing a multi-layered optimization strategy, Linear reduced pull request wait times from over 6 minutes to just over 5 minutes, even as their test suites nearly quadrupled in size since the start of the year.

Infrastructure and Tooling Upgrades

Upgrading the underlying hardware and compiler toolchain provides immediate performance gains without requiring changes to the CI pipeline logic.

• Third-Party Runners: Moving workloads from GitHub Actions to third-party runners with faster CPUs, higher-performance storage, and superior cache infrastructure resulted in an average 34% speed increase across jobs, with some workloads like tsc (TypeScript compiler) improving by 52%.
• Native Compilation: Switching to tsgo, a native TypeScript compiler, reduced the weekly median of tsc checks by 73%, effectively removing type-checking as a bottleneck.
• AST-Based Linting: Linear rewrote custom lint rules to use static analysis over the Abstract Syntax Tree (AST) instead of relying on TypeScript type information. This allowed ESLint to operate without the full type graph, reducing API lint time by 68% and full-repository lint time by 55%.
• Oxlint Integration: Moving to Oxlint further reduced the total runner-minutes spent on linting due to its higher efficiency in processing syntax-based rules.

Optimizing Gating Jobs

Jobs that sit on the critical path—those that must complete before any other work can begin—have a disproportionate impact on total CI duration.

Efficient Change Detection

Linear optimized the initial jobs that determine which tests to run based on the PR diff:

• Capped Fetch Depth: By capping the fetch depth for change-detection jobs, the slowest gates dropped from 94 seconds to 20 seconds.
• Removal of Working Trees: Jobs that did not require a full working tree had checkout removed entirely, reducing execution time from 27 seconds to 7 seconds.
• Sparse Checkouts: For commit push and merge-queue events, using sparse, blobless checkouts with limited history saved an additional 11 seconds.

These changes reduced the median duration of change-detection jobs from 26 seconds to 8 seconds.

Resilience and Path Minimization

To combat network instability between third-party runners and GitHub, Linear replaced actions/checkout with a custom composite action that implements retries with backoff and sets GIT_HTTP_LOW_SPEED_LIMIT and GIT_HTTP_LOW_SPEED_TIME to prevent hangs. Additionally, they moved non-essential tasks, such as writing cache markers, out of the critical merge path, shaving 42 seconds from every API pull request.

Reducing Repeated Setup Overhead

Setup costs—booting runners, installing packages, and provisioning dependencies—often consume more time than the actual tests in short-lived jobs.

• Custom CI Images: Linear moved shared dependencies (e.g., the Postgres client) into a base CI image. This eliminated the 7-8 second apt install time per shard and prevented occasional hangs during native build header downloads.
• Filtered Dependency Installation: In their pnpm monorepo, the API test workflow was changed to install only the API package and its dependencies rather than the entire workspace. This reduced pnpm install time from 44-73 seconds down to 16-18 seconds.
• Rebuilds vs. Caching: Testing revealed that rebuilding node_modules via filtered install (7.5 seconds) was faster than restoring them from a cache (28 seconds), leading Linear to abandon node_modules caching.
• Schema Snapshots: Instead of replaying full database migration history on every run, API containers now load generated schema snapshots and bootstrap files, reducing database setup from 12 seconds to 1-2 seconds.
• Job Batching: Seven independent short checks were consolidated into two jobs that run tasks concurrently. This reduced the frequency of setup overhead and saved approximately 87,000 runner-minutes per month (11.8% of total CI usage).

Improving Test Execution Efficiency

Once setup costs were minimized, Linear aggressively parallelized the API suite, which is the largest and most frequent part of the workflow.

Balancing Workloads

Because Vitest distributes work by file rather than by test duration, a few large files can bottleneck a shard. Linear split these large files into smaller, focused files and increased the shard count from four to eight. This reduced the slowest shard's duration from 5.25 minutes to 4.33 minutes.

Module State Caching

By introducing an opt-in Vitest project with isolate: false, Linear allowed safe test files to share a module registry within each worker. This prevented the redundant rebuilding of the entity, GraphQL, and decorator graphs for every file. This was the largest single improvement, reducing the slowest shard from ~300-379 seconds to 195 seconds and cutting total API-shard runner time from 32.8 to 22 minutes per run.

Community Perspectives and Counterpoints

While Linear's technical approach focused on infrastructure and pipeline efficiency, community discussion highlighted broader systemic challenges:

• The Value of AI Tests: Some contributors questioned whether the quadrupling of the test suite reflects a proportional increase in value, suggesting that LLMs may generate a high volume of boilerplate or trivial tests.
• Shift-Left Validation: Suggestions were made to move linting and unit tests into the agent's local loop (via hooks or skills) so that CI only handles resource-intensive tasks and receives pre-validated candidates.
• Alternative Tooling: Several developers advocated for build systems like Bazel or Grog, which use aggressive caching and dependency graphs to achieve build times in the range of 10 seconds for massive projects.
• The Moving Bottleneck: A common sentiment among engineers is that speeding up CI simply shifts the bottleneck further down the line to human code review, deployment, and rollback processes.

"Speeding up CI just moves the bottleneck to review and deploy. Agents made the queue louder — they didn't invent it."