When agents speed up coding, CI does not get a memo. On September 21, 2026, Linear engineer Mufeez Amjad published AI coding has made CI a bottleneck, so we reworked ours to keep up — a rare post that names the constraint explainx.ai has been tracking all month: merge velocity outran validation infrastructure.
CTO Tuomas assigned the issue bluntly: CI costs are high — and make CI faster. Linear's answer is not "fewer tests." It is four layers of systems work on a TypeScript / pnpm monorepo, with numbers attached.
The same week, Hacker News sent the post to the front page (~239 points) with a familiar meta-question: if everyone is shipping faster, where are the better products? Linear's article does not answer that — it answers a narrower one that every team with coding agents will hit: how do you keep feedback loops shorter than your agents' output?
TL;DR — Linear's published results
| Metric | Before / trend | After (Sep 2026 indexing) |
|---|---|---|
| Test suite size | ~4× growth since Jan 2026 | Still growing (~2,000 tests/week, agents write most) |
| PR wait on CI | >6 min | ~5 min (would be ~11 min without changes, per Linear) |
| Runner time per test | Baseline Jan | ~50% lower (indexed) |
| tsc (weekly median) | tsc baseline | −73% after tsgo |
| API lint | Type-aware ESLint | −68% API lint, −55% full repo (AST-only rules + Oxlint) |
| Change-detection gate | 26s median (138s max) | 8s median (37s max) |
| pnpm install (API shard) | 44–73s full workspace | 16–18s filtered to API package |
| Per-shard setup | 110–140s | 67–73s (~44% down) |
| Vitest API shards | 4 → 8 | Slowest shard 5.25 → 4.33 min (first week) |
| Batched micro-checks | 7 jobs × full setup | 2 jobs, 7 tasks inside → ~87k runner-minutes/month saved (~11.8% of CI) |
Why CI became the bottleneck (and why Anthropic said the same thing)
Linear's framing matches Anthropic's September 14, 2026 CI post almost line-for-line:
- Agents increase PR throughput.
- Every PR still runs gates.
- Wait time + dollars scale with runner starts, checkout, install, and shard count.
Anthropic attacked the problem with test impact analysis (which tests must run for this diff?) after CI job volume grew 25× in six months. Linear attacked it with faster machines, cheaper gates, and smarter sharding on a suite that nearly quadrupled. If you run agents today, you likely need both philosophies: run fewer tests when safe, and make each test minute cheaper when you do run them.
Andrew Ng's Batch 371 letter is the cultural backdrop — fear hype vs. engineering work ahead. Linear's post is the engineering work.
1. Infrastructure and toolchain (free speed before cleverness)
Third-party runners: Linear moved off default GitHub Actions hosts to runners with faster CPUs, better storage, and cache infrastructure. Like-for-like around the switch: ~34% faster jobs on average, with tsc down ~52% on some workloads.
tsgo: Adopting the native TypeScript compiler (tsgo) cut the weekly median tsc check by 73% — enough that typechecking stopped being the bottleneck.
Lint without the type checker: Custom ESLint rules that needed TypeScript type information forced a full type graph before lint — memory-heavy and slow. Linear rewrote rules as AST-only static analysis, then moved toward Oxlint. Result: ~68% faster API lint, ~55% on full-repo lint, with lower memory.
explainx.ai read: This is the same macro story as Rust rewrites in hot paths — push work to faster native tooling, then re-balance the pipeline. If your agents generate TS faster than tsc + type-aware ESLint can digest, you are paying twice: tokens to write code, minutes to prove it compiles.
2. Critical-path jobs (seconds that block eight shards)
Linear runs eight API test shards, but none start until gate jobs finish. Small jobs — path detection, "have these inputs passed before?" — became disproportionately expensive.
Shallower git: Change-detection jobs checked out full trees when they only needed diffs. Capped fetch depth took the slowest gate from ~94s to ~20s; jobs that never needed a tree dropped from ~27s to ~7s. Sparse blobless checkout saved another ~11s on merge-queue events.
Checkout resilience: After moving runners outside GitHub's network, actions/checkout hung on intermittent peering issues — and because checkout is first, the whole run stalled. Linear replaced it with a composite action: retries, GIT_HTTP_LOW_SPEED_* aborts (~30s), and a persistent git mirror on sticky disk.
Merge-queue trim: Cache marker writes sat on the merge critical path even after tests passed. Moving that write to a non-gating job saved ~42s per API PR / merge-queue entry.
Median change-detection: 26s → 8s; p90 31s → 12s; worst case 138s → 37s.
3. Repeated setup (where "fast tests" still feel slow)
Agent-era CI pain is often not the test body — it is runner boot + install + apt + cache restore repeated per shard.
Linear's moves:
- CI base image with Postgres client and native headers (no 7–8s apt every shard).
- Filtered
pnpm install— API workflow only installs API + deps, not the whole monorepo (44–73s → 16–18s). - Dropped node_modules cache when restore (~28s) lost to ~7.5s filtered install.
- DB setup: schema snapshot + bootstrap instead of replaying full migration history when schema unchanged (~12s → 1–2s per container).
- Batch seven micro-checks into two jobs with concurrent tasks inside — ~87k runner-minutes/month saved.
Per-shard setup fell from 110–140s to 67–73s, which is what made eight shards affordable: at the old setup cost, eight shards would spend 15–19 minutes on setup alone.
4. Test execution — Vitest sharding and isolate: false
File-based sharding: Vitest balances by file, not by test duration, so a few huge files dominated shard runtime. Linear split large files, went 4 → 8 shards, and saw the critical job ~19% faster and ~19% cheaper in initial benchmarks; slowest shard 5.25 → 4.33 minutes after a week.
Shared module state (biggest win, biggest risk): Default Vitest isolates every file — for Linear that meant rebuilding entity / GraphQL / decorator graphs per file. An opt-in project with isolate: false let safe files share a module registry inside a worker.
Linear credits this with ~17% monthly savings at their volume; slowest shard ~300–379s → ~195s; total API shard time ~32.8 → ~22 minutes per run.
They also call it the highest correctness risk: per-file opt-in comments, explicit teardown, files that need fake timers stay isolated — and because agents write most tests now, they updated agent skills so generated tests follow the same opt-in rules.
HN skepticism applies here: several commenters asked whether 4× tests means 4× value, or mostly agent boilerplate. Linear does not publish defect detection rates — only time and coverage curves. Treat test count as a cost driver, not a quality metric, unless you pair it with test impact analysis or human behavior-driven specs.
The bottlenecks Linear did not fix (HN's fair points)
Linear optimized machine time. The front-page thread kept returning to human and product layers:
| Bottleneck | Why CI speed does not solve it |
|---|---|
| Product taste / UX | Agents compress implementation; what to build still human |
| Manual / exploratory QA | "Does it feel right to customers?" — not in Vitest |
| Amdahl's law | Faster CI shifts wait to review, deploy, rollback, or merge queue politics |
| Test meaning | More agent tests ≠ more caught regressions if tests mirror implementation slop |
That is not an argument against Linear's work. It is an argument for not stopping at Linear's work. Teams shipping with agents should assume the next constraint is review quality or staging verification, not another shard count — see Claude Tag as CI first responder for how one lab automates interpretation of failures, not just execution.
A steal list for your repo this week
- Profile gate jobs — median/p90 duration; anything on the critical path under 10s is worth a postmortem.
- Measure install, not just tests — filtered workspace installs beat giant caches when lockfiles churn weekly.
- Try tsgo / oxlint on TS monorepos — if typecheck and lint dominate, native tooling beats micro-optimizing YAML.
- Shard only after setup is cheap — Linear's eight-shard story fails if each shard pays two minutes of pnpm.
- If agents write tests, codify isolation rules in skills — same as security skills for agent harnesses.
- Read Anthropic + Linear together — selection vs. speed; you may need both products internally.
Related on explainx.ai
- Cloudflare Worker Previews: a production-like environment per git branch — the same-week environment-provisioning half of this story
- Agentic coding is straining CI: Anthropic test impact analysis — the which tests run story at 25× volume
- Andrew Ng: AI fear vs. engineering fixes (Batch 371) — same week's narrative context
- Claude Tag as CI/CD first responder — when CI fails faster, triage still matters
- What is an agent harness? — where to enforce checks before CI when possible
- GitHub Copilot runtime Rust migration — parallel "make the toolchain native" theme
Primary source: Linear — AI coding has made CI a bottleneck (Mufeez Amjad, September 21, 2026). Discussion: Hacker News thread on the same post (September 2026).
Metrics and percentages above are Linear's published figures unless labeled as explainx.ai interpretation. Linear's stack is TypeScript-centric; your language toolchain may differ. Follow @explainx_ai for updates.