Software builds are slow, and teams run them all day: every change, every test, every release. So builds use a cache. When a piece of work has not changed since last time, the build reuses the stored result instead of doing the work again. When that works, a build takes minutes instead of hours.
Often, the cache is quietly not working as well as it could. One small mistake in the build's configuration makes the build believe its work has changed when it has not. The stored results for that work are never reused, and it runs again from scratch, every time. Nothing fails and nothing looks wrong. But your developers and AI agents are waiting, and your CI bill pays for avoidable work.
Ask an AI agent why your builds keep redoing work instead of reusing it, and it answers quickly:
Your build stamps the current time into one of the files it produces. That makes every build look different from the last, so earlier work is never reused. Stop stamping the time, and the reuse comes back!
Ask again, and you may get this instead:
Two steps of your build write their results into the same place. The build cannot tell whose results they are, so it trusts nothing and redoes both. Separate the two, and the reuse comes back!
Both answers are confident. Both sound like an expert who has studied your build. Only one of them is real: an actual defect, taken from one of the projects we used for our benchmark. The other is a plausible guess that would cost a day of scarce engineering time and change nothing.
Which one is real? And can you prove it? The agent that wrote them cannot. The evidence it would need is not in the code, and not in the build logs.
We measured how often the confident answer is the real one. Working from the repository and the build logs, a frontier model got it right in 4 runs out of 40. The same model, on the same problems, with real build data: 36 out of 40. 1 run in 10 becomes 9 runs in 10.
That gap is the case for Develocity. Models commoditize: the frontier moves every few months, and today's state of the art is tomorrow's baseline. Context does not. The build data and the encoded engineering expertise behind an agent are what make it better than the same model working alone.
Every AI vendor says their agent is better. Almost none of them show you how they know. Here is how we know.
Build caching is simple in principle. If a task's inputs have not changed, reuse last time's output instead of running the task again.
In practice, the cache key comes from what a task declares as its inputs. One volatile timestamp or one absolute file path in that declaration makes the task run again on every build. The task looks correctly configured. It just never hits the cache.
An organization in that state pays three times over. It pays for the acceleration platform it bought, for the continuous integration (CI) compute the cache was meant to save, and it pays in waiting time. Developers wait. AI agents wait too, because the build is the first thing that checks their work.
Finding which miss matters, and why, is build-engineering work. It needs rare specialists, and they do not scale to hundreds of repositories.
Fixing avoidable cache misses improves three things.
- Compute efficiency. Every fix cuts paid CI minutes on every later build of that project. The work is bought once and the saving repeats for as long as the fix stays in place.
- Developer productivity. Shorter waits keep people on their own work. And the central build team stops being every other team's caching bottleneck.
- Agent throughput. The build is the first check on an AI agent's change. Faster, more reliable builds mean more merge-ready changes per agent.
Agent throughput is new, and it is changing fastest. AI agents drive build volume up, so the same avoidable work now runs far more often than it did a year ago. Waste that was tolerable at human commit rates isn't tolerable at agent commit rates.
Build Caching Optimizer is one of the Develocity Agents. It is an agent skill that runs inside the AI agents you already use, such as Claude and Codex. There is no new vendor in the loop, and no new copy of your code anywhere. The agent runs on your side, reads from the build data you already have, and hands you a pull request.
It finds why a cacheable task missed the cache, then applies the smallest change that removes the cause. It re-runs the build to verify the fix. The Build Caching Optimizer is generally available for Gradle and Maven with Develocity 2026.2.
We wanted to isolate one thing: what does build data plus encoded build-engineering expertise add on top of a strong model?
So we ran a head-to-head with two setups, and changed one variable between them.
- Commodity AI. A frontier model given the repository and the build logs, then asked to fix the caching problem. This is the setup without Develocity.
- Build Caching Optimizer. The same model, with two additions. First, Build Scan data through the Develocity MCP Server (Model Context Protocol, the standard that connects AI agents to data). Second, a decade of build-engineering expertise encoded in the agent skill as a Gradle and Maven caching playbook.
Both setups ran the same model on the same problems. The only difference was context.
This is a product benchmark. We ran it on July 1, 2026, against Develocity 2026.2.0, and we disclose enough that you can judge it and understand its methodology.
- Model. Claude Opus 4.8 at high thinking effort, the strongest model available at the time, identical on both sides.
- Projects. Four real open-source projects: Apache Ratis on Maven, Twitch4J, Micrometer, and Caffeine. We seeded each one with known cache defects, the kind these builds hit in practice. That gives every scenario a correct answer to grade against.
- Runs. Each setup ran every project 10 times, for 40 runs each.
- Budget. A ceiling of 10 million tokens per run. A run that hit the ceiling without answering counts as a failure.
- Grading. Three checks, averaged. How close the diagnosis came to an expert answer. How close the code change came to a reference fix, mostly the fix these projects really shipped. And the cache hit rate improvement on a real build. A judge model grades the first two. The third is measured.
- Solved. A run counts as solved at 70% correctness or better. A project counts as solved when a majority of its 10 runs are solved.
Together, the last two checks make the result hard to game. The measured hit rate catches a fix that does not actually work. The code-change check catches the opposite trick: raising the hit rate by quietly deleting a task's inputs.
Working from build logs, commodity AI solved 4 of 40 runs. A 10% success rate.
On the same model, with build data and the caching skill, Build Caching Optimizer solved 36 of 40. A 90% success rate.
10% against 90%, on the same model. Nothing separated the two setups except access to the build data behind the cache miss and build-engineering expertise to make the most out of that data.
At the project level, that is 0 of 4 projects against 4 of 4. Average correctness rose from 30.1% to 80.3%.
| Project | Commodity AI | Build Caching Optimizer |
|---|---|---|
| Apache Ratis (Maven) | 22% ± 8 | 94% ± 3 |
| Twitch4J | 23% ± 2 | 76% ± 3 |
| Micrometer | 35% ± 12 | 81% ± 4 |
| Caffeine | 41% ± 16 | 71% ± 2 |
Average correctness across the runs that returned an answer. A run that hit the token ceiling produced nothing to score, so it counts as a failure but not as a zero.
The interesting part is consistency, not raw capability. Commodity AI was correct sometimes: three runs on Caffeine, one on Micrometer. It was never repeatably correct.
Look at the spread on Caffeine, 41% ± 16 against 71% ± 2. One of those is a tool you can rely on. The other is a lottery ticket, and without build data you can't tell which run you drew.
This is not a model-quality gap. They are the same model, at the same settings, on the same repositories. The gap is in what each one can see.
A build log tells you that a cacheable task ran instead of reusing its result. It doesn't tell you why. The cause is a difference between two builds, and a log records only one.
Take the Twitch4J case, which carried four separate defects at once. Let's look at two of them to show why logs are not enough. The first is the real answer from the top of this post: a plugin stamped a build timestamp into a packaged file, and that file sat among the inputs of a documentation task. A new timestamp on every build means a new cache key on every build.
Behind it sat a second defect. An absolute file path in the same task's configuration made its result impossible to reuse anywhere else. A result cached by one CI machine cannot be reused by the next.
That second defect stays hidden while the first one is there. To expose it you run the same build from two different locations and compare the two Build Scan records to see exactly which input moved.
Nothing stops a capable model from doing that, and the commodity prompt told it to run real builds and measure before and after. Two things stand in the way, and neither is reasoning ability.
The first is knowing that this is the experiment to run at all. Knowing to relocate a build to expose a path-dependent input is build-engineering knowledge, not a general AI insight, and it is exactly what the playbook encodes. The second is that even a model that runs the experiment has to read the answer off a log. A log does not record the exact inputs a task used to build its cache key. Build Scan data does.
On Apache Ratis, 7 of 10 commodity runs used the entire 10-million-token budget and still returned no answer. The constraint was never effort. It was the data.
And a correct first answer still leaves the harder question open: is that all of them? Compare that with a failing build. A red build is a signal the agent did not have to construct. Cache health is a signal it has to construct: build once to populate the cache, build again, compare the two. The agent can iterate against that, and it will, until every cacheable task reports a hit.
But that signal is only as good as the experiment behind it. Run both builds from the same directory and a relocation defect stays invisible, because in that experiment the task does hit the cache. The agent gets its green light from a comparison that was never able to show the problem, so it reports success and stops.
As far as we know, no vendor in this space has published a head-to-head like this one. We can, because the result held across all four projects.
We will re-run the benchmark when model capability takes a visible step up. We don't expect a stronger model to close the gap on its own, because the commodity setup is missing the data, not the reasoning. The causes of these misses are not in the source tree at all.
A broader suite, covering more of the Develocity Agents and more projects, comes next.
Your agent is not the limit here. What it can see is. Develocity is the difference between 4 of 40 and 36 of 40.
Most cache misses are not as tangled as the Twitch4J case. The usual causes are ordinary: a volatile input, an absolute path, an overlapping output. The cost is the same, because everything downstream runs again. And finding them still takes build-engineering expertise that most teams cannot spare.
Build Caching Optimizer is the Develocity Agent for fast builds. It finds the most impactful avoidable cache misses in your builds and root-causes each one against the real build inputs. Then it directs the AI agents you already run to apply a minimum-change fix, re-validate it against a fresh build, and open a pull request. Every finding cites the Build Scan data behind it.
