Build = commodity (near-instant for agents)

When build time is a commodity, it has ceased to be a meaningful variable in agent throughput calculations.

·Build is a commodity: near-instant feedback for agents regardless of codebase size
·Codebase is structured into self-contained modules/crates to eliminate compilation bottleneck (Cursor lesson)
·Disk I/O is optimized for concurrent agent workloads (parallel reads/writes across modules)

·Build latency is under 30 seconds for 90%+ of changes
·Module dependency graph is automatically maintained and optimized

Evidence

·Build duration dashboard showing near-instant feedback for standard changes
·Codebase architecture showing modular structure (crate/module boundaries)
·Disk I/O benchmarks for concurrent agent build workloads

What It Is

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.

Why It Matters

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

Getting Started

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.
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.
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.
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.
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.
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.

Tip

The test for commodity build status is the "fearless refactor" test. Ask agents and developers: do you ever choose NOT to make a change because of anticipated build time? If the answer is ever "yes," you have not achieved commodity status. Commodity status is when the answer is universally "no - I just make the change."

6 steps to get from here to the next level

Common Pitfalls

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.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob's team has been on the L4/L5 build journey for 18 months. Build times are consistently fast for most work, but he occasionally hears complaints about slow builds when teams work on shared infrastructure. He's asked whether the team has truly achieved "commodity" status.

What Bob should do: Bob should commission a 30-day build performance audit that tracks p50, p95, and p99 build times for agent iteration builds, segmented by target area. The audit should identify whether the tail events are randomly distributed or consistently concentrated in specific areas of the codebase. If they're concentrated - say, proto changes and base library changes account for 80% of tail events - those specific areas need targeted investment (fine-grained proto structure, stable/volatile library splitting). Bob should set a formal commodity status criterion: "p99 agent iteration build time under 30 seconds for 30 consecutive days" and track it monthly. When that criterion is met and sustained, formally declare commodity status and redirect the infrastructure investment to the next bottleneck.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah's DevEx metrics show that "build time" has dropped out of the top 5 developer friction points for the first time. It's been replaced by "PR review turnaround" and "context switching between agent sessions." This is exactly the productivity evolution she was targeting - build infrastructure has been solved, and new, higher-level friction points have surfaced.

What Sarah should do: Sarah should document the build journey as a case study: what investments were made, in what order, over what timeline, and what the measurable outcomes were at each stage. This documentation serves two purposes: it justifies the infrastructure investment to leadership, and it provides a roadmap for other teams in the organization that are at earlier maturity levels. Sarah should also redirect her optimization focus to the new top friction points - PR review turnaround and agent session context switching are now the limiting factors on agent productivity, and they're both addressable with process and tooling investments at L4/L5.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor's build infrastructure is running at what he considers commodity status: p99 under 15 seconds, flat scaling up to 30 concurrent agents, 97% cache hit rate. He's run out of obvious build optimizations and is now focused on the next frontier: making agent sessions themselves more efficient, since build time is no longer the constraint.

What Victor should do: Victor should document the full technical architecture of the build infrastructure as a reference implementation. The architecture document should cover: Bazel BUILD file conventions, remote execution cluster configuration, cache tier design, agent build profile definitions, disk I/O optimization choices, and the monitoring stack. This document should be detailed enough that any senior engineer could replicate it from scratch. Victor should also contribute to the open-source Bazel ecosystem: the configurations, tools, and learnings from achieving commodity build status at this scale are valuable to the broader community, and open-source contributions build Victor's reputation as a technical leader in this space.

What Victor should do - role-specific action plan