Pimp My IDE / Garage Dispatch
Back to garage
September 21, 2026 | CI / critical path / agent speed

Your agent got faster. The exit lane did not.

Linear cut machine time per test while its test suite grew to almost four times its earlier size. The useful lesson is not "buy faster runners." It is to measure the gate, repeated setup, useful work, and merge tail as separate costs.

THE TAKE: CI wall time and runner time are different gauges. Tune the critical path first. Then remove repeated work that burns machines without moving the merge.
Open the CI Critical Path Pit Lane

The new bottleneck is proof.

Linear reports that its test suites almost quadrupled during 2026. Over the same period, the company reduced pull request wait time from more than six minutes to just over five. It also cut runner time per test roughly in half.[1]

Those are Linear's measurements on Linear's codebase and CI setup. They are not a forecast for another repository. The method transfers better than the percentages. Measure how long a pull request waits and how much machine time the run consumes. A change can improve one gauge while hurting the other.

Small gates can hold every car.

Linear found change-detection jobs sitting in front of all test shards. A full checkout made those small jobs expensive. The team capped history, removed checkout where no working tree was needed, and used sparse, blobless checkout where a path diff was required. The reported median for one change-detection job fell from 26 seconds to 8 seconds.[1]

GitHub's checkout action fetches one commit by default. It also supports sparse checkout and a partial-clone filter.[2] Do not cargo-cult a shallow clone. First write down the exact question the gate must answer. A path diff needs enough history to identify the comparison base. A metadata-only decision may not need a working tree at all.

A ten-second gate in front of eight shards costs ten seconds of wall time. It can also leave eight machines waiting for permission to work.

Setup belongs on the timing board.

Linear also reports that seven short checks each paid for a runner, checkout, and dependency install. The team grouped them into two jobs and ran the checks concurrently inside those jobs. Based on its June usage, Linear says this saved about 87,000 runner-minutes per month.[1]

The same article describes filtered package installation. One API workflow moved from a full workspace install that took 44 to 73 seconds to a filtered install that took 16 to 18 seconds. pnpm documents selectors for a package, its dependencies, its dependents, directory globs, and packages changed since a commit.[3]

Filtering is policy, not a free speed switch. If the selector misses a dependent package, the run gets faster by skipping evidence. Put the selector under tests. Keep a scheduled full-workspace lane as a backstop when the change graph is hard to prove.

Delete the tail that gates nothing.

Linear found a cache-marker write on the merge path after tests had passed. Moving that write to a job that gated nothing removed 42 seconds from the path for affected API pull requests and merge-queue entries.[1]

This is the cleanest tuning question in the shop. If a post-test step fails, should the pull request remain blocked? If the answer is no, move it out of the required path. Keep its failure visible. Do not make the merge wait for bookkeeping.

Run the audit in this order.

  1. Draw the dependency graph and mark the longest required path.
  2. Measure queue time, gate time, setup, useful work, and tail separately.
  3. Remove checkout, package installation, and service boot where the job does not use them.
  4. Batch short checks only when failure output stays clear and reruns stay cheap.
  5. Move non-gating writes, uploads, and reports after the merge gate.
  6. Track wall time and runner-minutes after every change.
Interactive makeover / timing board

CI Critical Path Pit Lane.

Traditional purpose replaced: one total CI duration and a pile of job logs. Better version: split gate, setup, useful work, and tail on one physical timing strip. The same controls update wall time, machine burn, bottleneck, and a copyable audit card.

Set one representative CI lap

This is a teaching proxy. It assumes equal parallel shards and does not read your CI provider. Enter measured medians or percentiles from one matched workload.

Timing controls
26 sChange detection, policy, or routing before parallel jobs can start.0 s120 s
120 sRunner boot, checkout, package install, and service preparation per shard.0 s240 s
180 sThe test, build, lint, or analysis step that produces required evidence.10 s600 s
42 sRequired work after the useful check finishes.0 s180 s
8Equal jobs that start after the gate and run in parallel.116
TIMING MODEL6m 08s
Critical path wall time6m 08s
Estimated runner burn41.1 min
Largest stage / useful work

Useful work is 49% of the wall path. Optimize it only after the test still proves the same thing.

Why it is better: one adjustment updates the physical strip, wall time, machine burn, bottleneck, and handoff. The calculator keeps the result labeled as a model until you replace the controls with measured data.
Sources read, not vibes
  1. Linear, "AI coding has made CI a bottleneck, so we reworked ours to keep up": company measurements, gate analysis, checkout changes, setup reduction, filtered installs, batching, cache tests, and merge-tail removal.
  2. GitHub actions/checkout: default fetch behavior, fetch depth, sparse checkout, partial-clone filters, and checkout configuration.
  3. pnpm filtering documentation: package, dependency, dependent, directory, and changed-since selectors.
  4. Hacker News front page, September 21, 2026: discovery scan for current developer-tool signals. It is not used to verify Linear's measurements.

Source boundary: Linear reports results from its own TypeScript monorepo and CI provider. GitHub and pnpm document available controls. The pit-lane calculator is a simple planning model. It is not provider telemetry, a queue model, or a prediction of savings.