CI bottleneck from AI-generated pull requests: the September 2026 numbers for runners, tsgo, lint and Git
Tools in this post
Between January and September 2026, the tests a Linear pull request runs grew 3.7x, and its CI wait still fell 12%, "from more than 6 minutes to just over 5", according to Linear's write-up of 21 September. Each layer got its own fix: third-party runners cut job time by 34%, the native TypeScript compiler cut the typecheck by 73%, syntax-only lint rules cut API lint by 68%, and the slowest Git gate went from 94 to 20 seconds. Without that work, Linear says, the suite would take about 11 minutes. The month's other first-party figure is larger: Anthropic reported 25x more CI jobs over six months on 14 September.
Why did CI become the bottleneck once agents started opening the PRs?
CI became the bottleneck because coding agents raised the number of pull requests and tests faster than any other part of the pipeline grew. Every pull request still pays the fixed costs of a run: a runner start, a checkout, a dependency install, a typecheck and the gate jobs that block the tests.
Linear's own explanation: "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." It adds about 2,000 tests a week, and agents now write the majority of its tests.
Before the rework, each of Linear's API test shards spent 110 to 140 seconds on setup, so eight shards would have spent 15 to 19 minutes of runner time "on setup alone, more than the tests themselves". GitHub Actions rounds every job up to a whole minute, which makes short gate jobs expensive, and caps concurrent jobs on standard runners at 20 on Free, 40 on Pro, 60 on Team and 500 on Enterprise, so a burst of agent pull requests waits in a queue.
Linear's savings, layer by layer
Linear's CI rework, written by Mufeez Amjad and published on 21 September 2026, is the only September post I found with a measured saving for each layer of one pipeline. The table uses the numbers in Linear's text. Its summary chart differs in places: runners -33% against 34%, per-shard setup -55% against "roughly 44%", and the checkout-free test gate -69% against 27 s to 7 s.
| Layer | What Linear changed | Saving |
|---|---|---|
| Runner hardware | GitHub-hosted runners to unnamed third-party runners | Jobs 34% faster, tsc 52% |
| Compiler | tsc to tsgo |
Weekly median of the tsc check -73% |
| Lint | Type-aware custom rules rewritten to use syntax only | API lint -68%, full-repo lint -55% |
| Git gates | Capped fetch depth, no checkout where no working tree is needed | Slowest gate 94 s to 20 s, those jobs 27 s to 7 s |
| Critical path | Cache write moved off the required check | 42 s per API pull request |
| Setup | Base image, filtered pnpm install, no node_modules cache, then a schema snapshot |
Per-shard setup 110-140 s to 67-73 s, then database setup 12 s to 1-2 s |
| Runner starts | Seven checks batched into two jobs | About 87,000 runner-minutes a month, 11.8% of CI |
| Tests | Vitest isolate: false for opted-in tests |
About 17% of monthly cost, slowest shard 300-379 s to about 195 s |
The largest single saving, isolate: false, is the one Linear calls "the optimization with the highest correctness risk".
Faster runners took a third off Linear's jobs, not the 3x a microbenchmark showed
Third-party GitHub Actions runners cut Linear's average job time by 34%, roughly 1.5x, comparing the two days either side of the switch. A ten-trial benchmark on dev.to put Blacksmith 3.17x to 3.77x ahead of GitHub-hosted runners, on a Node script that ran for under half a second, "not a real build" in his own words. The other measurements I found land between about 1.4x and 2x.
| Source | Workload | Speedup over GitHub-hosted | Who ran it |
|---|---|---|---|
| Linear, 21 September 2026 | Its whole pipeline, unnamed vendor | 34% less time | Customer |
| Alex Georgiev, 20 September 2026 | Two Node scripts, 10 runs each, Blacksmith 4 vCPU against ubuntu-latest |
3.17x and 3.77x | Independent, says he has no affiliation |
| RunsOn benchmark, live page | PassMark CPU, Blacksmith 4 vCPU | 1.46x single-thread, 1.97x all cores | RunsOn, which sells runners |
After GitHub cut hosted-runner prices by up to 39% on 1 January 2026, a Linux 2-core runner costs $0.006 a minute and a 4-core one $0.012. Blacksmith lists $0.004 and $0.008, a third less. At Linear's 34% speedup, a job would cost about 44% of the GitHub price. Two risks come with it. Linear's checkouts hung because the new runners "sit outside GitHub's network", which it worked around with retries, a stall timeout of about 30 seconds and a cached git mirror. And third-party runners register as self-hosted, so they would pay the $0.002-a-minute self-hosted charge GitHub has postponed with no new date.
The native TypeScript compiler cut Linear's typecheck by 73%, below Microsoft's 8x to 12x
Linear moved its CI typecheck from tsc to tsgo, the native compiler that shipped as TypeScript 7.0 on 8 July 2026. That cut the weekly median of the tsc job by 73%, about 3.7x, "large enough to move the bottleneck off of typechecking entirely". Microsoft's announcement reports 8x to 12x on full builds, and a CI job also spends time on setup the compiler does not touch.
Microsoft itself advises that on "machines with fewer CPU cores and less memory (e.g. CI runners)", lower the --checkers count from its default of 4. The customer figures it quotes sit closer to Linear's: Slack cut type-checking in CI from about 7.5 minutes to 1.25, which is 6x, and removed 40% of its merge queue time.
Type-aware lint rules make every lint run pay for a full typecheck
A lint rule that reads TypeScript type information makes ESLint build the type graph of the whole program before it checks a single file. That is why typescript-eslint's performance guide says that with typed linting, "your lint times should be roughly the same as your build times". Linear rewrote its handful of type-aware custom rules to work on the syntax tree alone, which cut API lint by 68% and full-repository lint by 55%.
So when an agent opens ten pull requests an hour, the cost that matters is the type graph any type-aware rule forces: each of the ten lint runs costs about as much as a build, and the guide warns that "a project's first type-aware lint rule will almost always seem the slowest". Removing one typed rule out of five saves little; removing all of them saves the build, which is what Linear did. Among typed rules, the Oxc team published a timing sample from Oxlint's own engine in which unbound-method took 46.5% of rule time and no-floating-promises 28.1%, on a codebase it does not name. I found no measurement for no-misused-promises or the no-unsafe-* rules.
The native compiler does not help typed lint yet. As of 16 October 2026, typescript-eslint 8.71.2 requires TypeScript below 6.1, so typed ESLint rules still run on the old JavaScript type checker even after tsc moves to tsgo. There are two ways out:
- Oxlint: its type-aware mode went stable on 22 July. It covers 59 of typescript-eslint's 61 type-aware rules and ran 12x to 18x faster than ESLint on four large codebases on an Apple M4 Pro, measured by the Oxlint team.
- Biome: its
noFloatingPromisesrule is still in the nursery group, and Biome's only coverage figure, from June 2025, is a preliminary 75% of the cases typescript-eslint catches.
Reftable is not new in Git 2.55, and fetch depth moved Linear's gates more
The reftable backend a dev.to post measured on Git 2.55 shipped in Git 2.45 in April 2024. It stays opt-in until Git 3.0 makes it the default, and neither the 2.55 release notes nor GitHub's 2.55 highlights mention it. The 650 ms to 40 ms for 10,000 ref writes in the post's headline is one author's test in Docker on one machine.
In that test, also by Georgiev, 10,000 refs took 436 to 650 ms with the files backend and 39 to 42 ms with reftable, over three runs per point. GitLab's own runs after Git 2.51 work out to about 3x faster for fetch and 4x for push with 10,000 refs. His most useful finding for agent workloads was a failure: with 100 to 150 writers creating refs at once, between 30% and 63% of the writes failed with "cannot lock references" under reftable's default lock timeout of 100 ms. With the timeout raised to 5 seconds, all 150 succeeded in about 1.1 seconds.
Reftable helps repositories that live a long time and collect thousands of agent branches: the Git server, self-hosted runners with persistent workspaces, and git mirrors. It does little for a fresh CI checkout. actions/checkout fetches one commit by default, while fetch-depth: 0 fetches every branch and tag, so every agent branch lands on the runner on every run. Linear capped the fetch depth on its gate jobs and dropped checkout from jobs that never needed a working tree. Moving a long-lived repository over to reftable looks like this:
git refs migrate --ref-format=reftable --dry-run # writes the migrated refs to a separate directory
git refs migrate --ref-format=reftable # refuses repositories that have worktrees
git config reftable.lockTimeout 5000 # retry for 5 s instead of 100 msHow Linear's numbers compare with larger sources
Linear's growth is mild next to Anthropic's 25x in six months and steep next to the industry's. CircleCI's 2026 report, built on 28.7 million workflows in September 2025, found average daily workflow runs up 59% in a year and main-branch success at 70.8%, the lowest in over five years.
| Source | Measure | Growth | Window |
|---|---|---|---|
| Anthropic | CI jobs | 25x | A six-month period, reported 14 September 2026 |
| Linear | Tests in the suites a pull request runs | 3.7x | January to September 2026 |
| CircleCI (sells CI) | Average daily workflow runs | +59% | Year to September 2025 |
| GitHub Octoverse | Pull requests created per month | +20.4% | Year to August 2025 |
The same Octoverse counted over a million pull requests opened by Copilot's coding agent between May and September 2025. In May 2026 GitHub wrote: "More than one in five code reviews on GitHub now involve an agent." I found no 2026 GitHub figure for the share of pull requests that agents open.
On Stackness, as of 16 October 2026, 12 real members list a coding agent and 5 of them list GitHub Actions. My own account is one of the 5. One lists GitLab, and none lists a third-party runner. The numbers are small; the data sources page explains how bots are removed, and the full set is on the page for the DevOps and infrastructure tools developers list.
Method: who measured what, and what the numbers do not show
Every Linear figure is self-reported from Linear's own CI. The post gives no trial counts, runner sizes or dollar amounts. The dev.to runner and reftable benchmarks are each one person's runs. RunsOn, Blacksmith and CircleCI sell what they measure.
- What Linear leaves out: the runner vendor, the fetch depth it chose, the names of the rewritten lint rules and the saving from its later move to Oxlint.
- Whether faster checks catch the same bugs: nothing measures it. In the Hacker News thread, one commenter objected: "They don't even report pass/fail agreement between the old and the new CI." Others asked whether four times the tests meant four times the value.
- Review comes next: faster CI moves the queue to review, the subject of the verification layers for agent-written pull requests.
- The benchmark author: Georgiev posts an AI-assisted release benchmark about once a day and wrote both of the dev.to posts cited here.
Key numbers
- 3.7x the tests per Linear pull request with 12% less CI wait, January to September, published 21 September 2026 (Linear).
- 73%: cut in the weekly median of Linear's
tsccheck after the move totsgo, 21 September 2026 (Linear). - 34% less job time on third-party runners at Linear, against 3.17x to 3.77x on a Node microbenchmark, 20 September 2026 (Georgiev).
- $0.008 against $0.012: per-minute price of a 4 vCPU Linux runner, Blacksmith against GitHub, checked 16 October 2026 (Blacksmith, GitHub).
- 25x more CI jobs at Anthropic over six months, 14 September 2026 (Anthropic).
- 94 s to 20 s: Linear's slowest change-detection gate after it capped the fetch depth, 21 September 2026 (Linear).
New posts by email
About one email a week with what we published. No account needed.
One email to confirm first. Every email has a one-click unsubscribe.
Which of these do you use?
Nobody on Stackness runs Vitest yet. Tick what you use and be the first.
