AI coding has made CI a bottleneck, so we reworked ours to keep up
TL;DR
Linear's test suite nearly quadrupled since the start of the year, mostly from agent-written tests. Faster runners, leaner setup and smarter sharding still cut PR wait from over 6 minutes to just over 5. Runner time per test fell by half. Doing nothing would have meant about 11 minutes.
The article
- Moving from GitHub-hosted runners to third-party runners with faster CPUs and storage made jobs 34% faster on average. Switching to tsgo, the native TypeScript compiler, cut the median typecheck by 73%.
- Rewriting custom lint rules to work on the syntax tree alone let ESLint drop the type checker. That cut full-repo lint time by 55%. It also made a later port to Oxlint easy.
- Every test shard waits on small change-detection jobs. Those jobs got shallow or sparse checkouts, and a checkout action that retries instead of hanging. A cache write moved off the merge path. Together these took about a minute off the required check.
- Per-shard setup fell from 110-140 seconds to about 70. Linear baked the Postgres client into the CI image and installed only the API package's dependencies. It dropped a node_modules cache that took 28 s to restore, against 7.5 s for a fresh filtered install. Merging seven tiny jobs into two saved 11.8% of monthly CI minutes.
- Cheap setup made eight shards affordable. Splitting oversized test files fixed Vitest's per-file balancing. An opt-in `isolate: false` project that shares the module registry was the biggest single win, about 17% of monthly cost. It also carried the most correctness risk.
- Linear adds about 2,000 tests a week, mostly written by agents. So the team also updated its agent skills, and generated tests now follow the non-isolated test rules by default.
Why it matters
Anyone running a TypeScript monorepo on GitHub-hosted runners can lift these changes directly. The original has the before and after numbers for each one. It also explains when sharding stops paying for itself.
The discussion
Most of the 400 comments ignore the CI work and argue the headline instead. If agents make coding so much faster, why aren't products visibly better? That fight fills the giant first thread, and the rest stay on topic: bloated agent-written tests, self-hosted runners, and Bazel.
Where are the better products?
The top thread asks why faster coding hasn't produced better phones, operating systems or a faster Windows context menu. Defenders point to an 84% jump in iOS app submissions, emulator and decompilation projects, and internal wins like fewer outages that never reach a changelog. Skeptics answer that submissions aren't installs or revenue, and that product taste, sales and requirements were the bottleneck all along. Macro data settled nothing: one camp cited a St. Louis Fed estimate of up to 1.3% extra productivity, the other the Solow paradox.
Code is cheap and getting cheaper. Software remains hard and is getting harder.
These fixes mostly don't show up in our product change logs, and definitely don't fall into "new features". It would largely be invisible to the outside world, but our costs are going down
The quadrupled test suite
Many read "2,000 tests a week" as the actual cause of the CI load. Commenters describe agents testing string constants, external libraries and language features, and one notes the article never shows whether the bigger suite catches more bugs. A minority flips it around: with agents writing the code, the tests are the part worth reviewing. Passing end-to-end tests are what make large agent refactors safe.
Unless you prompt them otherwise, the models tend to write WAY too many useless tests and in the most inefficient ways imaginable.
Reviewing PRs is now about just reviewing the tests, as the code is very likely to be fine if tests are relevant and they're passing.
CI isn't the real bottleneck
Several people say their constraint is human testing, product judgment, or deploy and rollback, so a faster CI just moves the queue. Dagger's founder argues the reverse: QA itself will be automated and triggered from CI. An ex-QA engineer pushes back that QA exists to find the problems nobody thought to write a test for. The two end up agreeing that agents help with review but don't replace a human trying to break the product.
What you cannot automate are finding the "unknown unknowns". That is things you don't know to look for.
I started my career doing QA and 99% of what I was doing could be automated by an AI today.
Self-host the runners
Nobody was surprised that leaving GitHub-hosted runners gave the first big speedup. Commenters report CI under one or two minutes on their own machines: OVH boxes with warm LXD containers, a spare MacBook, one beefy server. Others recommend hosted alternatives like Blacksmith and RWX. The counterpoint is organizational: big companies have spent years moving off on-prem and away from the ops staff it needs.
You can buy a pretty beefy machine (TB of RAM, 256 cores, fast NVMe disk) and tests will run faster than on any hosted platform.
Because they're running away from on-premise and the associated Ops teams.
Is Bazel the answer?
A Bazel thread claims ~10-second warm builds and says agents have collapsed the migration cost from years to weeks. Others doubt the fit for JS/TS, where network and disk I/O dominate, and say warm-cache numbers hide real hit rates. One person's replay of a week of changes saved only 20%. Dagger's founder adds that Bazel builds well but is ordinary at tests, so it shouldn't own the whole CI stack.
The setup cost for bazel just went down by a lot, and I don't think the industry as a whole is aware of that yet.
I ran an experiment where I migrated a package to bazel then replayed a weeks worth of changes and it saved 20%.
Consensus
Leaving GitHub-hosted runners and cutting per-job setup are the obvious first wins. A test suite growing 4x in a year is a warning sign in its own right.
Dissent
A sizable group says agent-driven speed hasn't made software better for users, so making CI faster for it is optimizing the wrong thing. Others answer that the gains are real but land in internal quality and reliability, where nobody outside sees them.