Linear Cuts CI Wait Time to 5 Minutes as Tests Quadruple

Linear says it cut the median wait for a pull request to clear continuous integration from more than 6 minutes to just over 5, even as its test suite nearly quadrupled since the start of the year, according to a Sept. 21 post by engineer Mufeez Amjad on the company's own blog. The claim is worth taking seriously because Linear is measuring the exact problem coding agents are supposed to be creating industry-wide: code arrives faster than anything downstream can check it.

Why an assigned issue became an engineering post

Amjad wrote that the project began when "Tuomas, our CTO, had assigned an issue to me, titled 'CI costs are high.'" The diagnosis that followed doubled as an explanation of why CI has become a talking point across the industry this cycle: "Agents have made it exponentially faster to ship code, but validating those changes hasn't quite kept up at the same rate. Every PR still has to pass through CI, so as development accelerates, CI becomes a bottleneck, driving up infrastructure costs and leaving developers and agents waiting longer for feedback." Linear's own suite grew by roughly 2,000 tests a week over the period, according to the post, which runs on Vitest as its test runner and pnpm for package management, both named without being replaced.

What actually moved the number

The post lists five separate changes rather than one fix. Linear moved off GitHub Actions to third-party runners with faster CPUs and storage, and replaced the standard actions/checkout step with a custom composite action that adds retry logic and connection timeout controls. It adopted tsgo, a native TypeScript compiler, cutting the weekly median of its tsc type check by 73%. It moved ESLint's rules to Oxlint and rewrote its own custom lint rules to use static analysis instead of full type information, cutting API lint time by 68% and full-repository lint time by 55%. It doubled test sharding from four shards to eight and added module state sharing under strict isolation rules, which brought the slowest shard down from roughly 300 to 379 seconds to about 195 seconds. Batching seven previously independent checks into two jobs saved about 87,000 runner-minutes a month, which Linear said equals 11.8% of its total CI usage.

Metric	Before	After
Median PR wait for CI	More than 6 minutes	Just over 5 minutes
Test shards	4	8
Slowest shard	300 to 379 seconds	About 195 seconds
Runner-minutes saved monthly	—	About 87,000 (11.8% of total usage)

The number the post does not include

Linear's post measures CI runtime, not how long a finished pull request waits for a human to look at it, and that second number is where LinearB's 2026 Software Engineering Benchmarks Report, built from 8.1 million pull requests across more than 4,800 organizations, points to a different bottleneck. LinearB found that AI-assisted pull requests wait 4.6 times longer before a reviewer picks them up than unassisted ones, even though they are then reviewed twice as fast once someone starts. At the 75th percentile, LinearB's own data puts agentic pull requests at 17.6 hours of pickup time against 3.4 hours for unassisted work, and it attributes the gap to three causes: agent-authored pull requests have less clear ownership, agentic flows get pointed at low-priority backlog items nobody is watching for, and reviewers hesitate longer on larger or more complex AI-written changes. Those changes are larger to begin with. At the same percentile, AI-assisted pull requests ran 408 lines against 157 for unassisted ones, a gap LinearB ties directly to the slower pickup. AI-generated pull requests were accepted within LinearB's measurement window 32.7% of the time, against 84.4% for unassisted work.

1. Agentic AI pull requests17.6 hours
2. Unassisted pull requests3.4 hours

Source: LinearB, 'AI in software development: what the 2026 data shows,' accessed 2026-09-22

A pull request that clears CI in 5 minutes can still sit unreviewed for the better part of a day if nobody owns it, which is the gap Linear's post does not claim to have closed. That gap matters more as agentic coding tools scale past individual teams. Coding-agent startups are now raising rounds that value them at $5 billion, and the volume of machine-written code entering review queues is a separate problem from how fast that code compiles or passes lint, a distinction visible even in how coding agents' own output gets open-sourced faster than anyone can audit it line by line.

Linear's fix would stop looking durable if its own median wait time climbs back up as the roughly 2,000 weekly tests keep compounding faster than its infrastructure investment, or if a future post from the company has to address pickup time rather than runtime. Amjad's post does not say what Linear's own PR pickup time looks like, only how fast a PR moves once CI starts, which leaves the metric LinearB's data flags as the wider industry's actual constraint unmeasured in Linear's own account of the fix.

Sources

1. CI bottleneck? We reworked our approach., Linear
2. 2026 Software Engineering Benchmarks Report, LinearB
3. AI in software development: what the 2026 data shows, LinearB