Tuomas Artman's team cut runner time per test roughly in half while Linear's test suite nearly quadrupled in 2026, according to Linear.
By [RuntimeWire Staff](https://runtimewire.com/author/runtimewire-staff)
· Published
Primary source: [Linear](https://linear.app/now/ci-bottleneck-reworked)
Why it matters #
AI coding increases output before verification capacity catches up. Linear's overhaul shows CI architecture, runner economics and test isolation becoming core constraints for agent-heavy engineering teams.
Linear, the product-development software company, said on September 21st that a CI overhaul ordered by co-founder and CTO Tuomas Artman (@artman) cut runner time per test roughly in half even as its test suite nearly quadrupled during 2026. Pull request wait time fell from more than six minutes to just over five minutes.
Artman handed the work to Mufeez Amjad (@moofeez) with an issue carrying a blunt title: "CI costs are high." He wanted the pipeline faster, too. Amjad detailed the resulting changes in a Linear engineering post published September 21st.
The assignment fit Amjad's background. The New York-based infrastructure and backend engineer previously worked on Meta's Buck2 build system, Cockroach Labs' Pebble storage engine, and Splunk's release automation infrastructure. He studied software engineering at the University of Waterloo and has also been experimenting with LLM performance on software engineering tasks, according to his personal site.
Artman brought his own history with engineering scale to Linear. Before co-founding Linear with Karri Saarinen and Jori Lallo in 2019, he spent five years at Uber, where his team helped build RIBs, the architecture Uber developed for large mobile applications. Linear emerged partly from the founders' frustration with the tools and processes they encountered while building software at Uber, Coinbase, and Airbnb.
The CI project captures the next version of that frustration. Linear built its reputation by removing friction from product development. AI agents are now producing work quickly enough that the verification machinery behind the product has become a constraint of its own.
The bottleneck moved downstream
Linear's TypeScript codebase still has to validate every pull request, regardless of whether a person or an agent produced the changes. Higher coding output therefore increases the number of tests, runner starts, dependency installations, checkouts, and other tasks competing for infrastructure.
Linear says agents now write most of its tests. The repository is adding roughly 2,000 tests each week, and the test suite has grown to nearly four times its size at the beginning of January.
Linear's indexed chart tracks test-suite growth against machine time per test from January through September. Graphic: Linear.
Without the overhaul, Linear estimates the expanded suite would require roughly 11 minutes to run. Developers currently wait a little over five minutes. Those figures are Linear's internal measurements, indexed against its own January pipeline rather than an outside benchmark.
The pressure is closely tied to Linear's product strategy. In an August growth disclosure, Linear said agents were installed in 95% of its paid workspaces and generated 50% of work in the product, up from 3% a year earlier. Linear also said it had passed $100 million in annual recurring revenue and served more than 40,000 paying companies. The internal CI problem gives Linear a direct view of what its customers will face as agent-produced output expands.
Faster hardware bought the first gains
Amjad began with infrastructure rather than rewriting the pipeline. Linear moved its workloads away from GitHub Actions runners to an unnamed third-party provider offering faster CPUs, storage, and caching. In a comparison covering the two days before and after the switch, Linear says jobs ran 34% faster on average. TypeScript compiler jobs improved by 52%.
A move to tsgo, the native TypeScript compiler, cut the weekly median type-checking time by 73%. Linear also rewrote custom ESLint rules so they could analyze syntax without the complete TypeScript type graph. That reduced API lint time by 68% and full-repository lint time by 55%, while preparing those rules for a later move to Oxlint.
The provider switch also introduced intermittent checkout stalls because the external runners connected to GitHub outside GitHub's own network. Linear replaced the standard checkout action with its own retry and timeout logic, along with a persistent Git mirror. The episode is a useful reminder that faster infrastructure often moves failure into the network path rather than removing it.
Small jobs were consuming large amounts of compute
Some of Linear's largest savings came from eliminating repeated setup around tasks that took only seconds to execute.
Seven checks had each been starting a runner, checking out the repository, and installing dependencies independently. Amjad's team consolidated them into two jobs and ran the checks concurrently inside those jobs. Based on June usage, Linear says the change saved roughly 87,000 runner-minutes per month, equal to 11.8% of its total CI usage.
The API test workflow also stopped installing Linear's entire monorepo when it needed only the API package and its dependencies. Installation time fell from a range of 44 to 73 seconds to between 16 and 18 seconds. Restoring a cached node_modules directory took about 28 seconds, while rebuilding the filtered dependency set took roughly 7.5 seconds, so Linear removed the slower cache.
Database setup received the same treatment. Instead of replaying the full migration history for every container, Linear began a generated schema snapshot and bootstrap file. Setup fell from about 12 seconds to one or two seconds per container.
More parallelism required less setup
Linear increased its API test suite from four shards to eight after reducing the fixed cost of starting each shard. The slowest shard fell from 5.25 minutes to 4.33 minutes one week after the change.
Amjad's largest single improvement came from allowing eligible Vitest files to share module state inside a worker. Linear says the change reduced total API-shard runner time from about 32.8 minutes to 22 minutes per run and produced roughly 17% in monthly savings at its current volume.
Shared state can also let one test contaminate another. Linear made the faster mode opt-in, required teardown rules, and kept tests using fake timers or difficult shared state in isolated workers. It also updated its agent skills so generated tests follow the same performance constraints by default.
That detail carries the larger lesson from Artman's assignment. AI coding can generate enough work to expose years of accumulated setup costs and serial dependencies. The useful response is measurement and routine engineering: fetch fewer files, install fewer packages, reuse safe state, and keep short tasks from each renting a separate machine.
Linear reports runner-minute savings and relative speedups rather than dollar costs, leaving the financial return dependent on its provider rates and workload mix. The operational result is clearer. Linear absorbed a near-quadrupling of its test suite while reducing both wait time and compute consumed per test.
For a product built around coordinating people and agents, that outcome matters beyond an internal infrastructure bill. Artman and Amjad have shown where agent-driven development hits its next limit: every increase in code generation creates a corresponding demand for faster, cheaper and carefully isolated verification.