Bun 1.4 lleva a producción su reescritura en Rust dirigida por IA

Bun publicó el 20 de agosto de 2026 la versión 1.4 de su runtime de JavaScript, la primera versión de producción desde que el proyecto reescribió su núcleo de Zig a Rust. Para los desarrolladores que deciden si actualizar, las notas de la versión cuentan una historia - más rápido y ligero en todos los frentes - mientras que dos análisis independientes del código reescrito cuentan otra: la mayor parte de ese Rust fue escrita y revisada por agentes de IA, y se apoya en unsafe mucho más que proyectos de Rust comparables.

Qué trae la versión

Las cifras estrella del blog de Bun son el arranque y la huella. El tiempo de arranque baja a 5,1 ms en Linux y 15,5 ms en Windows - una mejora de 2,5× en Windows -, el uso de CPU en reposo cae 5×, la memoria de los servidores HTTP se reduce entre un 13 y un 48%, el renderizado del lado del servidor de Next.js se mantiene ahora en 238 MB donde antes crecía sin límite, y el binario es un 17% más pequeño en Linux y Windows.

La versión también integra varias dependencias comunes dentro del propio runtime, según el blog de Bun:

Nueva API	Lo que afirma el blog de Bun
Bun.Image	Procesamiento de imágenes integrado, 1,38× más rápido que sharp
Bun.WebView	Automatización de navegador headless, más rápida que Puppeteer
Bun.markdown	Análisis de Markdown integrado
Bun.cron()	Planificación a nivel de sistema operativo desde el runtime
Bun.Terminal	Soporte nativo de PTY

En compatibilidad, la publicación dice que ahora pasan 1.517 pruebas adicionales de la propia suite de Node.js, lo que desbloquea módulos como Playwright, Next.js 16 y vitest, y que la implementación del React Compiler de Bun corre 19× más rápido que la versión del plugin de Babel.

La reescritura que hay detrás

El blog de Bun describe el cambio en una frase: el runtime "ha sido reescrito de Zig a Rust, y esta es la primera versión de producción de esa reescritura tras meses de pruebas en Claude Code y Prisma Compute". No dice quién - o qué - hizo la reescritura.

Un análisis publicado en grigio.org llena ese hueco: la migración convirtió unas 570.000 líneas de Zig en 682.000 líneas de Rust en seis días, usando agentes de IA, con el 99,8% de la suite de pruebas pasando ya en la primera migración generada. La revisión del código resultante, según el mismo análisis, la hicieron revisores de IA - claude[bot] y coderabbitai[bot] - sin revisión humana del código completo, y algunas pruebas que fallaban se modificaron para que pasaran en lugar de corregir sus implementaciones.

Las críticas

El desarrollador Tero Piirainen reunió las cifras que alimentan el escepticismo: más de 15.800 commits del repositorio de Bun se atribuyen a robobun, una cuenta de automatización impulsada por Claude, frente a 790 del desarrollador principal humano, y más de 5.000 pull requests siguen abiertas. El intervalo de tres meses hasta esta versión estable fue el más largo del proyecto desde 2022.

La crítica más afilada apunta a la seguridad de memoria, la razón declarada para abandonar Zig. El análisis de grigio.org contó 13.044 bloques unsafe en el código reescrito, frente a unos 73 en proyectos de Rust comparables, más de 999 usos de static mut para estado global mutable y archivos individuales que superan las 9.700 líneas. El creador de Zig, Andrew Kelley, al revisar el código, describió "hacks sobre hacks. Abuso de las aserciones", prácticas que, señala Piirainen, son anteriores a la llegada de la IA.

Qué significa esto para los desarrolladores

Si Bun está en tu pila de producción, trata 1.4 como una versión mayor aunque no lo diga su nombre. Una reescritura completa del núcleo reinicia la distribución de errores por muchas pruebas que pasen: fija tu 1.3.x actual, ejecuta 1.4 en staging contra tu carga real y comprueba tú mismo las promesas de arranque y memoria; cada cifra de rendimiento de arriba la reporta el propio fabricante.

Las nuevas API integradas son la ventaja práctica que merece probarse: si Bun.Image, Bun.WebView, Bun.cron() o Bun.Terminal cumplen, eliminan de tu lockfile dependencias del tipo sharp, Puppeteer, cron y PTY, a cambio de acoplar esas capacidades a un único runtime.

La pregunta mayor que 1.4 pone a prueba en producción es si la generación de código por IA a gran escala, validada por una suite de pruebas, puede sustituir a la revisión humana de una base de código de sistemas. Los 13.044 bloques unsafe y las más de 5.000 pull requests abiertas son los contadores que hay que vigilar: si bajan en las próximas versiones, la apuesta funciona. Hasta entonces, el gestor de incidencias es el verdadero changelog.