Linear Rebuilt Its Testing Pipeline After AI Agents Sped Up Coding

Linear has reworked its continuous integration pipeline, the automated system that checks each code change, after AI coding agents began producing code far faster than validation could handle.

The company describes CI as the bottleneck as development speeds up. When generation runs ahead of checking, feedback gets slower and infrastructure costs rise. It set two narrow targets: how long a pull request, a proposed code change, waits on CI, and how much runner time, or compute time, it consumes Linear.

Those two measures pull in different directions. Wait time shapes developer flow, while runner time shapes spend and capacity. Linear reports it kept wait time roughly flat while cutting compute use, even as its test suites almost quadrupled since the start of the year. Pull request wait fell from more than 6 minutes to just over 5 minutes. Runner time per test was cut roughly in half.

The work followed four tracks: upgraded infrastructure and tooling, optimized jobs that block other work, reduced repeated setup steps, and made test execution more efficient.

Infrastructure provided much of the gain. Moving workloads off GitHub Actions to third-party runners made jobs run 34% faster on average in direct comparison. The tsc workload, the TypeScript compiler check, improved more, dropping 52% on the new runners.

Tooling added to that gain. Linear's codebase is primarily TypeScript, so typechecking acts as a gate on nearly every change. Switching to tsgo, the native TypeScript compiler, cut the weekly median of the tsc check by 73%.

Lint checks received similar treatment. Rewriting lint rules to use static analysis over the abstract syntax tree, the structured form of the code, reduced API lint time by 68% and full-repository lint time by 55%. Lint often runs as a gate, so shorter lint times leave more capacity for tests that need full execution environments.

The broader context here is a shift in where engineering time goes. When code production was manual, CI tuning was useful but limited by human output, since one engineer could only create so many changes per day. Parallel agents break that limit. They can open many more pull requests than a human team would, and each one still needs typechecks, lint, and tests. Cost then scales with volume, and wait time becomes a queueing problem.

In my view, Linear picked the right two numbers to watch. Teams often report CI duration as a single wall-clock number, which hides the trade between faster machines and smarter scheduling. Separating wait time from runner time makes the economics clear. Faster runners can cost more per minute but less per result if utilization improves. Work that blocks merge or blocks other jobs sits on the critical path, so minutes saved there are felt by every developer, while minutes saved elsewhere mainly lower the bill.

Looking at what this means for other organizations, the exact percentages will not carry over. Codebase shape, test parallelism, cache hit rates, and runner sizing all differ. The order of work likely does carry over. Move long blocking checks off shared and variable hardware first, then replace slower or older checks with native tooling, then shift lint and other analyzable work into fast structural passes rather than full builds. Reduce repeated setup continuously, since setup costs tend to return as dependencies change.

The wider lesson here concerns test growth. A suite that nearly quadruples in less than nine months would normally mean much slower merges or much higher spend. Linear reports neither outcome. That points to test execution efficiency, sharding, selection, and caching doing as much work as raw compute. For technical teams, the point is not that agents require four times the CI budget. Careful pipeline work can absorb much of the volume.

Worth flagging alongside that optimism, faster validation invites more generation. If merges get cheaper and quicker, agents will submit more. The next limit may be review quality, flaky test triage, or main-branch stability rather than pipeline minutes. Fixing CI does not by itself fix confidence. It restores conditions where confidence can be built quickly.

Over the long arc, cheaper and faster checks make a tight loop between humans and agents practical, with errors caught while context is fresh. That loop is what can turn higher code volume into better software, not only more software.