AI Coding Is Making CI the Next Bottleneck for Fast-Moving Software Teams
AI coding tools are changing how quickly software teams can produce code. But as the pace of development increases, another part of the engineering process is starting to struggle: continuous integration, or CI.
Linear recently detailed how it reworked its CI infrastructure after AI-assisted development increased the amount of code and testing moving through its engineering pipeline. The company says its test suite nearly quadrupled during 2026, while pull request wait time still fell from more than six minutes to just over five minutes.
The bigger lesson goes beyond Linear. When coding agents can generate changes much faster, validation systems have to scale at the same pace. Otherwise, the bottleneck simply moves from writing software to checking it.
Why AI Coding Is Putting Pressure on CI
Traditional software development already requires a balance between writing code and validating it.
A developer makes a change, opens a pull request, and waits for automated checks to run. Those checks can include unit tests, integration tests, type checking, linting, builds and other quality controls.
AI coding agents change the equation.
An agent can produce multiple changes quickly and can also generate large numbers of tests. That increases the amount of work that CI has to process even if the underlying engineering team has not grown.
Linear says its repository is currently adding roughly 2,000 tests per week. The company also says agents now write the majority of its tests.
The result is a new infrastructure problem: generating code becomes faster, but validating that code still requires computing resources, test runners and time.
Linear's CI Challenge
The project began with a simple engineering issue: CI costs were high, and the system needed to become faster.
Linear engineer Mufeez Amjad described the problem as a mismatch between development speed and validation speed. As coding agents accelerated software production, every pull request still had to pass through the same basic CI process.
Linear therefore focused on two major measurements:
How long developers wait for a pull request to pass CI.
How much runner time the test suite consumes.
The company says the test suite grew to nearly four times its size compared with the beginning of the year, while runner time per test was cut roughly in half. Pull request waiting time also fell from more than six minutes to slightly above five minutes.
That is important because simply adding more machines can reduce waiting time while increasing infrastructure costs. Linear instead treated CI as a system that needed optimization at several different layers.
Faster CI Runners Delivered an Early Improvement
One of Linear's first changes involved the infrastructure underneath its CI jobs.
The company moved workloads away from GitHub Actions runners to third-party infrastructure with faster CPUs, storage and caching.
In a like-for-like comparison around the migration, Linear reported that jobs ran 34% faster on average. Some workloads improved even more, with TypeScript compiler jobs becoming about 52% faster.
This demonstrates an often-overlooked part of CI optimization: sometimes the pipeline does not need a completely new architecture. Faster hardware and better storage can produce immediate gains when existing infrastructure is limiting performance.
But hardware alone was not enough.
TypeScript Compilation Became Much Faster
Linear also modernized parts of its development toolchain.