Stackness
All moves

Reworking CI pipelines to keep pace with AI-generated code volume

by Stackness

DevOps & Infrastructure

As coding agents generate far more PRs and commits than humans alone, CI throughput becomes the new bottleneck on shipping velocity. Teams respond by upgrading CI infrastructure, switching to native (non-transpiled) compilers, narrowing what lint rules type-check, and limiting git fetch depth, treating CI speed itself as a metric to optimize under load. The goal is to keep PR wait times flat even as test coverage and PR volume both climb.

What it is

As AI coding agents multiply pull request volume, continuous integration itself becomes the bottleneck that slows shipping. This move treats CI speed as a metric to actively optimize, reworking infrastructure, toolchains, and lint scope so that PR wait times stay flat even as test suites and code volume keep growing.

How to do it

  • Audit where CI time actually goes before optimizing blindly. Track both PR wait time and runner time per test as separate metrics, since gains in one do not always mean gains in the other.
  • Move workloads off default hosted runners onto third-party runners with faster CPUs, better storage, and improved caching. This alone can cut job time by roughly a third with no pipeline changes.
  • Swap transpiled or slower type checkers for native compiler tooling where available. Switching to a native TypeScript compiler moved typechecking off the critical bottleneck path entirely.
  • Rewrite lint rules that depend on full type information so they use syntax-only static analysis instead. Dropping the type-checking dependency in linting can cut lint time dramatically and reduce memory usage, while also making later linter migrations easier.
  • Identify the small gating jobs that every other job waits on, such as change-detection or cache-hit checks, and shrink their delay since they sit directly on the critical path.
  • Limit git fetch depth and setup steps to only what each job actually needs, avoiding repeated full-repo work across shards.

When it helps

This approach helps once test suites and PR counts are growing fast, particularly when AI agents are generating a large share of commits and pull requests, and developers or agents are waiting longer than they should for feedback on every change.

Pitfalls

Optimizing one dimension can regress another. Adding more test shards shortens wait time but increases total machine time, and infrastructure changes like checkout behavior can introduce new stalls. Treat CI performance as a system with tradeoffs, not a single number to chase.

Sources

Tools