Agents have made it exponentially faster to ship code, but validating those changes hasn’t quite kept up at the same rate.<\/p><\/blockquote>\n
That sentence describes a structural problem, not a tooling complaint. Every PR still passes through the same pipeline, so accelerating the upstream step just deepens the queue at the check. Costs climb and feedback slows at the same time, which is the signature of a CI bottleneck.<\/p>\n
Read it as a preview. Any process where AI raises output volume but the quality gate stays fixed produces the same result: a faster front end feeding a constrained verifier.<\/p>\n Runner time per test came down by roughly half. Wait time dropped from over six minutes to just over five. On their own, those two figures look modest. Set against the workload they were absorbing, they are the interesting part.<\/p>\n The test suites almost quadrupled over the same period. A pipeline handling four times the validation work while getting faster and cheaper per unit is not a minor tuning exercise. It is a capacity rebuild.<\/p>\n This is the metric operations leaders should be watching in their own AI programmes. Absolute cycle time tells you very little once volume is climbing. What matters is whether your verification step can absorb more work per hour without adding headcount, licences, or compute. Linear ran that experiment in public and the answer was yes, but only after deliberate re-engineering.<\/p>\n Linear’s own chart makes the tension visible. Machine time per test spiked when they added test shards, because splitting a suite across parallel runners shortens the wait and costs more machine time. Faster for the developer, more expensive on the invoice. The same spike appeared again during checkout stalling issues.<\/p>\n Most teams optimise one of these and quietly inflate the other. Cut wait time with parallelism and your compute bill climbs. Cut compute by consolidating jobs and your engineers and agents sit idle longer. Neither is a win if you only instrumented one side.<\/p>\n Track both before you change anything. Wait time is the cost paid by people and agents standing still. Runner time is the cash cost. Linear’s four-part rework, covering infrastructure, gating jobs, repeated setup, and execution efficiency, only registered as progress because they had both numbers indexed from the first week of January.<\/p>\n Any process where AI accelerates production and a check sits at the end deserves the same pair of meters: how long the queue is, and what the queue costs.<\/p>\n Linear grouped the rework into four categories: upgraded infrastructure and tooling, optimising the jobs that gate other work, reducing repeated setup, and making test execution more efficient. Listed that way it reads like a tidy engineering plan. The ordering matters more than the list, because the first category delivered the largest returns for the least design work.<\/p>\n Moving workloads off GitHub Actions onto third-party runners with faster CPUs, higher-performance storage and better cache infrastructure made jobs 34% faster on average. Comparing the two days either side of the switch, some workloads dropped 52%. The pipeline itself was untouched. Same jobs, same order, better machines.<\/p>\n Then the toolchain. Switching to The operations parallel is direct. Before you redesign a verification workflow, check whether the constraint is running on old equipment or outdated software. Buying capacity is faster than engineering it, and it tells you where the real constraint sits.<\/p>\n Linting was the harder problem. A handful of custom lint rules needed TypeScript type information, so every lint run had to build the full type graph before evaluating them. That made linting one of the most memory-intensive jobs in the pipeline, for the sake of a few rules.<\/p>\n The team rewrote those rules to use static analysis over the abstract syntax tree, identifying function-like constructs and guard patterns without type information. ESLint dropped TypeScript. API lint time fell 68%, full-repository lint time 55%, and memory usage dropped substantially.<\/p>\n The second payoff came later. Rules that operate purely on syntax port easily, so the subsequent move to Oxlint was straightforward and cut runner-minutes again. Removing a dependency did not just make one step faster. It made the next change cheap.<\/p>\n Swap “pull request” for “deviation report” and the story is identical. AI drafts the CAPA write-up, the supplier assessment, the inspection summary. A human still has to read it, question it, and sign it. The review queue becomes your pipeline, and it has the same failure mode: production speeds up, verification does not, and the backlog shows up as delayed batch release or an audit finding.<\/p>\n Before you add AI to a documentation-heavy process, find every point where its output enters an approval chain. Deviation closure, change control, supplier qualification, complaint handling. Each one has a named approver and a finite number of hours in their week.<\/p>\n Then measure two things separately, because they move in opposite directions. Queue wait time tells you how long an item sits before anyone touches it. Reviewer hours tell you how much actual human attention it consumes. Linear tracked exactly this split, optimising “how long a PR waits on CI and how much runner time it consumes.” Collapse the two into one average and you will fix the wrong thing.<\/p>\n Linear’s sharpest move was zooming out from individual checks to the small jobs sitting in front of everything else. Every run starts by checking which paths a PR touched and whether those tests already passed for the same inputs. Same-input work does not get re-run. That is deduplication, and quality functions almost never do it.<\/p>\n The operational version is risk-tiered routing. A low-risk deviation against a well-characterised process does not need the same depth of review as a first-time supplier nonconformance. Build the tier logic into the intake step, not the review step, and gate item by item rather than releasing work in weekly batches. Batch gating is what turns a five-minute review into a four-day wait, and no amount of extra reviewer headcount fixes it.<\/p>\n![\"Linear](\"https:\/\/falcoxai.com\/main\/wp-content\/uploads\/2026\/09\/ci-bottleneck-how-ai-coding-b-inline-1.jpg\")
<\/figure>\nThe Numbers Linear Put on the Board<\/h2>\n
Why throughput growth, not absolute speed, is the real result<\/h3>\n
The sharding trade-off: buying wait time with machine time<\/h3>\n
Four Levers Linear Pulled, Ranked by Effort Versus Payoff<\/h2>\n
Buy speed first: hardware and toolchain swaps that need no redesign<\/h3>\n
tsgo<\/code>, the native TypeScript compiler, cut the weekly median of the tsc<\/code> check by 73%. That single swap was big enough to move the bottleneck off typechecking entirely. Two decisions, both essentially procurement, both bigger than most clever optimisations would have been.<\/p>\nThen remove dependencies: how dropping type information unlocked the next two wins<\/h3>\n
![\"Four-quadrant](\"https:\/\/falcoxai.com\/main\/wp-content\/uploads\/2026\/09\/ci-bottleneck-how-ai-coding-b-inline-2.jpg\")
<\/figure>\nThe Same Bottleneck Is Forming in Quality and Operations Functions<\/h2>\n
Mapping your validation queue before you scale AI output<\/h3>\n
Risk-tiered review as the operational version of path-based gating<\/h3>\n