I spent 90% of my time at BazelCon talking to people in the hallway track. For some reason, I cannot stand watching the talks live unless I am deeply invested in the topics. I prefer watching them later, at home, under a blanket at 1 AM while YouTube cranks up the speed to 1.5x.

Here was the event’s official schedule:

• Tue, 13th: Training Day
• Wed, 14th: General Sessions
• Thu, 15th: General Sessions

And here was mine:

• Sun, 11th: coffee chat with folks
• Mon, 12th: coffee chat with more folks
• Tue, 13th: BuildBarn meetup at DataDog. Set up our sponsor booth. Team dinner.
• Wed, 14th: Talk to people. Happy hours.
• Thu, 15th: Talk to more people. Team dinner.
• Fri, 16th: Bazel Hackathon at DataDog. Team lunch.

And some BazelCon attendees wished the event was one day longer… I made mine three days longer, full of hallway conversation, and I loved it.

Delete Your Tests

Front and center of the hallway track was a discussion of the value of tests. This comes on the heels of some company reporting on Twitter that they had recently deleted all of their tests to save CI time. Anthropic also released a version-control blog post describing their investment in post-merge, pre-deploy testing.

“Redesigning source control at Anthropic”

A common observation among the folks I spoke to is that the latest generation of frontier coding agents is over-RLed with tests. A crap ton of unit tests gets added to each PR, just for the sake of having them. They are often set up with mocks and fakes and dupes, and will be refactored and updated in the next PR anyway. Basically, the agents are bad at identifying the scope at which the tests should be added. This, at scale, adds a lot more pressure on CI than necessary while making the diff harder to review and more expensive to maintain.

But on the other side of the coin, BazelCon engineers understand very well that you don’t go asking for only e2e tests either. These tests are expensive to run, and they rarely cache well between revisions. E2E tests are the last resort and should only be added for major functionality.

This means there exists a sweet spot somewhere between unit tests and e2e tests where the agents should be testing. Where that spot should be depends on the “Risk Tolerance” of the business. Tests can be thought of as insurance policies against future changes and breakages. The more risk you can tolerate, the fewer tests you need. The more assured you want your business to be, the more testing you do.

For example, at an e-commerce food delivery company, a bug that loses a few thousand orders might cost tens of thousands of dollars. For that particular failure, those tens of thousands of dollars are the value of your risk. But at an aircraft manufacturer or a surgical robot company, the risks are not simply calculated in dollars, but in human lives, which I think we can wholeheartedly agree are worth much more than tens of thousands of dollars. This means that these hardware manufacturers should be testing more, checking for flaws more often, and tolerating fewer failures in the final product.

Being at BazelCon means I am surrounded by folks, who not only can reason about these tradeoffs, but have also designed and rolled out such frameworks at scale, while being able to articulate them in layman's terms. I am constantly star strucked by the talent density here.

Folks also think that this will drive up the demand for mutation testing and property testing. Personally, I enjoy equipping my coding agents with a skill that prunes down the added tests guided by “bazel coverage” outputs. I have yet to find a good way to make it do branch coverage, but I suspect it will be much better once I have it set up after this conference.

Measure Your Tests

A surprising effect of coding agents is that your tests in CI can start passing almost all the time. The agents are often already running the tests exhaustively before committing and creating the PR. This creates a blind spot if you rely only on historical CI data to help drive efforts such as Test Pruning or Probabilistic Test Selection. CI data no longer tells the whole story. We also need to measure what happens while the agents iterate. A test that catches an agent’s mistake has earned its keep. Keep it, if not expand it.

Most enterprises don’t have the ability to measure this today. Their telemetry stops at CI because, historically, dev laptop metrics are noisy and endpoint control software comes with various limitations. Bazel and its Build Event Service seem like the perfect solution for this space.

BuildBuddy Target Performance UI

Not only can we capture and tag the metrics for later slicing and dicing, but we can also automatically set up the agents to go over these metrics regularly and fix test performance and prune and consolidate test cases. The software factory can now recursively improve itself to be more cost-efficient over time thanks to these signals.

A War for Talent

Among the usual sponsors of BazelCon, there was one name that stood out: Uber.

BazelCon 2026 Sponsors

Unlike the rest of the sponsors who are trying to market their product at the event, Uber isn’t there to sell you Uber One subscriptions. They are there to recruit talent.

It’s no secret that with big AI players paying big bucks for Bazel talent, the “traditional” internet tech companies like Uber, Airbnb, etc., have been bleeding talent to the labs. Across the tech market is a shift in talent percentiles: as the P99 talent gets sucked into “Big AI”, traditional “internet” companies such as Uber now have to shift into a lower gear to backfill their ranks.

Anthropic is hiring for Staff+ Dev Productivity at 625k USD base

And with non-competes being void in California, a large majority of engineers I talked to at BazelCon have tried interviewing at the labs. Some failed, some succeeded, but the numbers are turning heads. This causes overall market inflation among a scarce pool of talent, which is exciting if you are an engineer, and scary if you are a hiring manager.

Folks also discussed interview processes: what do you even do there? If you are still handing out coding interviews to an established open-source contributor in the Bazel ecosystem, I think you are already way, way behind. If the contributor is AI-native, they will laugh at you and just walk out of the room. There are way better opportunities for them in this bubbly market. The decision tree often comes down to a few points:

• Remote-friendly. This is a core differentiator among the AI labs. If you are fixated on RTO, you will miss out on good talent. 2-4 flights a year for offsites should be OK, though.
• Top-down commitment to expand Bazel (or a similar tool) usage. The main feedback I got from folks who decided not to join Anthropic was the lack of top-down sponsorship. Nobody wants to join an org to start fighting an uphill culture war with the rest of their co-workers. Let the builders build. Oh, and it does not need to be Bazel exactly because some folks enjoy the idea of writing a Bazel replacement themselves.
• AI adoption. Interviewees enjoy asking whether the company is opinionated about which models/harnesses are available to them, and whether they are given a fixed token budget. Having a token budget is not a bad thing. It’s a bad thing if you make the budget fixed instead of variable.

What does this mean for companies that can no longer afford top-percentile talent?

You either need to be able to sell your culture, or you need to adopt AI aggressively to empower your existing workforce. Most folks I talked to seem to agree: you can be a senior engineer adopting AI to be more productive; you can also hire an AI-native fresh grad who can dig through the codebase from day 1; but you cannot afford to be anti-AI and reject all the productivity gains seen across the entire industry. It’s genuinely surprising to hear these cases still exist among Bazel users. I hope those folks give coding agents a try and change their minds.

Performance improvements in Bazel 10 would not have been possible without AI

Isn’t it kinda ironic that the folks who are selling you cloud coding agents are also aggressively hiring human software engineers?

Yes. But in the current state of things, these coding agents are just amplifiers of your human engineers’ attention. While this may change in the future, today, you still want to curate a team filled with humans who know how to devote their time and attention to the right set of problems. These are skilled individuals with “taste” and “opinion” honed throughout the years, pattern-matched from the best among tech companies. If you are in the Bazel community, or even the much smaller Version Control community, and fit the description, congratulations because you are a million-dollar hire.

AMuseing Thoughts

Among BazelCon attendees were members from Meta’s Buck2 team. They gave a really good talk about Buck2’s Configuration Modifier, a replacement for Bazel’s Target Platform, which I thought was a very interesting divergence with different trade-offs. I got to pitch them my idea about Meta’s latest AI Agent: Muse. I don’t know Meta’s plans for Muse. But this is the competitive scenario I would be planning for.

Imagine personal AI agents becoming a successful product category. That means you, I, and everyone else at this conference will each have 10-20—an army of 24/7, always-online software engineers working for us. These coding agents will need more than just code. They will need language servers and code search for context, version control for collaboration and audit, build and test infrastructure, and deployment to a production environment.

Among these, we have seen ChatGPT Sites powered by Cloudflare as an early version of the “production environment” category. We have also seen some agent harnesses include version control in their product: Amp is powering theirs via Pierre’s Code Storage; Cursor is powering theirs via Origin. What we have not seen is a proper platform for builds and tests.

If you are Meta, would you let your customers run Git and Cargo on your data center compute? Heck no. You know that there are better options: Sapling VCS and Buck2 + RBE. These are solutions that work at scale. Eden VFS can clone and GC very efficiently. Buck2 and Bazel share cached action results across agents, while RBE can deduplicate matching actions across concurrent invocations. Cargo doesn’t natively offer that model—why pay for every agent to build the same thing? These are good, reliable solutions that Meta operates at scale; they know that they work. But the more important thing is this: Muse users don’t need to know. To the end users, these are merely implementation details that the agents will take care of. What they care about is the price per outcome, and with Sapling and Buck2 bundled into Muse, Meta could have a serious advantage on price in the Cloud Coding Agents product category.

Muse, Buck, and Sapling are friends

For the Sapling and Buck team, being able to attach their product to Meta Superintelligence Labs (MSL) will create a huge lane for promotions, bonuses, and, most importantly, headcount and tokens. “It’s a path to escape the permanent underclass,” I thought jokingly in my head.

This sounds plausible, but why do you spend so much time repeating this narrative to people?

I believe that today, Bazel (and Buck2) is a key that helps unlock productivity in top-tier AI labs. It drives down the CI compute bottleneck and enables more agents to collaborate at scale reliably.

But beyond that, I see a picture where Bazel is not just support tooling in the back of the office for these labs, but it should also be part of their core leading product in the next 6 months: the Cloud Coding Agent. If you assume that these agents will use the labs’ data centers to run builds and tests, and the compute consumption will put pressure on token/credit pricing, then by embedding Bazel and RBE as part of the multi-agent cloud factory, you will be able to offer the product at a much lower price than competitors. Otherwise, we are looking at millions of “cargo build” runs per minute a few months from now… good luck pricing that.

Given that Meta recently hired CJ Desai, MongoDB CEO, as their chief enterprise platform officer, one can only imagine what’s coming down the B2B SaaS pipeline. MongoDB is also using Bazel, btw. I wonder if other AI labs will get FOMO and do something about it. 😉

A Bazel Bard, A Buddy Bard

I am very proud of my team at BuildBuddy. At this year's BazelCon, we delivered wonderful technical talks. They are not sales pitches, just engineers talking about tech we have built over the last year, which we use ourselves and think others may also enjoy using.

Are we a sandbox company now?

Folks I talked to were constantly amazed by how small a team BuildBuddy is. We are less than 20 people at the time of writing. Yet, we are empowering some of the most critical companies in the world: frontier AI labs, space, semiconductors, robotics, car manufacturers, internet companies, top financial banks, and payment processors. We cannot name many of them, but IYKYK.

We shipped CDC in Bazel with a huge impact across the ecosystem

I really hope that we can talk more about what we have been doing in the upcoming year because there are so many cool underlying infrastructure problems we have solved. The downside of being in a team full of busy builders is that sometimes we forget to share what we have built. But in the meantime, point your agent at our GitHub repo and ask about it.