Your Agents Write Code Faster Than You Can Check It

Linear published an engineering post on Sunday with a title that reads like a confession: AI coding has made CI a bottleneck, so we reworked ours to keep up.

The numbers underneath it are the interesting part. Agents now write most of Linear's tests. The repository is adding roughly 2,000 tests a week. The suite is close to four times the size it was in January. Without any changes, running it would take about eleven minutes per pull request.

Engineers wait a little over five.

One engineer, Mufeez Amjad, got that result after Linear's CTO Tuomas Artman handed him an issue titled "CI costs are high." No rewrite, no new platform. Mostly deletions of work that did not need to happen.

Six things, roughly in order of how much they returned.

Linear moved off GitHub Actions to a third-party runner provider with faster CPUs and caching. Jobs got 34% faster on average in the two days before and after the switch, and TypeScript compiler jobs got 52% faster. It adopted tsgo, the native TypeScript compiler, which cut weekly median type-checking time by 73%. It rewrote custom ESLint rules so they analyse syntax without building the full type graph, which cut API lint time 68% and full-repository lint time 55%.

Then the unglamorous ones. Seven separate checks were each starting their own runner, cloning the repository, and installing dependencies. Consolidating them into two jobs saved about 87,000 runner-minutes a month, 11.8% of total CI usage. The API test workflow stopped installing the entire monorepo when it needed one package. Database setup switched from replaying the full migration history to loading a schema snapshot, dropping from twelve seconds to one or two per container.

Pull request wait time went from over six minutes to just over five. Machine time per test halved. The suite quadrupled.

Because verification does not scale the way generation does.

An agent writing a test costs you tokens and about four seconds. Running that test costs you a runner slot, a checkout, a dependency install, a database, and a place in a queue behind everyone else's tests. Generation got roughly a hundred times cheaper in two years. Verification got maybe two times cheaper.

So the constraint moved. It did not disappear, it relocated downstream, and it landed somewhere most teams were not measuring.

Linear had a clean view of this because of its own product. In August the company said agents were installed in 95% of paid workspaces and generated 50% of the work happening in the product, up from 3% a year earlier. Its internal CI problem is a preview of what its customers hit next.

This is the part worth internalising, because it contradicts what most people assume.

Linear's biggest single infrastructure win was not making tests run faster. It was stopping seven small jobs from each renting their own machine. The checks themselves took seconds. The ceremony around them took minutes.

Same story with dependency installation. Restoring a cached node_modules directory took about 28 seconds. Rebuilding a filtered dependency set took about 7.5 seconds. So Linear deleted the cache, which is the opposite of what a reflex would tell you.

If you are a four-person team looking at a CI bill, the instinct is to buy bigger machines. The evidence says to first count how many times per pull request you clone your repository and install your packages. That number is usually embarrassing and almost always free to fix.

Linear increased its API suite from four shards to eight, but only after reducing the fixed cost of starting each shard. Order matters. Doubling shards before you fix setup just doubles the setup you pay for. The slowest shard fell from 5.25 minutes to 4.33 minutes a week after the change.

The largest single improvement came from letting eligible Vitest files share module state inside a worker, which took total API-shard runner time from about 32.8 minutes to 22 minutes per run.

And it carries a real risk: shared state lets one test contaminate another. Linear made the mode opt-in, required teardown rules, and kept anything using fake timers or awkward shared state in isolated workers.

Then it did the thing almost nobody does. It updated its agent skills so generated tests follow the new performance constraints by default. The agents that created the problem got taught the rule. That is the difference between a fix and a fix that holds.

You do not have 2,000 tests a week. You will still recognise the shape.

Measure wait time, not cost first. Cost is a symptom, and the number that changes behaviour is how long an engineer sits there. Linear's CTO asked for both and got both.

Count your repeated setup. Checkouts, installs, container boots, migration replays. Every one of those is a fixed tax paid per job, and most small teams are paying it five or six times per pull request without knowing.

Give the work to one person with a clear brief. Amjad's issue title was four words. It was not a committee.

Update whatever instructions your agents run on, the moment you change a constraint. If your agent writes a test that violates the rule you just set, you have not changed the rule.

And accept that the bottleneck will move again. It moved from writing code to verifying it in about eighteen months. It will move from verifying to reviewing, then to deciding what to build.

Most early-stage plans still model engineering capacity as a headcount number. That assumption is now shaky.

If agents triple your output of changes, your plan has to carry a corresponding line for verification: CI minutes, review hours, staging environments, incident load. Otherwise you have planned a quarter where the work gets produced and never ships.

The practical version is a small model with two columns. What increases when output goes up, and what does not. Test runs go up. Code review hours go up. Product decisions do not. Customer conversations do not. That split tells you where to spend and where to hold.

You can build that in a spreadsheet, in Causal, or in a planning tool like Foundra that keeps operating assumptions next to the projections that depend on them. The tool matters less than writing the assumption down with a date on it, because in six months you will want to know what you believed and whether it held.

Linear reported runner-minute savings rather than dollar figures, which is a reasonable limit on what any outside team can copy directly. The operational result travels fine.

• Linear's test suite nearly quadrupled in 2026 because agents write most of its tests. Pull request wait time still fell from over six minutes to just over five.
• Generation got dramatically cheaper. Verification did not. The bottleneck moved downstream to CI, review, and release.
• The biggest wins came from removing repeated setup, not from faster execution. Consolidating seven jobs into two saved 11.8% of total CI usage.
• Sometimes the cache is slower than the rebuild. Measure before you assume.
• Increase parallelism only after you reduce per-shard fixed cost, otherwise you multiply the overhead.
• Update your agent instructions when you change a constraint, or the agents will keep generating the old pattern.
• Plan capacity with two columns: what scales with code output, and what does not.

Is this only a problem for large codebases?

No, but it shows up differently. Small teams feel it as a slow pull request loop and a surprising bill rather than as queue contention. The underlying cause, fixed setup cost paid repeatedly, is the same at any size.

Should we move off GitHub Actions?

Linear did and got a 34% average speedup, but it also inherited intermittent checkout stalls because external runners connect to GitHub from outside GitHub's network. It had to write its own retry logic and keep a Git mirror. Faster infrastructure often relocates the failure rather than removing it.

How much of this needs a specialist?

Less than you would think. Consolidating jobs, trimming installs, and snapshotting a database schema are routine engineering. Shared module state across tests is where you want somebody careful.

What if our agents write bad tests, not just many tests?

Then volume makes it worse, not better. Set the constraints in your agent instructions before you scale output, and treat a generated test with no assertion as a failure rather than as coverage.

Where does the bottleneck go next?

Human review is the common answer. Once verification is fast, the queue forms in front of whoever has to decide whether the change is correct and wanted.

Does this mean AI coding is not worth it?

Linear passed 100 million dollars in annual recurring revenue with more than 40,000 paying companies while running this way. The point is that the second-order cost is real and belongs in your plan, not that the first-order gain is fake.

1. AI coding has made CI a bottleneck, so we reworked ours to keep up, Linear engineering blog, September 21, 2026
2. Linear reworks CI as coding agents make validation the expensive part, RuntimeWire, September 21, 2026
3. AI coding has made CI a bottleneck, Hacker News discussion, September 21, 2026
4. Sharing growth with the people building Linear, Linear, August 2026
5. Inside Linear engineering culture, The Pragmatic Engineer
6. Oxlint usage guide, Oxc