CI Build Speed in the Agent Era: What Teams Actually See

On 25 October 2026, an Ask HN thread asked a question many teams are quietly wrestling with: as AI agents push more commits, how fast is your CI? The thread got only three comments, but the question is worth answering properly, so here is what the data and the best public case studies say about CI build speed.

Key takeaways

• The original Ask HN post claims agent-driven development is pushing CI costs up, but gives no data. One reply is the only concrete datapoint.
• CircleCI’s benchmark target for a workflow is 5 to 10 minutes. Its 2024 report found an average of 2m 49s.
• Cash App cut its median build from 30 to 10 minutes with caching, modularization and smarter sharding.
• Remote caching is the biggest single lever, but only if your cache inputs are complete.

What did the Ask HN thread actually say?

The poster, easterncalculus, wrote that with the age of agents CI costs are going up, and asked how people optimized and how fast their builds are. At the time of reading, the post had 3 points and 3 comments.

The one detailed answer came from a commenter named verdverm, who runs a large monorepo. Their setup runs a review agent on any commit with an open pull request that has already passed the build. The reviewer uses open-weight models, or at least a different model family from the one that wrote the code.

By their napkin math, an average review costs under $1. That is cheaper than their most rigorous CI validation step, which needs a GPU for up to an hour. Reviews take roughly 10 to 15 minutes, and they blamed a scheduling bug in Argo for some of the delay. Humans still check the review on their own schedule.

That is a useful reframing. In an agent workflow, the expensive part of CI may not be the compute minutes. It may be the specialized steps, like GPU tests, that run on every change.

How fast should CI be?

The most cited yardstick is CircleCI’s 2024 State of Software Delivery report, published on 16 April 2024 using data from September 2023. It sets a maximum benchmark of 10 minutes for a workflow, and found an average of 2 minutes 49 seconds across all branches, 13% faster than the year before.

The same report found a main-branch success rate of 82.5% against a recommended 90%, and an average recovery time of 57m 33s, the first time teams beat the 60-minute target. It also warns that short pipelines can hide thin test coverage or manual work outside the pipeline. Fast is good, but fast and empty is not.

I could not find a 2025 or 2026 edition of these numbers, so treat them as a baseline, not a measure of the agent era. That gap is exactly why the HN question was interesting.

What cut a 30-minute build to 10?

The best public worked example is Cash App’s write-up of taming its monolith, published on 12 October 2023. Its median (p50) build time fell from 30 to 10 minutes, and the p99, the slowest 1% of builds, fell from 45 to 22 minutes.

The gains came from a list of unglamorous changes:

• Gradle remote build cache: unchanged modules are reused, so a pull request only rebuilds what it touched.
• Modularization: splitting one huge module meant a tiny edit no longer rebuilt everything.
• Deleting dead code and its tests.
• Eager test workers: database and dependency setup starts during compilation.
• Off-path checks: security and quality steps run in parallel, away from the critical path.
• Timing-based sharding: tests are split by past duration so shards finish together.
• A better CI platform: fewer spot-instance interruptions and shorter queues.

Notice that none of these is “buy bigger machines.” Most are about doing less work, or doing it in parallel.

Does remote caching really help?

Yes, with caveats. Nx’s documentation explains why: CI machines are usually ephemeral, so every run starts cold, and a local cache helps only one machine. A remote cache shares results across machines and runs.

Nx reports 40 to 90% faster CI across its workspaces. That is a vendor figure, so read it as a ceiling, not a promise. The biggest wins come in repos with many projects where most pull requests touch a small slice.

The pitfalls are real. A cache is only correct if its hash covers every input, and a missing input produces stale results. Flaky tests can get cached as failures. And a change to a shared library invalidates everything that depends on it.

Why would agents make CI more expensive?

This part is my opinion, not a measured finding. Agents open more pull requests and push more fixup commits, and each push can trigger a full pipeline. More commits times the same pipeline means a bigger bill, even if no single build got slower.

If that holds, the fixes are the same as above, applied harder: cache aggressively, run only affected tasks, and gate expensive steps like GPU tests behind cheaper checks. verdverm’s pattern of running the review agent only after the build passes follows that same logic.

What happens next

verdverm said they plan to publish a write-up on their agent review setup, inspired by a Cloudflare post on the same topic. If it appears, it will be a rare piece of real data on agent-era CI. Until then, the honest answer to the HN question is that few teams publish their numbers.

Expect CI vendors to update their benchmark reports. For related reading on agents and tooling, see our pieces on cutting Claude Code context and capping your Vercel bill.

FAQ

What is a good CI build time?

CircleCI’s benchmark is a maximum of 10 minutes per workflow. Its 2024 report found an average of 2m 49s.

What is the fastest way to speed up CI?

Usually a remote build cache plus running only the tasks affected by a change. Cash App also gained from modularization and timing-based test sharding.

Do AI agents really raise CI costs?

The Ask HN poster says so, but no hard data was shared in the thread. The logic is plausible, since more commits trigger more pipelines.

Next step: pull your last 30 days of pipeline durations, find the slowest 10% of builds, and fix the biggest single step first.