Linear engineer Mufeez Amjad has published a detailed account of how the company reworked its continuous integration pipeline after AI coding agents turned CI into its worst bottleneck — cutting pull request wait time from more than six minutes to just over five while its test suites nearly quadrupled since the start of the year.

The post, published on Linear's engineering blog on September 21, began, as these things often do, with a terse ticket from above. Earlier this year, Amjad opened Linear to find that Tuomas, the company's CTO, had assigned him an issue titled "CI costs are high" — and asked him to make CI faster while he was at it. For more context on this story, see our ongoing AI industry coverage.

When Agents Outpace Validation

The problem is structural, not incidental. "Agents have made it exponentially faster to ship code," Amjad wrote, "but validating those changes hasn't quite kept up at the same rate." Every pull request still has to pass through CI, so as development accelerates, CI becomes the choke point — driving up infrastructure costs and leaving developers and their agents waiting longer for feedback.

Linear optimized for two metrics: how long a PR waits on CI, and how much runner time it consumes. The results after months of work: despite test suites almost quadrupling since January, pull request wait time fell from more than six minutes to just over five, and runner time per test was cut roughly in half.

The work broadly fell into four categories: upgraded infrastructure and tooling, optimized the jobs that gate other work, reduced repeated setup, and made test execution more efficient. Linear's codebase is primarily TypeScript, but many of the optimizations apply across languages and toolchains.

Faster Machines and a Native Compiler

Some of the earliest gains required almost no optimization of CI itself. Moving workloads off GitHub Actions to third-party runners with faster CPUs, higher-performance storage, and better cache infrastructure paid off immediately: in a like-for-like comparison of the two days either side of the switch, jobs ran 34% faster on average, with some workloads like `tsc` dropping 52%.

Modernizing the toolchain compounded the win. Switching to `tsgo`, the native TypeScript compiler, cut the weekly median of the typecheck by 73% — large enough to move the bottleneck off typechecking entirely.

Linting Without the Type Graph

Linting was another early target. A handful of Linear's custom ESLint rules depended on TypeScript type information, which forced every lint run to build the full type graph before evaluating them — making linting one of the most memory-intensive CI jobs.

The team rewrote the rules to use static analysis over the abstract syntax tree, identifying function-like constructs and guard patterns without any type information. That let ESLint drop TypeScript entirely, reducing API lint time by 68% and full-repository lint time by 55%, with memory usage dropping substantially. It also eased the later migration to Oxlint, which further reduced CI runner-minutes spent on linting.

Shrinking the Critical Path

With individual checks faster, Linear zoomed out and treated CI as a system. That drew attention to the small jobs sitting in front of everything else — path-change detection and test-result cache checks that gate at the job level, meaning none of the eight API test shards can start until they finish.

The fixes were granular but additive. Capping fetch depth took the slowest gate from 94 seconds to 20. Removing checkout entirely from jobs that never needed a working tree cut those from 27 seconds to 7. A sparse, blobless checkout with limited history saved another 11-odd seconds for push and merge-queue events. In aggregate, the change-detection job's median duration fell from 26 seconds to 8, its p90 from 31 to 12, and its slowest run from 138 seconds to 37.

Checkout reliability needed work too: because the third-party runners sit outside GitHub's network and rely on a direct IP link, intermittent link degradation occasionally stalled fetches. Linear replaced `actions/checkout` with its own composite action that retries with backoff, sets `GIT_HTTP_LOW_SPEED_LIMIT` and `GIT_HTTP_LOW_SPEED_TIME` so a stalled connection aborts after about 30 seconds instead of hanging, and uses a checkout cache that keeps a persistent git mirror on a sticky disk.

One subtle fix removed wasted merge-queue time: cache markers were being written as part of the final check before merging, so a PR could sit in the queue even after its tests passed. Moving that write into a non-gating job shaved 42 seconds from the merge path for every API pull request and merge-queue entry. Together, these changes took roughly a minute off the required checks for API PRs on cache misses while reducing runner starts.

Fewer Wasted Seconds per Job

The last category attacked setup cost repeated across every job. Each API test shard spent 7 to 8 seconds installing the same Postgres client with apt on every run; moving it into a small CI base image alongside Node meant shards could start ready to run. The team later added native build headers to the image after discovering that downloading them during setup could occasionally hang.

Why It Resonated

The post struck a nerve with developers: it reached the front page of Hacker News, drawing roughly 250 points and around 280 comments within a day. The reaction is easy to explain — Linear's experience names a cost of AI-assisted development that most engineering organizations are only now confronting. Agents that generate pull requests in minutes still wait on validation pipelines designed for human cadence, and every minute of that wait is multiplied across every agent working in parallel.

The lesson from Linear's rework is that the bottleneck is movable, but only through the unglamorous accumulation of many small fixes — faster runners, cheaper typechecks, syntax-level lint rules, capped fetches, resilient checkouts, prebuilt images — rather than any single silver bullet.

---

Stay Ahead of AI

Get the latest AI news, analysis, and breakthroughs — all in one place.

Read more AI news →