El 8 de julio, Jarred Sumner, creador de Bun, publicó las cifras detrás de un trabajo que la mayoría de los equipos de ingeniería habría descartado como imposible. Una reescritura en Rust del runtime de JavaScript, una base de alrededor de un millón de líneas escrita originalmente en Zig, se completó en 11 días y 6.502 commits, impulsada por hasta 64 agentes de IA trabajando en paralelo. La factura de tokens rondó los 165.000 dólares al precio público de la API.
La comparación que más circuló fue el contrafactual: el mismo trabajo, hecho de forma convencional, se estimó en cerca de un año para tres ingenieros. En menos de un día, ese artículo, una reescritura rival de Postgres y una réplica contundente del creador de Zig estaban a menos de 30 puntos entre sí en lo alto de Hacker News. La discusión que siguió no trata realmente de un runtime. Trata de qué ocurre cuando el costo de reescribir software fundamental cae dos órdenes de magnitud.
Qué pasó realmente dentro de la reescritura
Las cifras brutas detrás de la reescritura en Rust son lo bastante inusuales como para enunciarlas con claridad. La ejecución consumió unos 5.900 millones de tokens de entrada sin caché y 690 millones de tokens de salida. Los agentes trabajaron en paralelo y no en secuencia, y por eso el tiempo de reloj se desplomó mientras el trabajo total no. El resultado se verificó de forma continua contra la propia suite de pruebas de Bun, que reúne alrededor de un millón de aserciones.
Esa suite de pruebas es la parte que sostiene la historia. Un port dirigido por máquina no tiene criterio sobre la intención; solo tiene una especificación que puede ejecutar. Bun contaba con una de las especificaciones ejecutables más exigentes del ecosistema JavaScript, construida durante cuatro años persiguiendo la compatibilidad con Node.js. La cifra publicada para la build en Rust es del 99,8% de compatibilidad de pruebas en Linux x64 con glibc.
Lo que esa cifra no significa es que la build en Rust sea la que se instala hoy. Sigue siendo experimental, limitada a una sola plataforma, y no es el binario por defecto. La línea estable 1.3.x de Bun se sigue produciendo desde el código en Zig. Según el relato de julio, el código reescrito sí llegó a usuarios dentro de Claude Code v2.1.181 el 17 de junio, lo que es una señal relevante de producción, pero no equivale a un lanzamiento general.
Por qué un runtime que funciona abandonaría Zig
Se dieron tres razones, y ninguna es la velocidad bruta. Ambos lenguajes compilan a código nativo sin recolector de basura, y la expectativa expresada en público era que la build en Rust quedara a pocos puntos porcentuales de la de Zig.
La primera razón son las personas. Rust tiene una comunidad de contribuidores mucho mayor que Zig y, para un proyecto que quiere recibir parches externos, el tamaño de ese embudo es una restricción de diseño como cualquier otra. La segunda es el mantenimiento a escala, donde el modelo de ownership y el sistema de tipos de Rust trasladan una clase de errores del tiempo de ejecución al tiempo de compilación. La tercera es institucional. Bun fue adquirido por Anthropic en diciembre de 2025, y Claude Code se distribuye como un ejecutable de Bun a millones de usuarios. El resumen de Sumner sobre lo que está en juego fue directo: si Bun se rompe, Claude Code se rompe. Ese mismo anuncio se comprometió a mantener Bun como software libre con licencia MIT y su desarrollo público en GitHub.
Andrew Kelley, creador de Zig, publicó una réplica al día siguiente. Su objeción central es de capacidad de revisión, no de preferencia de lenguaje: entregar cerca de un millón de líneas de código generado por máquina que ningún humano ha leído tiene un perfil de riesgo distinto al de entregar un millón de líneas que un equipo escribió y revisó. También cuestionó con qué consistencia se aplicó la suite de pruebas. Es una objeción razonable, y la respuesta honesta es que nadie tiene todavía un buen método para revisar código a ese volumen.
Postgres recibió el mismo tratamiento, y los fuzzers respondieron
El segundo proyecto hizo visible el intercambio. pgrust, una reescritura de PostgreSQL en Rust iniciada a comienzos de abril de 2026 por Michael Malis y Jason Seibel, siguió una ruta parecida: un primer intento desde cero y, en junio, un cambio a conversión automática de C a Rust seguida de reescritura asistida por IA hacia un Rust más seguro.
El 25 de junio el proyecto anunció que pasaba el 100% de las más de 46.000 pruebas de regresión de PostgreSQL 18.3, junto con las pruebas de aislamiento, y que podía arrancar desde un directorio de datos existente de Postgres. Para una base de datos, ese es un listón genuinamente difícil de superar.
Entonces Andreas Seltenreich, autor del fuzzer SQLsmith, lo apuntó contra el resultado el 9 de julio. En pocos días produjo un fallo de segmentación a partir de una sola línea de SQL, SELECT numrange_subdiff(1,1);, un error interno en una sentencia MERGE, varias invariantes del planificador rotas y una validación ausente en literales bytea. Las pruebas de recuperación estaban en 34 de 47. Los benchmarks publicados fueron igual de duros: unas 728 transacciones por segundo frente a 6.365 de PostgreSQL 18.4 original, una inicialización once veces más lenta y muertes por falta de memoria bajo carga sostenida. La base incluye 2.664 bloques unsafe y 1.835 funciones unsafe, un recordatorio de que traducir mecánicamente a Rust no produce de forma automática un Rust seguro en memoria.
El kernel resolvió la cuestión del lenguaje años antes
Perdido en el ruido está que la cuestión de fondo se respondió hace tiempo, y en voz baja. En el Maintainers Summit del kernel de Linux, en diciembre de 2025, el consenso fue que Rust en el kernel ya no es experimental. Jonathan Corbet, al informar del desenlace, lo resumió como que el experimento había terminado y había salido bien. El soporte de Rust se había incorporado a finales de 2022 y creció de forma sostenida desde entonces; el summit solo retiró la etiqueta.
Ese camino llevó tres años de revisión humana, subsistema por subsistema, con mantenedores discutiendo cada interfaz. Es lo contrario de una carrera de 11 días, y por eso el resultado del kernel es duradero. El lenguaje nunca fue la parte discutida. La parte discutida es a qué velocidad puede una base de código migrar a él y seguir siendo confiable.
Qué prueban las cifras y qué no
Leídos con cuidado, la reescritura en Rust de Bun y su equivalente en Postgres sostienen una afirmación más estrecha que la de los titulares. Muestran que, cuando una base de código cuenta con una especificación ejecutable amplia, una flota de agentes ya puede traducirla entre lenguajes en días en lugar de años, a un costo que una sola persona bien financiada podría cubrir. Eso es un cambio de capacidad real y significativo.
No muestran que el resultado esté listo para producción. Los resultados de fuzzing de pgrust demuestran justo lo que una suite de regresión no atrapa: verifica el comportamiento que alguien pensó en probar, no el que nadie imaginó. La propia postura de Bun, manteniendo las versiones estables en Zig mientras la build en Rust madura, es la señal más instructiva. Quienes están más cerca del trabajo lo tratan como prometedor e inacabado, que es la lectura correcta.
Queda además una pregunta de mantenimiento que nadie ha respondido. Una base producida en 11 días sigue teniendo que ser comprendida por quien la arregle a las 3 de la madrugada dentro de dos años. La revisabilidad no es un extra en software de base; es el mecanismo por el que se acumula la confianza.
Qué cambia esto para los equipos pequeños
En MW3.biz leemos esto como una historia de democratización con un asterisco. Una capacidad que antes exigía un equipo financiado está ahora al alcance de dos personas con una tarjeta de crédito y una buena suite de pruebas, y esa es la dirección en la que queremos que avance la tecnología. También creemos que el asterisco importa: los proyectos que funcionaron aquí son los que ya habían invertido años en pruebas, y esa inversión no es algo que un agente pueda añadir después. Nuestra visión es que ampliar el acceso a este tipo de herramientas vale la pena, y que la forma honesta de defenderlo es informar de los resultados del fuzzer junto con el recuento de commits.
La conclusión práctica para un equipo pequeño es poco vistosa. La palanca está en la especificación, no en el modelo. Si tu proyecto tiene una suite de pruebas débil, una refactorización dirigida por agentes producirá algo que compila, pasa lo poco que escribiste y falla en producción. Si es exhaustiva, la misma herramienta se convierte en un multiplicador de fuerza real, del mismo modo que los modelos de pesos abiertos han ampliado el acceso al trabajo cotidiano de programación. Dedicar quince días a la cobertura de pruebas rinde hoy más que dedicarlos a la refactorización.
Ninguna de las dos reescrituras está terminada, y ambas conviene seguirlas antes que copiarlas. El estado actual del port de Bun y la lista de issues abiertas de pgrust dirán más en los próximos seis meses que cualquier benchmark aislado hoy. Lo que ya cambió es el precio de intentarlo.
