Linear rebuilt its CI pipeline after AI agents made code validation the bottleneck

Agents ship faster than CI can validate

According to an engineering post from Linear that reached the front page of Hacker News, AI coding agents have accelerated how quickly code gets shipped, but validation has not kept pace. Every pull request still has to clear CI, so as development sped up, CI turned into the constraint — pushing infrastructure costs up and leaving both developers and agents idle waiting for feedback.

The post opens with Linear's CTO, Tuomas, assigning an issue titled "CI costs are high" and asking for faster CI as well. The team measured success on two axes: how long a PR waits on CI, and how much runner time it consumes. Despite the company's test suites almost quadrupling since the start of the year, PR wait time fell from more than six minutes to just over five, while runner time per test dropped by roughly half.

The rework fell into four areas: upgraded infrastructure and tooling, optimized gating jobs, reduced repeated setup, and more efficient test execution. Linear's codebase is mostly TypeScript, but the team notes many of the changes apply to other languages and toolchains.

Faster hardware and a native compiler

Some early gains required no changes to CI itself. Moving workloads off GitHub Actions onto third-party runners with faster CPUs, higher-performance storage, and better cache infrastructure made jobs 34% faster on average in a like-for-like comparison across the switch, with tsc workloads dropping 52%.

Modernizing the toolchain helped too. Switching to tsgo, the native TypeScript compiler, cut the weekly median of the tsc check by 73% — enough that typechecking stopped being the bottleneck.

Linting without the type checker

A handful of Linear's custom lint rules relied on TypeScript type information, which forced every lint run to build the full type graph and made linting one of the most memory-hungry CI jobs. The team rewrote those rules to use static analysis over the abstract syntax tree, recognizing function-like constructs and guard patterns without any type data.

That let ESLint drop TypeScript entirely: API lint time fell 68% and full-repository lint time 55%, with a substantial drop in memory use. Because syntax-only rules are easy to port, the change also smoothed a later migration to Oxlint, which further reduced runner-minutes spent on linting.

Shortening the jobs that gate everything

Viewing CI as a system drew attention to the small jobs that sit in front of all other work — deciding which paths a PR touched and whether identical tests already passed for the same inputs. None of the eight API test shards can start until those checks finish, so even tiny delays are disproportionately costly.

Capping the fetch depth took the slowest of these gates from 94 seconds to 20, while jobs that never needed a working tree dropped from 27 seconds to 7 after checkout was removed. For push and merge-queue events, a sparse, blobless checkout with limited history saved another 11 or so seconds. The change-detection job's median duration fell from 26 to 8 seconds, its p90 from 31 to 12, and its slowst run from 138 to 37.

The runner migration also introduced checkout hangs, which the provider traced to intermittent degradation on the direct IP link that third-party runners use to reach GitHub. Linear replaced actions/checkout with its own composite action that retries with backoff, uses Git's low-speed settings to abort a stalled connection after about 30 seconds, and keeps a persistent Git mirror on a sticky disk.

Finally, the team moved cache-marker writes out of the final pre-merge check, since PRs were lingering in the merge queue even after tests passed. That shaved 42 seconds from the merge path for every API pull request, and roughly a minute off the required check on cache misses.

Cutting repeated setup

Booting a runner, installing packages, and provisioning build dependencies meant jobs doing seconds of useful work could burn whole minutes of infrastructure time. Three changes cut per-shard setup by about 44%, from 110–140 seconds to 67–73 seconds.

The Postgres client, previously a 7–8 second apt install on every shard, was baked into a CI base image alongside Node. The pnpm install was restricted to the API package and its dependencies rather than the entire monorepo workspace, cutting it from 44–73 seconds to 16–18. And a node_modules cache was removed after testing showed it was slower than rebuilding: a cache hit restored in about 28 seconds versus roughly 7.5 seconds for a filtered install.

The post also flags setup that only needs replaying when its inputs change, such as API containers re-running the full database migration history on every run.

Why it matters

AI-generated code does not just change how software gets written; it changes the load profile of everything downstream. As agents produce more changes, validation capacity — not human typing speed — becomes the rate limiter, and CI bills scale with volume. Linear's response offers a template other teams can copy: run on faster hardware, strip expensive type-graph dependencies out of cheap checks, treat gating jobs as critical-path engineering, and audit whether caches and repeated setup actually pay for themselves. As agent-driven shipping becomes the norm, expect validation infrastructure, not code generation, to be the constraint more engineering organizations have to redesign around.