Bez is an open-source Rust project attempting something that sounds impossible: generate an entire web rendering engine from specifications rather than writing one by hand. The premise is direct — hand-building a browser engine costs hundreds of engineers and many years, which is why only three exist (Blink, Gecko, WebKit), and why those three organizations effectively dictate how the web works. Bez proposes to break that bottleneck by feeding spec text to language models, generating candidate implementations, and validating them against the pixel-level output of all three shipping browsers. If the candidate renders the same boxes in the same places, it passes. If not, the model tries again. The validation architecture is genuinely clever. Rather than trusting any single browser as ground truth, Bez uses a three-way vote: when Chromium, Firefox, and WebKit agree on rendering, that's the oracle. In 699 of 705 browser-pair comparisons across 235 documents, the three agreed — and all six disagreements traced to a known Firefox rounding bug (Gecko rounds to 1/60 px vs Blink/WebKit's 1/64 px). The project has already identified this as a real web-compat bug matching Mozilla bug 1719314, with reproductions on Slack, Google Store, and Samsung. This isn't just validation — it's producing useful diagnostic output. The numbers are sobering and honest. Against browser-compat-data's 17,259 leaf keys, Bez has generated just 0.6% of coverage, with another 0.3% hand-written and 0.5% linked. A full 93% of the web platform surface is unreached. CSS is the furthest along at 2.5% generated. Nine CSS 2.1 layout rules are implemented — eight written by models, one hand-written because no model candidate could beat it. Together they pass 227 recipe cases and 11 WPT normal-flow pages. This is not a browser. It's the first nine bricks of a very large building. The economics argument is the load-bearing claim. About 55-60% of engine-relevant compat entries have a usable automated oracle and generatable spec prose. Roughly 8-18% have none. The project frames this as a question of marginal cost: once the generation pipeline exists, each additional engine costs very little to produce. The tree-shaking feature extends this logic — analyze a site, drop every web feature it doesn't use, and ship a minimal engine binary. This is genuinely novel: not a browser, but a web engine factory with configurable output. The WPT (Web Platform Tests) coverage data adds credibility. A stable three-engine majority covers 2,162,676 of 2,282,301 test/subtest keys — 94.8% agreement. Canvas tests are 82.6% usable as oracles (92.7% excluding tentative), Khronos WebGL with dEQP hits 99.7%, Web Audio is at 74.4% (85.6% excluding tentative), and WebGPU CTS is about 85% for validation and 50% for numeric execution. These numbers define the ceiling for automated generation — you can only generate what you can verify. The project sits at the intersection of two powerful trends: LLM-assisted code generation and frustration with browser monoculture. Chromium's dominance means Google's engineering choices become the web's de facto standards. A viable generation pipeline would make engine diversity cheap instead of prohibitively expensive. But the gap between 0.6% and anything usable is enormous — CSS layout alone has thousands of interacting rules, and JavaScript, the DOM, and the full API surface are entirely untouched. Bez is best understood as an infrastructure bet, not a product. The thesis — that specs plus browser consensus can substitute for hundreds of engineers — is being tested honestly, with every number published and every limitation documented. The open questions section of the roadmap is longer than the accomplishments section, which is exactly what credible early-stage work looks like.
