3.5.2 Inner-Loop Build Delegation

Bazel is built for correctness across a whole repository, not for the sub-second edit–compile–test cycles that dominate a developer's inner loop. When sub-second iteration matters, some teams treat Bazel as the outer-loop system — authoritative for merges and CI — and delegate the inner loop to the IDE's own incremental compiler instead. This is not a Bazel feature. It is a deliberate decision to step outside Bazel for the minutes of the day when Bazel is not the right tool.¹

Why Bazel is a poor fit for the inner loop

Two structural properties of Bazel become a ceiling on interactive speed, especially in a large JVM or polyglot monorepo:¹

Per-invocation overhead. Every bazel build pays the cost of the loading and analysis phases from 2.2 Three Phases of a Build before any action runs. On a warm server the numbers are small, but they do not shrink to zero for a trivial one-line edit.

No incrementality within an action. Bazel's caching, covered in 2.4 Caching & Incrementality, operates at action granularity: if any input changes, the whole action reruns. When a source file inside a java_library changes, Bazel re-runs the compile action and javac starts the compile over — even though persistent workers keep the JVM warm, Bazel has no way to resume a compiler mid-flight and reuse its in-memory symbol table at method or symbol granularity. IDE compilers, by contrast, keep that state hot and recompile at method- or symbol-level granularity.

For single-digit-second or sub-second test iteration, these two costs are what "Bazel is too slow" often means in practice.¹ The delegation pattern below is a response to that measured latency, not a default replacement for Bazel's local build loop.

The delegation pattern

The pattern has a concrete form in a large (30M-line) JVM monorepo. It resembles the "fast builds" mode of the Bazel IntelliJ plugin (see 3.5.1 IDE Support for baseline plugin setup). However, the actual compilation step is delegated to IntelliJ's incremental compiler. In practice, this requires maintaining a fork of the Bazel plugin so the IDE compiles instead of Bazel.¹ The responsibilities are:

• IDE drives inner-loop compile/run/test. IntelliJ (or any IDE with a real incremental compiler) compiles only what changed, using its symbol graph, and surfaces errors and warnings live.
• Bazel drives the project model. The plugin tells the IDE which targets exist, which sources they own, and what their classpaths are. New dependencies, generated code, and renamed targets are invisible to the IDE until the project is synced back to Bazel.
• Bazel remains the source of truth for CI. Every merge still goes through bazel test //... under the CI recipe in 3.6 CI Basics. This is where 2.3 Hermeticity & Sandboxing and sandboxing provide their guarantees, while the remote caching setup in 6.2 Shared Remote Cache provides reusable results.

The reported payoff is large: up to 30× faster incremental builds, with 30-second builds compressing to roughly 1 second.¹

An IDE runs its own analyzer rather than invoking Bazel per edit for reasons of latency and feedback quality: asking Bazel to build a single file can invalidate several levels of dependencies and stall for minutes, whereas the IDE resolves direct dependencies at symbol granularity and builds an AST of your code that can also represent errors — so errors, warnings, inspections, and suggested improvements surface live.² Inner-loop delegation leans on that existing capability instead of fighting it.

Drift is the tax

The cost of this pattern is that two models of the project coexist, and they move apart whenever the build definition changes:¹

• New deps entries in a BUILD file are invisible until the IDE project is re-synced to Bazel.
• Generated code (protos, GraphQL bindings, stubs) must be produced by Bazel before the IDE can index it.
• The IDE's compiler flags, annotation-processing setup, and classpath order are not guaranteed to match Bazel's action. A green IDE can hide a red CI.
• Compute shifts onto developer laptops rather than RBE, so the pattern rewards the fastest available developer hardware.¹

Teams that use this pattern reduce the cost of drift by automating BUILD file updates when imports change, providing cross-repo symbol search, and relying on CI to catch whatever the IDE missed.¹ Without that investment, time saved by the 30× speedup can be lost to subtle "works on my machine" debugging.

When to reach for this

Inner-loop delegation is a niche pattern, worth knowing exists rather than adopting by default. It pays off most clearly when:

• The primary language has a mature in-IDE incremental compiler (JVM languages are the canonical case).
• Local iteration time, not CI time, is the dominant developer complaint.
• The team already has strong CI gates — otherwise drift leaks into production.

It is a poor fit when the IDE has no real incremental compiler of its own (Bazel C++ setups commonly rely on clangd plus a compile_commands.json, which is a language-server front end rather than a build tool), when generated code dominates the inner loop, or when tests require the hermetic environment to behave the same as in CI.