The promise of AI coding assistants is intoxicating. With a few keystrokes, developers can prompt an LLM to scaffold entire features, generate comprehensive test suites, and refactor sprawling components. But this explosion of productivity comes with a hidden tax. When code generation outpaces infrastructure, engineering teams fall straight into the AI velocity trap.

Linear, a company renowned for its obsession with software craftsmanship and speed, ran headfirst into this wall. As developers and automated agents embraced AI-driven workflows, Linear’s test suites almost quadrupled in a single year. Suddenly, their CI/CD pipelines—once a smooth highway for code delivery—transformed into a congested bottleneck. Pull requests backed up in merge queues, and developer friction threatened to neutralize the very velocity AI tools were meant to provide.

To keep up, Linear had to stop treating CI as a set-it-and-forget-it configuration file and start treating it as a core product infrastructure priority. Overhauling their TypeScript monorepo required a multi-pronged strategy: migrating to high-performance hardware, rewriting static analysis tooling, and rethinking test orchestration.

Diagnosing the Monorepo Bottleneck at Linear

Managing a large-scale TypeScript monorepo managed via pnpm workspaces is already an exercise in architectural discipline. Add thousands of newly generated AI tests and code files to the mix, and the complexity multiplies exponentially.

Linear’s initial symptoms were familiar to any team scaling rapidly: pull request wait times creeping past six minutes, ballooning runner times per test, and a heavy reliance on default GitHub Actions runners that struggled under the weight of massive node_modules directories and parallelized test matrices.

[ AI Code Generation ] ──> [ Bloated Monorepo Workspace ]
                                      │
                                      â–Ľ
                      [ Default GHA Runners Saturated ]
                                      │
                                      â–Ľ
                      [ Merge Queue & Developer Friction ]

By default, standard cloud runners spin up generic virtual machines with limited I/O throughput and constrained CPU allocations. For a heavy TypeScript workspace, operations like pnpm install, disk-heavy file caching, and deep dependency graph resolutions consume precious minutes before a single test even executes. Linear realized that fixing the bottleneck meant attacking it across three distinct layers: hardware infrastructure, compilation efficiency, and orchestration logic.

Hardware and Runner Optimization: Moving Beyond Default Infrastructure

The first low-hanging fruit was the underlying compute. Relying on default GitHub Actions runners meant Linear was leaving performance on the table, constrained by standard-issue virtual machine specs that buckled under heavy I/O workloads.

Linear transitioned their heavy workloads to optimized, third-party runner infrastructure equipped with faster NVMe storage, higher core counts, and improved memory bandwidth. The impact was immediate: jobs ran 34% faster on average, and TypeScript compilation (tsc) checks saw individual drops of up to 52% just from the hardware upgrade alone.

However, faster hardware is only useful if you aren’t wasting cycles on unnecessary data transfer. Linear optimized their workflow setup by pruning redundant overhead through sparse and blobless Git checkouts. Instead of pulling the entire commit history and every asset across the monorepo for every ephemeral job, the pipeline fetches only the necessary file trees. This reduces network I/O and speeds up workspace initialization, ensuring that the beefy new runners spend their cycles compiling code rather than uncompressing git objects.

Accelerating TypeScript Compilation and Linting

With hardware optimized, the software stack itself needed a rigorous audit. TypeScript compilation and linting represent a massive chunk of any CI pipeline, and traditional tooling struggles when codebases scale into hundreds of thousands of lines.

Linear tackled tsc checks head-on by switching to tsgo—a native TypeScript compiler implementation. By bypassing parts of the traditional JavaScript-based execution path, this shift slashed the weekly median of the tsc check time by a staggering 73%.

Linting underwent a similar revolution. Historically, tools like ESLint build a full type graph to validate rules, which becomes brutally slow in a large monorepo. Linear rewrote their custom ESLint rules to rely strictly on Abstract Syntax Tree (AST) static analysis rather than requiring full type graph building.

The results of these two software adjustments were dramatic:

  • API lint time dropped by 68%.
  • Full-repo lint time dropped by 55%.

By leveraging AST-based techniques and native compilers, Linear ensured that static analysis stopped acting as a tax on every single git push.

Optimization Vector Traditional Approach Optimized Approach Performance Gain
TypeScript Compilation Standard tsc on default runners tsgo on high-performance runners 73% reduction in median check time
API Linting Full type graph building in ESLint AST-based static analysis 68% reduction in lint time
Full-Repo Linting Standard ESLint configuration Rewritten AST-driven rules 55% reduction in lint time
Test Sharding Isolated state across all test files Opt-in shared module registry (isolate: false) 17% cost reduction & faster shard times

Job Batching and Test Sharding Strategies

Even with faster compilers, orchestrating a massive matrix of tests requires careful workflow design. When AI assistants generate tests by the dozens, developers often end up with dozens of tiny, independent verification jobs that swamp the scheduler with overhead.

Linear tackled this by consolidating workflows. They batched seven independent short checks into two distinct jobs. This architectural consolidation saved roughly 87,000 runner-minutes per month, accounting for an 11.8% total reduction in CI usage.

For heavy test execution using Vitest, Linear scaled their multi-sharded parallelization from 4 to 8 shards. But sharding alone wasn’t enough; test isolation overhead was dragging down execution speeds. To solve this, they introduced an opt-in Vitest project configuration with isolate: false for suites where state pollution wasn’t a risk.

By running tests within a shared module registry rather than spawning isolated execution contexts for every single file, they dropped their slowest shard times from 300–379 seconds down to about 195 seconds, shaving an additional 17% off monthly CI costs.

Quantifying the Impact: Developer Experience and Cost Savings

Infrastructure optimizations are ultimately judged by two metrics: developer velocity and cloud spend. If engineers are still waiting around for green checkmarks, the engineering is incomplete.

Linear’s comprehensive overhaul shifted the dial across every critical indicator:

  • Pull request wait times dropped from over 6 minutes down to just over 5 minutes, restoring the feedback loop for active developers.
  • Runner time per test was cut roughly in half, meaning that quadrupling test suites didn’t result in a quadrupling of cloud bills.
  • Overall monthly cloud infrastructure costs plummeted due to the combination of job batching, reduced execution times, and optimized runner efficiency.

These improvements align closely with broader industry movements toward efficient AI integration. As explored in discussions on how the tech industry moves towards efficient AI, managing compute constraints has become a defining engineering challenge of our time. Much like the strategies highlighted in our analysis of DeepSeek’s engineering approach to AI compute constraints, winning teams are learning that brute-force scaling is unsustainable; instead, success requires rigorous architectural efficiency.

Future Outlook: Sustainable Engineering in the Age of AI Automation

The velocity of AI code generation is not slowing down. As coding assistants evolve into autonomous agents capable of generating entire modules, pull requests will only grow larger and more frequent. Codebases will continue to scale at unprecedented rates, meaning that today’s optimizations will eventually become tomorrow’s bottlenecks.

To stay ahead, engineering teams must view CI/CD infrastructure as a living system. This will require continuous innovation in distributed test execution, highly granular change-detection algorithms that only run tests affected by specific AST diffs, and broader adoption of native, compiled toolchains.

Ultimately, sustainable engineering in the age of AI automation demands that pipeline efficiency be baked directly into the toolchain. As AI agent frameworks mature, they will need natively integrated, context-aware constraints that respect CI/CD limits—ensuring that the code being generated is not only functionally correct, but architecturally lightweight enough to ship without breaking the build.