Linear rebuilt its CI after agents outran it

Linear's CTO assigned Amjad an issue titled "CI costs are high" earlier this year, and wanted CI faster while he was at it. The post reports the outcome in first-party numbers: test suites have almost quadrupled since the start of January, and over the same period pull request wait time fell from more than six minutes to just over five, with runner time per test roughly halved. The individual wins are itemized. Moving off GitHub Actions to third-party runners made jobs 34% faster on average in a like-for-like comparison of the two days either side of the switch, with tsc down 52%. Switching to the native TypeScript compiler cut the weekly median tsc check by 73%. Rewriting custom lint rules to work on the syntax tree instead of type information let ESLint drop TypeScript entirely, cutting API lint time 68% and full-repository lint 55%. Capping fetch depth on change-detection jobs took the slowest of those gates from 94 seconds to 20. Consolidating seven small checks into two jobs saved roughly 87,000 runner-minutes a month on June usage, 11.8% of total CI spend. The single largest saving, about 17% of monthly cost, came from an opt-in Vitest project running with isolate: false, which dropped the slowest shard from between 300 and 379 seconds down to about 195. The Hacker News thread on the post stood at 49 points against 27 comments at 16:57 EDT on September 21.

That last change is also the one Amjad flags as carrying the highest correctness risk, and the way Linear contained it is the part with the widest application: "because agents now write the majority of our tests, we updated our respective agent skills to account for this performance opt-in as well, so generated tests follow the same constraints by default." The repository is currently adding roughly 2,000 tests a week. Without this year's work, the post estimates, the suite would now take about 11 minutes rather than the five developers wait today.

Why it matters: Writing the code stopped being the slow step here, validating it became the slow step, and the fix was ordinary infrastructure work rather than anything agent-specific. The transferable part is the coupling at the end. A performance optimization with real correctness risk had to be written into the agent instruction surface, because the thing generating the tests is the thing that has to honor the constraint. If your test suite is growing at a rate set by agents, your CI budget and your agent instructions are now one system, and changing either alone will not hold.