Bez: un motor de navegador generado con IA a partir de specs

Qué es Bez y por qué importa para el ecosistema web

Bez es un proyecto open source alojado en Tangled que plantea una idea poco habitual: en lugar de escribir a mano un motor de renderizado web, lo genera automáticamente a partir de las especificaciones del W3C y de los tests del Web Platform Tests (WPT). La propuesta, fechada el 1 de octubre de 2026, parte de una constatación dura: construir un motor de navegador a mano cuesta "cientos de ingenieros y muchos años", un umbral que en la práctica solo han podido cruzar Chromium (Google), Gecko (Mozilla) y WebKit (Apple), según recoge el propio repositorio.

Ese oligopolio técnico es, precisamente, lo que Bez quiere romper. Si la pipeline de generación funciona, el argumento del proyecto es que cada motor adicional cuesta muy poco, y que cualquiera podría tener el suyo: gobiernos, regiones, empresas, proyectos de privacidad o dispositivos embebidos.

Cómo funciona la generación: del texto de la spec a Rust verificado

El repositorio documenta un bucle de generación con cinco pasos, ilustrado en el README del proyecto:

1. A partir del texto de la especificación, un modelo escribe múltiples candidatos de implementación.
2. Cada candidato se ejecuta dentro del propio engine.
3. La salida visual se compara con Chromium, Firefox y WebKit (los tres navegadores de referencia, cacheados).
4. Se exige que las cajas aparezcan en los mismos lugares que en los oráculos.
5. El candidato ganador se commitea como Rust normal.

El proceso se apoya en datos abiertos bien conocidos del ecosistema: browser-specs (el catálogo de especificaciones de la W3C), web-features (la plataforma web agrupada por features), browser-compat-data (la superficie web completa con datos de compatibilidad), y el propio WPT (web-platform-tests.org) como oráculo de tests.

Estado actual: cobertura del 0,6% y hallazgos que ya son noticia

El dashboard del proyecto, calculado sobre 17.259 leaf keys de browser-compat-data 8.0.4 con 74 reglas en docs/feature-map.json y fechado el 25 de septiembre de 2026, muestra un panorama desigual:

Área	Generado	Escrito a mano	Vinculado	Solo oráculo	Sin alcanzar
Global	0,6%	0,3%	0,5%	5,7%	93,0%
CSS	2,5%	1,1%	2,0%	0,0%	94,4%
HTML	0,0%	0,0%	0,0%	0,0%	100,0%
API	0,0%	0,0%	0,0%	9,9%	90,1%
JavaScript	0,0%	0,0%	0,0%	0,0%	100,0%
SVG	0,0%	0,0%	0,0%	0,0%	100,0%

El proyecto no oculta la cifra: en términos de superficie web cubierta de forma útil, Bez está todavía en fase de proof of concept. CSS, donde más avance hay, apenas supera el 5% sumando todas las columnas "alcanzadas".

Pero el trabajo ya ha producido hallazgos técnicos relevantes:

• Los tres navegadores suelen coincidir. De 705 comparaciones por pares de navegadores sobre 235 documentos (commit 3ca7323), 699 coincidieron. Las seis discrepancias siempre se resolvieron a favor de Blink y WebKit, con Firefox como outlier. El documento firefox-app-units.md detalla el motivo.
• Esa diferencia es un bug de compatibilidad real. Gecko redondea longitudes a 1/60 de píxel mientras Blink y WebKit usan 1/64 de píxel, lo que hace que un flex item se rompa solo en Firefox o que offsetWidth difiera por un píxel. El proyecto reproduce el mismo tipo de rotura reportada en Slack, Google Store y Samsung, y la conecta con el bug de Mozilla 1719314.
• El voto tripartito es estable en la mayoría del WPT. Una mayoría estable entre los tres motores cubre 2.162.676 de 2.282.301 test/subtest keys (94,8%), según wpt-votes.md.
• Las suites de conformidad son usables como oráculo. Considerando usable un test cuando dos de cada tres motores coinciden: WPT canvas 82,6% (92,7% excluyendo tests tentativos), Khronos WebGL con dEQP 99,7%, WPT Web Audio 74,4% (85,6% excluyendo tentativos) y WebGPU CTS alrededor de 85% en validación y 50% en ejecución numérica.
• La programación lógica tiene un nicho. El colapso de márgenes escrito como Datalog coincidió con los navegadores en 1.195 de 1.195 offsets y cazó un bug sembrado que la verificación geométrica no detectó en ninguno de los 227 casos.

Por qué la cobertura es tan baja: la economía de la plataforma

El propio proyecto hace cuentas en platform-economics.md y oracle-coverage.md. Su estimación es que entre el 55% y el 60% de las entradas relevantes de compatibilidad tienen un oráculo automatizado utilizable y prosa de especificación generable, mientras que entre el 8% y el 18% no tienen ninguno. La franja intermedia es la que está en disputa y la que define si la tesis de Bez es viable a gran escala o solo en un subconjunto del estándar.

Qué cambia si Bez madura: motores regionales y embeddings ligeros

El README plantea cuatro objetivos de diseño que, de cumplirse, cambian la ecuación para founders y equipos de producto:

• Completo o recortado según uso. El build por defecto es un motor completo. Pero existe un motor scoped al contenido (documentado en content-scoped-engine.md): se analiza un sitio o una app y cada feature que su contenido nunca toca se elimina del binario, no se desactiva. El analizador de contenido ya está mergeado en el repo.
• Rápido en cualquier dispositivo. Un motor más pequeño hace menos trabajo y consume menos memoria, lo que importa en hardware embebido y móviles de gama baja.
• Fácil de embeber. Una API clara para apps y dispositivos que hoy se ven obligadas a embarcar todo Chromium o quedarse sin navegador.
• Rápido de actualizar. Cuando una spec o un test cambia, el código afectado se regenera y re-verifica, no se reescribe a mano.

Qué significa esto para tu startup

Aunque Bez está lejos de ser un producto, su tesis abre decisiones prácticas que ya puedes evaluar:

• Si tu producto depende de un WebView de Chromium, el coste binario y de memoria es real. Una alternativa basada en un motor generado y recortado al contenido que sirves podría, en el medio plazo, reducir drásticamente el tamaño de tu app y el consumo en dispositivos low-end. Hoy no es una opción lista para producción, pero vale la pena seguir el repositorio y los hitos de roadmap.md.
• Si tu producto automatiza código a partir de specs o normativa (regulación, contratos, datos abiertos), el patrón de Bez es directamente inspirador: oráculo automático + suite de tests como ground truth + código generado verificado por un juez externo. Es un template de arquitectura aplicable a fintech, legaltech y herramientas de compliance, no solo a navegadores.
• Si haces IA generativa aplicada a código de bajo nivel, mira cómo Bez acota el espacio de búsqueda con la votación entre tres motores y con la separación entre código generado y código a mano. Esa disciplina de "el modelo propone, el oráculo dispone" reduce alucinaciones y da un camino para auditar el output en sectores regulados.

Lo que aún no está claro

El propio repo marca preguntas abiertas en roadmap.md → Open questions: cuánto cuesta escribir cada regla a mano, qué ancho debe tener la parte generada de cada feature, qué porción de WPT es alcanzable sin JavaScript y dónde acaba el código generado a partir de IDL. Hasta que esas preguntas tengan respuesta y la cobertura global salga del dígito por ciento, Bez debe leerse como una hipótesis de investigación con resultados iniciales prometedores, no como un motor alternativo listo para producción.

Fuentes

• Bez — Generating a web engine from specs and tests (fuente original)
• Bez — dashboard con cobertura por área
• Bez — viabilidad económica de la plataforma
• Bez — cobertura de oráculos
• W3C browser-specs
• Web Platform Tests