P.1.1 Key Benefits

Most build systems force a trade-off between speed and correctness. Bazel's predecessor inside Google, Blaze, was created to make builds correct and fast.¹ Bazel brings that same promise to the open-source world. Its design — declaring what to produce rather than scripting how to produce it — enables five benefits that compound as a codebase grows. Each benefit here is a teaser. The mechanisms behind them are explored across the curriculum, starting with the foundational shift from tasks to artifacts in P.2.1 Task-Based vs Artifact-Based and the five defining properties of the Bazel model in P.2.4 Five Properties.

Correctness

Bazel is designed to make unchanged, correctly declared work safely reusable². On supported platforms, build actions can run in a filesystem sandbox, isolated from much of the host environment and limited to their declared inputs³. When an action is hermetic and its effective inputs have not changed, Bazel can trust and reuse the cached output instead of relying on a stale-file heuristic.

You shouldn't need to routinely run bazel clean. Many build workflows use a clean build as a conservative recovery step when incremental state is no longer trusted. In Bazel, needing to clean for a correct answer points to a misconfigured build or a Bazel bug^2,4.

The formal mechanism behind this is hermeticity. A build depends only on declared inputs, not on what happens to be installed on the machine. That also sets the limit of the guarantee: reproducibility is only as strong as the hermeticity behind it, so actions that read the clock, the network, or undeclared files can still vary. How Bazel enforces this through sandboxing is covered in 2.3 Hermeticity & Sandboxing.

Speed

Because Bazel knows an action's declared inputs and outputs, it can skip work whose action key is still valid. A small edit rebuilds the affected actions and their necessary dependents rather than blindly rerunning the whole pipeline. A warm build with no relevant changes is therefore usually much faster than the first build³.

Beyond incremental rebuilds, Bazel parallelizes independent actions across all available cores. When actions are sufficiently hermetic, their results can be cached locally, on a shared disk cache, or on a remote cache that the entire team shares.²

Outside Google, teams also report large improvements in CI time and incremental build speed after migrating to Bazel⁴.

The caching and incrementality model is explained in 2.4 Caching & Incrementality. Remote caching and remote execution, where build actions run on shared infrastructure rather than a developer's laptop, are covered in 6.2 Shared Remote Cache and 6.3 Remote Execution Infrastructure.

Scalability

Bazel was born inside Google's monorepo, which at the time of writing of the SWE at Google book contained more than two billion lines of code and processed tens of thousands of changes every day⁵. The design assumptions that make this possible include fine-grained dependency tracking, aggressive caching, and distributed execution. They work at any scale, but pay off most when the codebase is large enough that naive rebuilds become infeasible.

The payoff can appear long before "Google scale." Teams juggling multiple languages, shared libraries, and slow CI often start feeling the benefit as soon as the dependency graph becomes hard to coordinate with native tools.⁴

Polyglot by Design

Most build tools are tied to a single language ecosystem: cargo for Rust, go build for Go, Gradle for JVM projects. Bazel takes a different approach. Its core engine is language-agnostic by design. Bazel ships a small set of built-in rules, but language support is primarily delivered through rulesets, external packages that teach Bazel how to compile, link, and test for a specific ecosystem⁶.

This means a single Bazel repository can build a Go backend, a React frontend, a Python ML pipeline, and a Rust infrastructure tool, all with one build system and one dependency graph. Cross-language dependencies, like a Java service consuming code generated from Protocol Buffers definitions, are first-class citizens rather than afterthoughts⁶.

The split between Bazel Core and rulesets is explained in P.2.3 Core vs Rulesets.

Uniform Interface

The polyglot architecture creates a uniform command-line interface. bazel build compiles code, bazel test runs tests, and bazel run executes a binary regardless of whether the target is Java, Python, Go, or Rust.

This uniformity propagates through the development workflow. CI can use a shared top-level command such as bazel test //... instead of inventing one entry point per language⁶. When rulesets and toolchains model their tools correctly, a backend engineer debugging a frontend dependency can use that same Bazel interface without manually orchestrating npm scripts or compiler steps. Repositories may still have host prerequisites, credentials, or platform setup. Bazel makes those requirements easier to centralize, not automatically nonexistent⁷.