AI Coding Made CI the Bottleneck. Linear Fixed It. Here Is What Everyone Else Is Getting Wrong.

The Problem Nobody Was Tracking Until It Was Embarrassing

When Linear’s CTO Tuomas Makinen assigned a ticket titled “CI costs are high” to engineer Mufeez Amjad earlier this year, the framing was almost comically understated. By the time the work was done, they had cut runner time per test roughly in half, reduced per-shard setup from 110-140 seconds to 67-73 seconds, and documented the kind of CI transformation that most engineering teams claim they want but consistently deprioritize. The blog post they published on September 21, 2026 is worth reading in full. But the story it tells is larger than Linear’s particular infrastructure wins.

The story is this: AI coding agents have changed the fundamental economics of software development pipelines in a way that most teams have not yet internalized. The bottleneck has moved. It moved earlier this year, quietly, and the teams that noticed first are the ones now writing about 34% faster CI job runtimes and 87,000 runner-minutes saved per month. The teams that did not notice are the ones looking at their AWS bills wondering where the growth came from.

I have been watching this shift closely because I spent the better part of 2024 arguing with colleagues that CI optimization was a boring problem, the kind of thing you fix once and forget. I was wrong. AI coding changed the inputs dramatically, which means the outputs — pipeline duration, cost, developer feedback loop — have changed dramatically too, even if you have not touched your CI configuration in eighteen months.

Why AI Coding Broke the Relationship Between Commits and CI Load

Traditional software development has a roughly human-paced commit rhythm. A developer writes code, thinks, tests locally, revises, then opens a pull request. The PR might sit in draft for hours. The CI run might be triggered once or twice before the PR is ready for review. The feedback loop has natural throttles built into human biology and psychology: attention span, meeting schedules, lunch breaks, the psychological cost of context-switching.

Agentic coding removes most of those throttles. An agent can open twenty pull requests while you sleep. It can trigger a CI run, read the failure output, apply a fix, and re-trigger within minutes. The commit cadence that a single engineer with agents produces looks nothing like the commit cadence of a single engineer without them. This is not speculative — Linear states it explicitly: “Agents have made it exponentially faster to ship code, but validating those changes hasn’t quite kept up at the same rate.” That gap between shipping speed and validation speed is the entire problem.

What this means in practice is that CI systems designed for human-paced development are now processing workloads that look more like continuous integration from a small army of tireless junior developers who never take breaks and never context-switch. The infrastructure cost scales with commit frequency, not headcount. If your team of 10 engineers each gained an agent that triggers CI twice as often, your CI workload doubled — but your CI budget and configuration did not.

The industry has mostly responded to this by adding more runner capacity and accepting higher bills. That is the path of least resistance, and it is the wrong one. Linear’s post is notable because it refuses that path. Instead, it asks what actually needs to run, when it needs to run, and how to run it with minimum redundant overhead.

The Four Optimization Categories and What They Actually Mean

Linear’s post organizes their work into four buckets: upgraded infrastructure and tooling, optimizing gating jobs, reducing repeated setup, and making test execution more efficient. This is a useful taxonomy, but I want to reframe each one through the lens of what AI coding specifically exposed.

Infrastructure and Tooling Upgrades: The Underappreciated Floor

Moving off GitHub Actions to third-party runners with faster CPUs and better cache infrastructure gave Linear a 34% average speedup with no optimization effort at all. Some workloads dropped 52%. That is a remarkable return on what is essentially a procurement decision.

The deeper lesson here is about where the performance floor sits. GitHub Actions runners are provisioned for general availability across a massive customer base. They are not provisioned for peak performance. When your CI load was low and your feedback loop tolerance was high, this did not matter. When an agent is waiting on CI feedback to decide its next move, every second of runner overhead is a second the agent is blocked. The economics of “good enough” infrastructure shift when the consumer is a non-sleeping agent rather than a human who has gone to make coffee.

Separately, Linear’s switch to tsgo — the native Go-based TypeScript compiler — cut their weekly median tsc check time by 73%. This is the kind of single-line improvement that most teams have available to them right now and have not yet taken. The tsgo project has been maturing since early 2025, and by mid-2026 it is production-ready for most TypeScript workloads. If your CI pipeline includes a tsc check that takes more than 60 seconds, the correct action is to test tsgo against your codebase today, not next quarter.

Eliminating Type Information from Lint: A Pattern Worth Stealing

This is the most technically interesting optimization in Linear’s post, and it generalizes well beyond their specific stack. Their custom ESLint rules required TypeScript type information, which meant every lint run had to build the full type graph before it could evaluate even simple rules. This made linting one of the most memory-intensive CI jobs in their pipeline.

They rewrote the rules to use static AST analysis instead. The result: API lint time dropped 68%, full-repository lint time dropped 55%, and memory usage fell substantially. The type-information dependency was essentially paying a very large tax to answer questions that could be answered more cheaply through syntax analysis alone.

I have seen this pattern in multiple codebases. Teams write lint rules that feel right when they depend on type information — the rule seems more accurate, more aware of what the code is actually doing. But the cost is enormous, and the accuracy gain over a well-written AST rule is often marginal for the categories of problems lint actually catches. The question to ask your team: which of your lint rules actually require type information to be correct, and which ones just happen to use it because the type APIs were convenient?

The secondary benefit Linear gained from this refactor — that Oxlint migration became significantly easier — illustrates how architectural decisions in CI compound. They were not optimizing for Oxlint compatibility. They got it for free by making a correct decision earlier.

The Critical Path Problem: Small Jobs With Outsize Impact

Linear’s third category surfaces a counterintuitive truth about pipeline optimization: the most impactful jobs to speed up are often the smallest ones, not the longest ones, provided they sit on the critical path.

Their change-detection job — which checks which paths a PR touched and whether tests have already passed for the same inputs — was a small job. It did not run long. But it sat in front of all eight API test shards. No shard could start until it finished. They reduced its median duration from 26 seconds to 8 seconds by doing two things: capping fetch depth for jobs that only needed a small subset of the working tree, and removing checkout entirely from jobs that needed no working tree at all.

The slowest run of that job fell from 138 seconds to 37 seconds. That tail matters enormously when you are running CI thousands of times a week. The average case improved by 69%, but the worst case improved by 73%, and the worst case is what creates the “CI feels slow” perception that engineers and agents experience.

Linear also found that they were writing cache markers as part of the final check before merging — meaning a PR could sit in the merge queue after its tests had passed, waiting for this write to complete. Moving that write to a non-gating job shaved 42 seconds from the merge path for every API PR. This is the kind of optimization that requires someone to actually look at the pipeline as a system, trace the critical path end-to-end, and ask what is blocking what. It is not glamorous work. It is reliably high-leverage.

Setup Overhead: The Tax That Scales With Shards

Linear’s most detailed set of optimizations addresses setup overhead — the fixed cost paid at the start of every job before any useful work happens. Installing Postgres via apt: 7-8 seconds per shard, every run. Installing the full pnpm workspace when only the API package was needed: 44-73 seconds, down to 16-18 seconds after filtering. Replaying full database migration history on every run when the schema had not changed: 12 seconds per container, down to 1-2 seconds after switching to a schema snapshot.

These numbers look small in isolation. They compound badly at scale. Linear runs roughly 8 shards per API test run. If they run CI 1,000 times per week — conservative for an agent-augmented team — 8 seconds of unnecessary Postgres installation per shard is 64,000 seconds of wasted runner time per week, or about 1,067 runner-minutes. Multiply across every similar inefficiency in the pipeline and you arrive at the 87,000 runner-minutes per month they saved by consolidating seven short checks into two parallelized jobs.

The batching optimization deserves particular attention. Seven independent checks, each starting a runner, checking out the repository, and installing dependencies before doing seconds of useful work. Consolidated into two jobs, running those seven tasks concurrently. Setup overhead paid twice instead of seven times. The savings — 87,000 runner-minutes per month, 11.8% of total CI usage — came entirely from refusing to pay the same setup cost repeatedly for tasks that did not need to be isolated.

This is a pattern I have encountered in almost every non-trivial CI pipeline I have audited. Teams add checks over time, each as an independent job for reasons that seemed good at the time — isolation, clarity, independent scheduling. The cumulative setup overhead accumulates invisibly. Nobody measures it because nobody is looking at setup time as a first-class metric. The moment you start looking at runner-minutes instead of just job duration, the batching opportunities become obvious.

The Vitest Isolation Trade-off: Correctness Versus Performance

The most technically nuanced optimization in Linear’s post is their introduction of an opt-in Vitest project with isolate: false. This allowed safe test files to share a module registry within each worker instead of rebuilding the entity, GraphQL, and decorator graph in each test shard separately. The result was their largest single performance improvement: roughly 17% in monthly savings, with the slowest shard falling from 300-379 seconds to about 195 seconds.

This optimization comes with correctness risk that Linear is explicit about. When you disable isolation, tests can share state in ways that make failures harder to reproduce and can create order-dependent failures that are notoriously difficult to debug. Linear handled this by making eligibility explicit — an opt-in comment on every eligible file — and writing the necessary teardown for shared state. Files that used fake timers or shared state in untangleable ways stayed in the isolated project.

What is particularly interesting is one sentence buried in their description: “because agents now write the majority of our tests, we updated our respective agent skills to account for this performance opt-in as well, so generated tests follow the same constraints by default.” This is a small sentence with significant implications. They are not just optimizing their CI pipeline — they are updating the behavioral parameters of their coding agents to produce tests that conform to their optimized CI constraints by default. The human-authored configuration and the agent-authored tests are in a feedback loop with each other.

This is what I mean when I say the industry has not yet internalized the full implications of agentic coding. It is not just that agents write more code. It is that the code agents write — its structure, its dependencies, its testability — becomes a variable you can tune by updating the agent’s instructions. Linear is doing this. Most teams are not.

The Sharding Math: Why Setup Time Is the Real Constraint

Linear’s observation about sharding constraints deserves to be extracted and stated plainly: further sharding only pays off when fixed cost per shard is low. This is a non-obvious result that trips up many teams.

The naive intuition is that more shards always means faster CI — you are parallelizing the work across more machines. But setup overhead is paid per shard. If setup takes 110 seconds and tests take 300 seconds, going from 4 to 8 shards cuts test time per shard from 300 to 150 seconds, but doubles the setup cost. Your total runner time goes from 4 x (110 + 300) = 1,640 minutes to 8 x (110 + 150) = 2,080 minutes. More shards, more cost, and potentially no improvement in wall-clock time if the bottleneck was elsewhere.

Linear proved this empirically: at 110-140 seconds per shard, eight shards would have spent 15-19 minutes of runner time on setup alone, more than the tests themselves. After reducing setup to 40 seconds, eight shards spend less total setup time than four did before. The sharding optimization was only viable after the setup optimization. Teams that try to shard their way out of a slow CI pipeline without first addressing setup overhead are making the problem worse.

The numbers here are approximate reconstructions from Linear’s post, but the shape of the trade-off is clear. Sharding without setup optimization is counterproductive. The correct sequence is: optimize setup first, then evaluate whether additional shards deliver a net reduction in total runner time.

What Most Teams Are Actually Getting Wrong

Linear’s post is a case study in doing things correctly. Here is a less flattering portrait of what I see most commonly in teams that have adopted AI coding without revisiting their CI infrastructure.

They are treating CI cost as a line item to accept rather than a system to optimize. When bills go up, the instinct is to categorize the increase as “cost of AI productivity gains” and move on. This framing is incorrect. The cost increase is real, but much of it is waste — setup overhead paid repeatedly, gating jobs with inflated fetch depths, lint rules that build the full type graph unnecessarily. These are not the costs of AI productivity. They are the costs of AI productivity meeting infrastructure that was never designed for AI-paced commit rates.

They are not measuring the right things. Most teams track job duration. Few track per-test runner time, per-shard setup overhead, or the ratio of setup time to test time. Without those metrics, you cannot identify which optimizations would have the highest leverage. Linear’s post is notable for the specificity of its measurements — they know the p50, p90, and maximum of their change-detection job before and after each optimization. That specificity is not accidental. It reflects a team that decided to treat CI as an engineering system with measurable characteristics rather than a black box that either passes or fails.

They are not updating their agent instructions to reflect their infrastructure constraints. If your agents are generating tests without knowledge of your CI configuration — whether your test framework supports shared module state, how your shards are structured, which setup steps are expensive — then your agents are optimizing for correctness in isolation while ignoring the systemic cost of their output. Linear’s update to their agent skills to account for the isolate: false opt-in is a small step toward CI-aware code generation. This will become a standard practice within two years. Teams that start now will have a meaningful head start.

They are not auditing their pipeline as a system. Individual jobs are reviewed. The pipeline as a dependency graph — which jobs gate which other jobs, what sits on the critical path, which jobs pay setup costs that could be shared — is rarely audited at that level. The 42-second gain Linear got from moving a cache write to a non-gating job is an example of what systematic pipeline review finds. You will not find these gains by looking at individual job durations.

The tsgo Question You Should Answer This Week

A specific, concrete, time-sensitive point: if you have TypeScript in your CI pipeline and you have not evaluated tsgo — the Go-based TypeScript compiler — you should do so this week. Linear saw a 73% reduction in their median tsc check time. This is not a marginal improvement. A tsc check that took 4 minutes before tsgo takes about 65 seconds after. At any meaningful CI volume, this is substantial.

tsgo achieved feature parity with the TypeScript compiler for most production TypeScript codebases by mid-2026. The flags are compatible, the output is identical, and the performance improvement is consistent across different codebase sizes. The migration path is: replace tsc with tsgo in your CI configuration, run it against your codebase, confirm that it passes the same checks. If it does, you are done. If it does not, file a bug — the TypeScript team is actively maintaining compatibility.

This is the rare CI optimization that requires no architectural change and delivers enormous leverage. The only reason not to evaluate it is inertia, which is a poor reason when the reward is a 73% speedup on one of the most common CI bottlenecks in TypeScript codebases.

The Compounding Problem Linear’s Post Quantifies

Linear ends their post with a projection: “Had we not made a deliberate effort to improve CI earlier this year, today’s test suite would take roughly 11 minutes, close to double what developers wait now.” They are currently adding roughly 2,000 tests per week.

This number gives a concrete illustration of what happens when CI optimization does not keep pace with test suite growth. At 2,000 tests per week and the old configuration, every week adds approximately 45-90 seconds to the total test run time. After six months without optimization, a 5-minute CI run becomes an 8- or 9-minute CI run. After a year, it is approaching 12 minutes. At that point, agent-triggered CI runs are long enough that the feedback loop materially slows the agent’s iteration speed.

The feedback loop between CI speed and agent productivity is tighter than most teams appreciate. Agents that get sub-5-minute CI feedback can iterate faster, fail more cheaply, and require less orchestration overhead to manage. Agents waiting 12+ minutes for CI feedback either block or context-switch, which increases the complexity of the orchestration layer managing them. CI optimization is not just a cost problem. It is a capability problem for agentic development, and the two framings lead to different organizational responses.

The cost framing leads to a budget conversation. The capability framing leads to an engineering conversation. Both conversations are worth having, but the engineering conversation is more likely to result in structural change. Teams that frame CI speed as a constraint on agent capability will invest in improving it. Teams that frame it only as a cost will add capacity and accept the spend.

What Actually Generalizes from This Post

Linear’s stack is TypeScript, Vitest, GitHub Actions migrated to third-party runners, and a pnpm monorepo. Not everyone shares this stack. But the generalizable lessons are not stack-specific.

First: measure at the right granularity. Per-shard setup time, per-test runner time, critical path duration, and tail latencies matter more than average job duration. If you are not collecting these metrics, start.

Second: find your gating jobs and their unnecessary dependencies. Every pipeline has small jobs that gate large ones. Every pipeline has jobs that fetch more than they need. These are consistently high-leverage targets that most audits miss because the jobs look cheap in isolation.

Third: evaluate your type-information dependencies in lint. This applies to any typed language with a lint ecosystem that can optionally use type information. The type-information path is expensive. Audit whether you actually need it for each rule, and rewrite the ones you do not.

Fourth: batch your short checks. If you have independent checks that each start a runner and install dependencies, you are paying setup overhead once per check. Consolidate them, run them concurrently, pay once. The savings scale linearly with the number of checks you consolidate.

Fifth: update your agent instructions to reflect your CI constraints. If agents are generating code and tests that hit your CI pipeline, they are already implicitly making decisions that affect CI cost and speed. Make those decisions explicit by encoding your CI constraints into the agent’s operational context.

The Organizational Problem Underneath the Technical One

I want to be honest about something that Linear’s post does not address, because it cannot: the organizational reason most teams have not done this work is not technical ignorance. The optimizations Linear describes are not obscure. Fetch depth optimization, sparse checkout, pre-installed dependencies in CI images, test file splitting — these are documented, widely discussed, and not difficult to implement.

The reason teams do not do them is prioritization. CI optimization is invisible work. When it is done well, nothing changes visibly — CI is fast, costs are reasonable, nobody thinks about it. When it is done poorly, the costs creep upward slowly and the slowdowns accumulate gradually, neither rapidly enough to create an incident nor dramatically enough to generate urgency. In most engineering organizations, work that prevents gradual degradation competes unfavorably against work that adds features, and it usually loses.

AI coding changes this calculation in a practical way. When CI costs and durations become large enough to appear as line items in infrastructure budget reviews, they acquire stakeholders. When CI slowness measurably reduces agent throughput — because agents are waiting on feedback rather than working — it acquires a velocity metric. The invisible becomes visible. The preventive work that was previously deprioritized becomes incident response.

Linear got ahead of this because their CTO created a ticket for it before the situation became critical. That is the organizational lever: someone with budget authority decided this was worth prioritizing before it became a crisis. Most teams will wait for the crisis. The teams that do not wait will end up with posts like Linear’s. The teams that do wait will end up writing apology comments on Hacker News about their CI bills after their next all-hands spending review.

Falsifiable Predictions

Here are specific predictions about how this space develops, with timelines I am willing to defend.

By the end of 2026, at least three major CI platforms — GitHub Actions, GitLab CI, and either Buildkite or CircleCI — will have released tooling specifically designed for agent-triggered CI workloads. This will include rate limiting by actor type, priority queuing for human-authored PRs over agent-authored PRs, and cost attribution broken down by commit source. The existing billing models do not surface the information needed to manage agentic workloads, and the platforms know it.

By mid-2027, “CI-aware test generation” will be a documented feature in at least two major coding agent platforms. Agents will, by default, generate tests that respect the CI configuration of the repository they are working in — shard structure, isolation settings, setup overhead profiles. Linear’s manual update to their agent skills will be automated and available to any team using a mainstream agent platform.

By end of 2027, the mean CI duration for teams using AI coding agents will be lower than it is today, despite dramatically larger test suites. The optimization pressure created by agentic commit volumes will force the work that teams have been deferring. The teams that do this work voluntarily in 2026 will have meaningfully better developer experience for two years before it becomes table stakes.

The final prediction: tsgo will be the default TypeScript compiler in CI pipelines at a majority of new TypeScript projects by the end of 2026. The 73% tsc speedup is too large to ignore once it achieves mainstream awareness, and the migration cost is trivially low. This one is close to a certainty rather than a genuine prediction — but I am stating it explicitly because I have spoken with multiple engineering teams in 2026 who had not heard of tsgo, and I find that remarkable given the performance difference involved.

Linear’s CI post is a record of unglamorous, high-leverage work done systematically. The industry should read it not as a Linear success story but as a checklist. The items on that checklist are available to most teams today. The question is whether the organizational will to prioritize them exists before the agentic commit volume forces the issue — and whether, when the issue is forced, the team responds with genuine optimization or with another runner capacity purchase.