Capability 03 of 04 · Infrastructure
Build System
Build tooling optimized for agent-scale throughput - caching, incrementality, and speed.
5
maturity levels
15
practices
15
guides
L1 · Stage 01Assisted
Practices - what it looks like3 guides
- Maven/Gradle default configMaven and Gradle ship with sensible defaults for single-developer, sequential workflows.guide→
- Full rebuild on every changeA full rebuild recompiles every source file and re-runs every build step from scratch on each invocation, regardless of what changed.guide→
- Each build recomputes the full graph from source, on every machineBuilds share nothing: every developer's machine and every CI run recomputes the same artifacts from source, over and over, because each cache dies with the process that produced it.guide→
Criteria - what to measure
- 01A build system is in place (default configuration is fine)
- 02Builds run on each change
- 03Build completes (even if slowly)
- 04CI runs builds on a shared queue (even if everyone waits)
L2 · Stage 02Delegated
Practices - what it looks like3 guides
- Basic build caching; packages an agent installs from docs or llms.txt are verified against a registry allowlist first (237 of 8,565 llms.txt files pointed at dead, typo'd or unregistered packages)Basic build caching stores the outputs of build steps and reuses them when the inputs haven't changed, and packages an agent installs from docs or llms.txt are checked against a registry allowlist before they enter the cache.guide→
- Parallel build stepsParallel build steps execute independent stages of the build and test pipeline concurrently rather than sequentially.guide→
- The build cache is shared between developers and CI, not rebuilt per machineOne build cache serves everybody: an artifact computed once - on a developer's laptop or on a CI runner - is reused by every later build that needs it, instead of being recomputed per machine.guide→
Criteria - what to measure
- 01Build caching is implemented (dependency cache, compilation cache)
- 02Parallel build steps are configured (test and lint run concurrently)
- 03The build cache is shared between developers and CI rather than rebuilt per machine
- 04Cache hit rate exceeds 60%
- 05Build time has improved by at least 30% compared to uncached baseline
L3 · Stage 03Systematic
Practices - what it looks like3 guides
- Incremental builds: only changed targetsIncremental builds with only changed targets rebuild exactly and only the build targets that depend on files that have changed since the last build.guide→
- Remote execution distributing build steps across machinesRemote execution distributes build actions across a cluster of machines rather than running them locally.guide→
- A build tool with an explicit dependency graph and a shared cache (Bazel, Buck2, Pants, Nx, Turborepo)Bazel, Buck2, and Pants are hermetic build systems originally developed by Google, Meta, and Toolchain respectively to handle the scale and correctness requirements of massive monorepos.guide→
Criteria - what to measure
- 01Incremental builds run only changed targets (not full rebuild)
- 02Remote execution distributes build steps across multiple machines
- 03The main codebase uses a build tool with an explicit dependency graph and a shared cache (Bazel, Buck2, Pants, Nx, Turborepo or equivalent)
- 04BUILD file maintenance is assigned to specific team members or automated
- 05Remote cache hit rate exceeds 80%
L4 · Stage 04GovernedMost teams aim here
Practices - what it looks like3 guides
- Agent-specific build profiles; multi-root workspaces and worktree isolation per agent, now shipped as a default by agents themselves rather than assembled by handAgent-specific build profiles are lightweight build configurations optimized for the agent iteration use case rather than the human pre-merge or release use case, and they now have to assume every agent is building in its own git worktree.guide→
- Build system aware of agent iteration patternsA build system aware of agent iteration patterns goes beyond passive responsiveness - it actively anticipates what agents will need to build next and prepares accordingly.guide→
- Sub-2min feedback on any changeSub-2-minute feedback means that for any change an agent or developer makes to the codebase, the signal "this compiles and the relevant tests pass" arrives within 120 seconds.guide→
Criteria - what to measure
- 01Agent-specific build profiles exist (optimized for agent iteration patterns - fast feedback over comprehensive build)
- 02Build system understands agent iteration patterns and pre-caches likely next builds
- 03Any change gets build feedback in under 2 minutes
- 04Build profiles are auto-selected based on invoker (agent vs. human vs. CI)
- 05Pre-caching hit rate exceeds 70% for agent iterations
L5 · Stage 05Self-improving
Practices - what it looks like3 guides
- Build = commodity (near-instant for agents)When build time is a commodity, it has ceased to be a meaningful variable in agent throughput calculations.guide→
- Compilation bottleneck eliminated via crate/module architecture (the Bun lesson: a conformance test suite makes even a runtime rewrite verifiable)Compilation bottleneck elimination through crate/module architecture means restructuring a codebase so that the unit of compilation is small, focused, and independently compilable.guide→
- Disk I/O optimized for concurrent agent workloads (Cursor lesson)Disk I/O is the hidden bottleneck when running hundreds of concurrent agents on a shared infrastructure.guide→
Criteria - what to measure
- 01Build is a commodity: near-instant feedback for agents regardless of codebase size
- 02Codebase is structured into self-contained modules to eliminate the compilation bottleneck
- 03Disk I/O is optimized for concurrent agent workloads (parallel reads/writes across modules)
- 04Build latency is under 30 seconds for 90%+ of changes
- 05Module dependency graph is automatically maintained and optimized
From the Field
Recent releases, projects and discussions the AI Radar classified into this capability.
Which level is your team at in Build System?
The criteria above are what we check in a facilitated assessment. Run it yourself to place this capability, see which gates you have passed, and compare it against the other 3 in Infrastructure.
Start the assessment →