Build = commodity (near-instant for agents)

When build time is a commodity, it has ceased to be a meaningful variable in agent throughput calculations. Builds complete in 5-15 seconds for any change, consistently, regardless of codebase size or concurrent agent load. Agents don't plan their work around build constraints, don't batch changes to minimize CI runs, and don't experience wait states caused by the build system. Build time has been reduced to a fixed, negligible overhead - like network latency for an API call.

This is the L5 state, and reaching it requires the full stack of build infrastructure working together: hermetic incremental builds (Bazel or Buck2), distributed remote execution (EngFlow or BuildBuddy), a mature remote cache with 95%+ hit rates, fine-grained crate or module architecture that limits recompilation scope, disk I/O optimized for concurrent agent workloads, and agent-specific build profiles that skip irrelevant steps. No single intervention achieves commodity build speed - it's the compounding of all of them.

The business implication of commodity build speed is profound. When build time is no longer a variable, agent throughput is bounded only by the agent's reasoning speed and the rate at which humans can review outputs. The organization can scale agent count without scaling build infrastructure proportionally - the remote cache absorbs most of the additional load. A team moving from 20 to 200 parallel agents sees near-linear throughput scaling rather than infrastructure-limited throughput scaling.

Commodity build speed also changes how engineers think about the codebase. When any change can be compiled and tested in 15 seconds, refactoring, experimentation, and exploratory development become low-cost activities. Engineers (and agents) make more frequent, smaller changes rather than batching large changes to amortize build time. This behavioral change has quality benefits: smaller changes are easier to review, easier to revert, and produce more informative CI feedback.

• Agent throughput becomes purely reasoning-limited - build infrastructure no longer caps how fast agents can iterate; the ceiling is now the quality of agent reasoning and the speed of human review
• Linear agent scaling becomes possible - adding more agents adds proportionally more throughput; without commodity builds, adding agents adds disproportionately more build load
• Developers stop thinking about build time - when any change takes 10 seconds to build, the concept of "optimizing to minimize builds" disappears; developers and agents work at their natural pace
• Exploratory development becomes viable for agents - agents can try 10 different approaches to a problem and validate each one in 2 minutes total, rather than one approach per 20-minute iteration
• The organization's AI investment pays maximum return - the LLM inference cost is fixed; reducing build overhead means more of the total cost goes to productive reasoning rather than waiting

1. Audit your current build time distribution - Before declaring commodity status, measure p50, p95, and p99 build times for agent iteration builds. Commodity status requires p99 under 30 seconds. If p99 is higher, identify what's causing the tail.
2. Verify the full stack is in place - Commodity builds require all L3 and L4 infrastructure: Bazel/Buck2 with BUILD files, remote execution with a sufficiently sized cluster, 95%+ cache hit rates, agent-specific build profiles, and fine-grained module architecture. If any layer is missing, address it first.
3. Validate under concurrent agent load - Test commodity build performance when 20, 50, and 100 agents are building simultaneously. Build time should remain flat or degrade gracefully. If p95 build time doubles under concurrent load, the remote execution cluster needs more capacity or the cache tier needs optimization.
4. Eliminate the remaining tail causes - At p99, tail events are typically: large target rebuilds from proto changes, cache evictions forcing cold builds, or network congestion in the remote execution path. Each requires specific mitigation. Document each tail cause and its mitigation as an operational runbook.
5. Implement continuous build performance monitoring - Deploy a synthetic monitor that builds a representative set of targets every 10 minutes and reports p50/p95/p99 latency. Alert when p95 exceeds 30 seconds. Treat build performance degradation as a production incident.
6. Declare and communicate commodity status - Once p99 is consistently under 30 seconds for 30 days, formally declare commodity build status. Communicate it to the development team with the implication: "you no longer need to batch changes or optimize for build frequency - build whenever you want." This behavioral permission is as important as the infrastructure achievement.

Declaring commodity status based on averages. A 10-second average build time with occasional 5-minute outliers is not commodity status - the outliers are what agents and developers experience as friction. Track p99, not p50. Commodity status requires the tail to be as fast as the median.

Not maintaining commodity status under growth. A codebase that doubles in size, a team that triples its agent count, or a remote execution cluster that isn't kept scaled for current load will drift back from commodity status. Assign a quarterly "build performance review" as ongoing infrastructure maintenance.

Confusing agent-profile build time with full-pipeline build time. If your 10-second build time is an agent-profile build (compilation + unit tests only), and the full pre-merge pipeline takes 15 minutes, you haven't achieved commodity status for the full development workflow. Commodity applies to the full loop: iteration is fast AND pre-merge validation is fast enough not to be a bottleneck (target: under 5 minutes for full pre-merge).

Letting BUILD file quality degrade. Commodity builds depend on fine-grained, correct BUILD files. As the codebase grows and teams add new targets, BUILD file quality degrades: targets get larger, dependencies get sloppier, hermetic violations accumulate. BUILD file review must be as rigorous as code review. One poorly-structured BUILD target with 200 files can erode commodity status for an entire module.

Ignoring the disk I/O dimension. Commodity build times require the full disk I/O optimization described in the companion guide. Remote execution doesn't eliminate all local disk operations - source file reads, artifact staging, and workspace setup all involve local I/O. Concurrent agents doing I/O-heavy operations on a shared filesystem can still produce tail latency spikes even with excellent remote execution.