Bazel's time has come
With regard to builds, a cohort of companies using agents are leaping across the Bazel ROI boundary.
The way that software companies tend to grow and evolve is that they start out with a few people mostly using ecosystem-default tools for everything, including their build system. New projects are small so all their builds are pretty quick so the build system is not much of a concern. There is no time to think about builds, anyway; the company needs to make money to survive and no one makes money from their build system.
As the company grows and the software grows the builds get a little slower, but they still only take a few minutes on the developers’ macbooks. This is a pretty tolerable situation, although the cumulative number of build-minutes gets large when you factor in testing and releases. As build times grow past the ten-minute mark people will complain louder, but lots of software companies stay in this stage forever.
If the company grows even further, there comes a critical point where build latency and other build system problems become the primary rate limiter of productivity. Experiences vary, but my sense is that this normally happens in the ‘hundreds of SWEs’ range. At this point, conditions are ripe for a change:
- Builds are making engineers both unproductive and unhappy
- Builds are consuming lots of compute (money) and time (money) so the issue is legible to the company
- The company is (likely) already paying full-time DevOps, SREs, or other personnel nominally responsible for build optimization so there is a place for this responsibility to land
One way to significantly improve build speed and economy at scale is to switch to a build system that is reproducible and therefore capable of extensively caching intermediate build artifacts. In a large organization where people are constantly building the same core systems with minor peripheral changes, the ability to cache intermediate artifacts can massively reduce duplicate work.
One system that works this way is Bazel, an externalized version of Google’s build system.
Despite being open-sourced in 2015, Bazel adoption has been limited outside of Google. While usability may be one factor (industry reviews are mixed), it seems to me that the adoption funnel for tools like Bazel is just very narrow: a company must grow to a point where the solutions Bazel offers justify the adoption cost and then make the commitment to migrate to it. The relative lack of a thriving Google-external Bazel community then becomes a self-reinforcing problem.
Except! We are now about six months into widespread industry adoption of coding agents. As I write this in June 2026, the current hot topic is agent sandboxes and the next one up looks to be cloud-based agents.
Companies adopting these tools aggressively will see their build-minutes grow by 5-10x in months, turbocharging the associated frictions. A company that started the year with 50 SWEs may have the build issues of a company with 500 come Thanksgiving. With a surge in the need for more efficient, distributed builds, Bazel may finally get its due.