An engineer asks an AI coding agent for a fix, gets a pull request back in two minutes, and then waits six minutes for CI to tell them if it actually works. The bottleneck didn’t disappear when coding got faster — it just moved.
What actually happened at linear
Linear’s engineering team published a detailed account of hitting exactly this problem: “Agents have made it exponentially faster to ship code, but validating those changes hasn’t quite kept up at the same rate… CI becomes a bottleneck, driving up infrastructure costs and leaving developers and agents waiting longer for feedback” (linear.app/now/ci-bottleneck-reworked). The numbers are specific and real, not vague: “Despite our test suites almost quadrupling since the start of the year, we brought pull request wait time down from more than 6 minutes to just over 5, while cutting runner time per test roughly in half.”
What actually fixed it, per their own breakdown: switching to a faster native TypeScript compiler cut one check by 73%, “large enough to move the bottleneck off of typechecking entirely.” Rewriting lint rules to skip full type-checking cut full-repository lint time by 55%. Capping how much of the repository each CI job actually checks out (instead of fetching everything every time) took their slowest gating job from 94 seconds to 20. None of these are AI-specific fixes — they’re ordinary CI engineering, just applied under new pressure.
The broader claim, and how much to trust it
Several outlets are reporting striking secondary statistics about this trend industry-wide: one piece cites “CircleCI’s 2026 State of DevOps report” claiming CI pipeline runs increased “340% within 6 months” at companies adopting AI coding tools; another cites a company running “660 builds per engineer per day.” These numbers were not independently verified for this piece, and several of the articles reporting them cite each other’s framing rather than a single traceable primary source — worth treating as directionally plausible (multiple unrelated sources describe the same underlying mechanism: agents iterate in tight write-build-test loops that humans don’t) rather than as precise, confirmed figures.
Why the mechanism makes sense even without the exact numbers
The structural argument holds regardless of which specific statistic is accurate: “A human engineer used to write a commit, wait for a build, look at the result, and move on to the next thing a few times a day… an agent writes, builds, reads the failure, and tries again, over and over, in a tight loop, sometimes dozens of times for a single task” (curata.com, a commentary piece, not a primary data source, but the mechanism described matches what Linear’s own post independently confirms happened to their test-suite volume). Multiply that loop across a fleet of agents running in parallel, and a CI system sized for human-paced commits gets hit with a fundamentally different traffic pattern — bursty, not steady.
Why this matters
This is a genuinely new kind of infrastructure problem, not a repeat of “tests are slow, add more servers”: agents create load in tight, repeated cycles that a system built around human patience never had to handle. Linear’s fix worked because they treated it as an ordinary, if urgent, performance-engineering problem — faster compilers, less redundant setup, smarter test sharding — rather than needing anything AI-specific. Whether every team’s bottleneck looks like Linear’s (TypeScript-heavy, CI-cost-driven) or something else entirely is an open question; the reported industry-wide statistics are worth watching, not yet worth citing as settled fact.