AI coding has made CI a bottleneck, so we reworked ours to keep up

TL;DR Highlight

Tests quadrupled, yet Linear cut PR CI wait from 6+ to ~5 minutes and halved runner time per test.

Who Should Read

A backend developer on a TypeScript monorepo whose CI wait times and runner costs are rising as AI agents flood in PRs.

Core Mechanics

Tests quadrupled, wait time still dropped
- The test suite almost quadrupled since the start of the year.
- PR wait fell from over 6 minutes to just over 5, and runner time per test roughly halved.
Faster runners and compiler gave big wins
- Moving off GitHub Actions to third-party runners with faster CPUs, storage and cache made jobs 34% faster on average, comparing the two days either side of the switch.
- tsc-type jobs dropped 52%.
- Switching to tsgo cut the weekly median tsc check by 73%.
Linting without the type checker
- Custom lint rules were rewritten as static analysis over the AST instead of using type info.
- ESLint dropped TypeScript, cutting API lint time by 68% and full-repo lint by 55%.
- Syntax-only rules also made the move to Oxlint easier.
Shrink the gating jobs first
- Change-detection jobs got a capped fetch depth and no checkout where unneeded.
- Their median fell from 26s to 8s and the slowest run from 138s to 37s.

Community Reactions

Opinion that human testing is the real bottleneck
- One commenter said checking whether the product works the way customers will understand and like is the slow part.
Opinion that LLM-written tests are often useless
- Commenters said many tests in LLM-heavy PRs only exercise built-ins or trivial behavior.
- Others asked whether four times the tests produced four times the value.
Experience cutting CI with self-hosting and Bazel
- One commenter got CI with full linting and unit tests under 60 seconds using self-hosted runners, Podman and Docker images as cache.
- Others said Bazel gives about 10s builds with a warm cache, and that build and test must be scheduled together.
Opinion that agents prefer small isolated services
- One commenter argued contract-only boundaries let agents iterate internally, favoring them over monoliths.

How to Apply

Make change-detection checkouts shallow
- Open the first change-detection or path-filter job in your workflow today.
- Set a limited fetch-depth and delete checkout from jobs that need no working tree.
- Compare job durations before and after.
Measure per-shard setup before adding shards
- Read test job logs to time install and DB prep before tests start.
- Cut setup with pnpm --filter installs and a base image before raising shard count.
Split big test files and relax Vitest isolation
- Split the large test files in your slowest shard.
- Put only safe files into an isolate: false project with an opt-in comment, and keep fake-timer files out.
Put test rules in your agent instructions
- If agents write your tests, add the opt-in conditions and teardown rules to the skill or instruction file.

Try It

copy & run

# Paste into Claude Code or ChatGPT (the article's method turned into a prompt)

Below are our CI workflow file and a summary of recent job logs.

{{workflow YAML}}

{{per-job duration / setup time}}

Analyze in this order.
1. Find unnecessary full checkouts in front-of-pipeline jobs that gate others (change detection, etc.).
2. Find setup repeated in every job (apt, pnpm install, DB migrations).
3. Tell me whether full-workspace installs can become installs of only the needed packages.
4. Calculate whether adding shards would make setup cost exceed test time.
5. List each fix by expected time saved and show the modified YAML.

Next step: paste per-file test durations of your slowest shard and ask which files to split.

Terminology

ShardA slice of the test suite run on its own runner in parallel. Like adding checkout lanes, but each lane has its own setup time.

Critical pathThe longest chain of jobs that determines total completion time. A slow job here makes everything after it wait.

tsgoA native implementation of the TypeScript compiler. It runs the same type check much faster.

ASTA tree representation of code's syntax. Used to check code by its shape without type information.

Merge queueA queue that merges passing PRs in order. A slow required check keeps a PR waiting even after tests pass.