News · 2026-09-22
Linear rebuilt its CI after agent-assisted coding made validation the bottleneck
Linear says agent-assisted development pushed its validation system into the critical path, and its response cut waste around tests rather than pretending more parallel workers alone would solve the problem. The post is valuable because it identifies the mundane setup, checkout, cache, and scheduling costs that become visible when code arrives faster.
Key facts
- Linear's 21 September engineering post says its test suite grew to almost four times its January size.
- It reports adding roughly 2,000 tests each week and holding PR wait time to just over five minutes.
- Replacing
tscwithtsgocut the weekly median TypeScript check by 73%, according to Linear. - Per-shard setup dropped from 110–140 seconds to 67–73 seconds after several changes.
Linear begins with a blunt internal framing: “CI costs are high.” The company says agents made code ship more quickly while every change still needed checking. That produces two queues at once: people and agents wait longer for feedback, and the organization pays more runner time. Crucially, the post does not publish a time series of PR volume or the percentage generated by agents. The defensible claim is that rapid test growth and faster code production exposed a validation bottleneck, not that a known number of AI-authored pull requests caused it.
The diagnosis is a systems lesson. A CI run is not simply test duration. Linear had small change-detection and cache jobs that ran ahead of eight API-test shards, so every downstream job waited for a gate. It reduced the median change-detection job from 26 seconds to eight by fetching less Git history and avoiding checkouts that did not need a working tree. Like an airport security queue before multiple gates, a small delay at the entrance multiplied across every flight waiting behind it. Moving an unrelated cache-marker write off a required merge check removed about 42 seconds from a key merge path.
The post's anchor number is the 73% weekly-median TypeScript reduction after Linear changed from tsc to native tsgo. It also rewrote lint rules that had built the entire TypeScript type graph even when a syntax-only rule could decide the issue. Linear reports 68% faster API linting and 55% faster whole-repository linting. The point is not that type information is useless. It is that using semantic machinery for a syntactic rule is like starting a whole city map to check whether a street sign is misspelled.
Setup cost was the other enemy. Every test shard installed the same PostgreSQL client and other dependencies. Linear moved some pieces into a CI image, installed only the API package and its dependencies rather than the full workspace, and discovered that restoring node_modules was slower and more variable than a targeted fresh install. The combined work cut per-shard setup from 110–140 seconds to 67–73 seconds. That made eight-way sharding viable: before the setup changes, the extra shards would have spent 15–19 minutes cumulatively just preparing themselves.
Linear also split unusually large test files because Vitest shards by file rather than individual test duration. Its slowest shard fell from 5.25 minutes to 4.33 after the changes. An opt-in isolate: false project allowed carefully prepared test files to share a module registry, reducing repeated initialization. Linear reports about 17% monthly savings at its scale and says shared state requires explicit cleanup, an important safety rail. The company writes that agents now generate most tests and that its agent skills are being updated to choose the performance option by default.
The results are capacity gains rather than instant CI. Linear reports PR wait time going from more than six minutes to just over five while the test suite nearly quadrupled, and machine time per test roughly halved. Batching small checks saved 87,000 runner-minutes per month, or 11.8% of its stated total. Without the work, Linear estimates the current suite would take around 11 minutes. These are vendor-reported internal measurements, not an external benchmark.
The strongest counterargument concerns assurance. Dagger's Solomon Hykes agrees agent output is straining CI but argues infrastructure upgrades only postpone a scheduler and software-architecture problem. HN practitioners added that more generated tests are not automatically valuable, and Linear did not publish a diagnostic-equivalence study for tsc versus tsgo or type-aware versus syntax-only linting. Those are fair limits. The news is not “AI made CI broken everywhere”; it is that high-velocity coding makes the fixed tax around validation a first-class engineering problem, and one team has supplied a detailed, measurable playbook for attacking it.
Key questions
What did Linear change in its CI system?
How much did Linear's test suite grow?
Does Linear prove that AI-written code caused CI failures everywhere?
Cite this
APA
Ground Truth. (2026, September 22). Linear rebuilt its CI after agent-assisted coding made validation the bottleneck. Ground Truth. https://groundtruth.day/news/linear-ci-bottleneck-agent-coding.html
BibTeX
@misc{groundtruth:linear-ci-bottleneck-agent-coding,
title = {Linear rebuilt its CI after agent-assisted coding made validation the bottleneck},
author = {{Ground Truth}},
year = {2026},
month = {sep},
url = {https://groundtruth.day/news/linear-ci-bottleneck-agent-coding.html}
}
Comments are replies to this story on Bluesky — reply with any Bluesky account to join in.