The Compiler Reports No Error, but the Numbers Quietly Go Wrong: Google Uses Agent Swarms to Resolve 142 Silent Bugs

Google published a paper titled 'XLA from the Trenches: Correctness on TPU Workloads at Scale.' They used a group of AI agents to fix bugs in Google's own TPU compiler, XLA. The tweet says the framework has already driven 142 compiler bugs to resolution, with another 103 findings still under review. Paper link here: https://arxiv.org/abs/2611.00624

First, let's explain what silent miscompilation means. The compiler reports no error, and the program can still finish running, but the numbers quietly drift, or a buffer gets corrupted. Short tests may not reveal it; in large-model training, the loss may look wrong weeks later; in online services, returned results may gradually degrade. Logs are clean, monitoring does not go off, and it costs the most time. The paper says this is the most dangerous category.

Their approach has several layers. Fuzzing uses both synthetic programs and real production traces at the same time to generate large numbers of inputs; the checking logic runs in parallel with the existing autotuner; once a failure is found, a hierarchical differential pipeline shrinks the full workload layer by layer, ultimately locating a single operation inside a fused kernel. Then the agent swarm comes in: generating stress tests, reproducing failures, and drafting fixes. The team also deliberately steers agents away from easy crash bugs and has them focus on silent data corruption. This choice is very practical: crash bugs are easy to find and easy to fix, while silent bugs are the ones that truly cost money.

One detail is worth noting. Someone in the tweet thread mentioned that in the paper, most fuzzing runs on simulators, with real TPUs reserved for confirming bugs; fixes still require maintainer approval. In other words, agents did not bypass humans; they simply raised the volume of candidates and reproduction work.

But the paper itself also states a somewhat uncomfortable conclusion: reviewer effort grows faster than fix complexity. In plain terms, agents writing patches is cheap; humans reading patches is not. As patches pile up, review becomes the new bottleneck. So before humans look at them, they added an adversarial pre-filter. Someone in the tweet thread asked whether this pre-filter reruns the post-bisect reproduction for each patch, or has a second model read the diff; the tweet and abstract do not elaborate. This detail will determine whether it actually saves human effort.

Several judgments in the comments are more direct than the paper abstract. One developer said they would only trust a fix if a new test fails on the old code. Another said that for agents to fix compilers, three things are most needed: a minimal reproducer, reference results for comparison, and regression tests added to the test suite. A fix without a reproduction is just a guess. Another comment put it more sharply: agent swarms can grind because there is an oracle. If you can diff outputs against reference results, humans only need to look at the inconsistent part. Many teams want to replicate this approach, and what they lack is not agents, but an oracle.

So the value of this is not 'AI can write code again.' It is more like a real engineering case: in a hardcore scenario like compilers, agents have made the pipeline of discovery, reproduction, and drafting fixes work. But it also pushes the problem one step further. Once the cost of writing patches drops, verification, review, and regression testing become harder constraints. If you want to rely on agents to fix compilers, first prepare decent reproductions, reference outputs, and tests; otherwise you are just sending more guesses to reviewers.

Paper: https://arxiv.org/abs/2611.00624
Chat with Paper: https://academy.dair.ai/papers/xla-from-the-trenches-correctness-on-tpu-workloads-at-scale-2611.00624
Original tweet: https://x.com/omarsar0/status/2117613273189376072