Written for Engineering leadership feeling the throughput squeeze.
The argument
Verification is the constraint now, not generation
For as long as software has been an industry, output scaled with headcount. Hire more engineers, ship more code, and the work of validating that code grew at roughly the same rate, because the same people did both. That coupling is what made capacity planning possible.
Agents broke it. One engineer with a capable agent produces several times their previous volume of change, and the multiple keeps moving. The generation side of the pipeline became elastic almost overnight; everything downstream stayed exactly as elastic as it was before.
What you get is a queue, and not a metaphorical one: a literal backlog of changes waiting to be built, tested and reviewed, growing at the rate the agents produce and draining at the rate the build system allows.
- Any plan that only makes generation faster makes the constraint worse. If your build and test loop is unchanged from eighteen months ago, the ceiling on your engineering throughput is now set by your CI, not by your engineers.
- The verification loop was designed for humans reading text. An agent that fails a build gets a log. It can’t reliably tell what broke, so it retries blindly or escalates to a human.
- The economics have to hold. Verifying several times more change at the same unit cost is a budget problem before it is an engineering one.
Why the bill grows faster than the change count
If verification cost scaled linearly with the number of changes, this would be a budgeting exercise. It doesn’t, for four compounding reasons.
None of these are new. What is new is that agent adoption pushes all four at once, and they multiply rather than add. You can’t buy your way out with a bigger CI fleet alone: linear compute against superlinear demand loses. What changes the curve is not running the work faster. It is not running work you have already proven.
Make the build legible to machines
Discoverability solves what to run. The harder half is what happened.
Every monorepo grows the same sediment of scripts: undiscoverable, undocumented and subtly different in every repo. The Aspect CLI replaces that with a task surface a machine can enumerate, so “what can I run here?” has an answer that doesn’t depend on tribal knowledge.
Then the results. When a build fails, an agent needs to know which target failed, why, what the cache did, and whether this has happened before. A log answers none of those reliably. It is prose, written for a person, with the important line somewhere in the middle of forty thousand others. So the same data the UI shows is available over HTTP, and as tools an agent calls directly.
Take the work out of the loop entirely
Making verification legible is necessary. Making less of it happen is better.
- Never verify the same thing twice. A cache shared across CI and every developer machine means an action executed anywhere is not executed again. As change volume rises, the proportion of work that is genuinely novel falls.
- Only verify what the change affects. Bazel’s dependency graph already knows which targets a change can possibly affect. Testing that set is the difference between a cost that tracks the size of the change and one that tracks the size of the repository.
- Then spread what is left. Remote execution runs the remaining actions across a fleet, so the wall-clock cost of verification stops being a function of the developer’s laptop.
You need both halves. Cutting the work without cutting the wait leaves developers waiting; cutting the wait without cutting the work leaves you paying for a bigger fleet every quarter.
The stack behind this has been architected and sized for monorepo workloads at these volumes. At a 92.8% hit rate, thirteen of every fourteen actions are not executed at all. That is the mechanism that makes agent-scale change volume affordable.
Three things to do this quarter
- Measure your verification cost per change, not per build. If you can’t, that’s the first finding.
- Find out what fraction of your CI compute is re-execution. Cache hit rate answers this directly, and most teams have never looked.
- Point one repository at a hosted instance and give an agent the API. The question is not whether it is faster. It is whether the agent stops needing a human to read the log.
Where it runs
Three ways to run this, and the axis that separates them is isolation, not hosting.
| Option | Infrastructure | Cloud account | Operated by |
|---|---|---|---|
| Aspect Cloud | Shared, scoped to your organization | Aspect’s | Aspect |
| Aspect Enterprise, hosted by Aspect | Isolated, yours alone | Aspect’s | Aspect |
| Aspect Enterprise, self-hosted | Isolated, in your account | Yours | Aspect, or your team |
The last two are the same product, Aspect Enterprise. What differs is whose account it runs in and who holds operational control. Holding that control yourself is usually the point. Plenty of teams in finance, healthcare and government are not allowed to give a third party production access. For them we work over the shoulder: we guide and diagnose, their hands stay on the controls. It is what makes air-gapped and GovCloud deployments possible at all.