AI coding agents write code in minutes, but every agent-generated pull request still waits on cold checkouts, fresh installs, and full test suites. Agents also multiply pushes, retries, and reruns, so every pipeline inefficiency, and the compute bill, gets amplified. This article explains how faster checkouts, caching, test selection, and flaky-test handling can speed up a slow monorepo, and where each technique can break. The goal is to cut feedback time for developers and agents, and to reduce CI spend, without trading away reliability.
Agents Changed the Shape of CI Load
Writing code got fast. Validating it did not. GitHub reports that by September 2026 more than 40% of pull requests on its platform began with an agent’s first draft, up from 17% in March, and that Actions jobs grew about 4.8x in a year. Those counts cover only agents GitHub can detect, but the direction is clear.
Cost follows a simple formula: runs × minutes per run × price per minute. Agents raise the first term with more pull requests, more pushes per pull request, and round-the-clock activity. Without test selection, growing test suites raise the second term.
Picture a monorepo with dozens of modules and a deep dependency tree that also builds a Docker image on every change, for each OS and architecture combination. Each push pays the same cold-start cost. Five fixes remove most of it, and each comes with a caveat.
Stage proportions vary by repository, so measure yours before choosing a fix.
1. Stop Cloning the Whole History
A full clone can dominate a short pipeline. Shallow clones ( –depth=1) skip history, blobless clones ( –filter=blob:none) fetch file contents on demand, and sparse checkout materializes only the modules a job builds.
The caveat: A shallow clone has no merge base, so diffs against the target branch fail, and change detection and test selection usually need that diff. Fetch enough depth to reach the merge base, or use a blobless clone.
2. Cache Dependencies, and Scope the Cache
Key the cache on a hash of lockfiles plus OS and toolchain version, never the commit. Add a prefix fallback so a near match still restores most files. Let trunk builds save and pull request builds restore read-only. Object storage suits ephemeral runners but pays a download-and-unpack cost on every job; a mounted volume is nearly instant but ties state to a machine and needs pruning. Either way, set a time-to-live and a size cap with leastrecently-used eviction, and watch the hit rate.
The caveat: An unscoped cache is an attack surface. If untrusted pull-request code can write a cache that trunk or release jobs later restore, one poisoned entry reaches your builds. Keep release builds off shared caches, or verify them.
3. Order the Dockerfile for the Cache
A layer is reused only if its instruction, its inputs and every layer before it are unchanged. So order instructions from least to most frequently changed: copy dependency manifests, install, then copy source and build. Use RUN –mount=type=cache to keep package downloads between builds, add a.dockerignore, and, because ephemeral runners start cold, share layers through a registry or blob storage with –cache-to and –cache-from.
The caveat: Placing COPY.. near the top of the Dockerfile defeats the cache. Any edited file in the monorepo invalidates that layer and everything after it, so dependencies reinstall on every build.
Copying manifests before source keeps the install layers reusable.
4. Run Only the Tests a Change Can Affect
Options run from cheap to sophisticated: the module dependency graph, call graphs, pertest coverage maps, and predictive models trained on history. Start with the build graph. It is deterministic, easy to explain, and fits a multi-module repo: a change in a leaf module runs its tests and its dependents’; a change in a core module fans out wide. Agents benefit too, since a small, relevant test set gives them a faster, clearer signal.
The caveat: Selection fails quietly. A stale coverage map or lagging history can skip a test that should have run, and one escaped regression ends trust. Build the safety nets first. Run the full suite when build files or CI configuration change, or when the selector errors. Always run new and changed tests. Run everything on merge to trunk and on a schedule. Finally, count escaped defects, meaning the failures that full runs catch and selection missed.
5. Quarantine Flaky Tests, Don’t Retry Them Into Silence
Flaky tests turn red builds into noise and trigger reruns that burn compute. Atlassian has reported flaky tests behind as much as 21% of master build failures in one large repository. Detect flakiness from pass-fail flips across runs, move offenders to a nonblocking lane where they keep running, give each an owner and a deadline, and release them after a sustained clean streak.
The caveat: Blanket retries are tempting, but rerunning until green hides the signal, and Google has described how retry-until-pass encourages developers to ignore flakiness. If you retry, record every pass-on-retry as a flake.
Measure Speed and Reliability Together
Track time to first signal, cache hit rate, work avoided (tests skipped, layers reused, and minutes saved), and cost per merged change. Pair each of these with a reliability measure: flaky rate, quarantine size, and escaped defects. A faster pipeline that lets more defects through has only moved the cost. Prefer hit rate and work avoided over raw build duration, because duration cannot distinguish removed work from bigger machines.
Start by measuring. Next, take the cheap wins in order (checkout, dependency cache, and layer order), and add selection and quarantine once your safety nets exist. Small, measured changes beat rewrites, and they give developers and coding agents the same thing: fast feedback they can trust.
Conclusion
Agents have made code cheap to write, so the pipeline is now the bottleneck. Lighter checkouts, scoped caches, cache-friendly images, selective tests, and quarantined flaky tests each remove repeated work, and each comes with a caveat that protects trust. Apply them one at a time, measure speed and reliability together, and your developers and agents will get faster feedback at lower cost.
Hemanth Mantri is a Principal Engineer at Harness in Mountain View, California, where he leads development of a managed Software Factory for DevSecOps in the agentic coding era. His work centers on intelligent CI as a service, including Cache Intelligence, Build Intelligence, and Test Intelligence, which help engineering teams and AI agents ship secure software faster by cutting build times and running only the tests and checks that matter. Before Harness, Hemanth spent nine years at Nutanix.