Cómo se reescribió Bun en Rust con ayuda de agentes de IA

Resumen del proyecto

Un desarrollador anunció y documentó un experimento ambicioso: portar Bun, un runtime de JavaScript, desde Zig a Rust. Lo notable no es solo el tamaño del trabajo —más de un millón de líneas añadidas— sino la estrategia empleada: una orquestación de agentes de lenguaje grande (LLM), una suite de pruebas en TypeScript como referencia de conformidad y un proceso continuo de revisión adversarial y arreglos a nivel de generador de código en lugar de correcciones manuales.

El resultado práctico fue que la versión en Rust llegó a producción en el entorno de Claude Code (release v2.1.181, 17 de junio) y la transición fue mayormente transparente para los usuarios: el arranque en Linux mejoró alrededor de 10% y, por lo demás, casi nadie notó el cambio. Esa estabilidad es, en este caso, una virtud.

Por qué Zig fue valioso y por qué Rust se volvió la opción

El autor reconoce que Zig fue fundamental para que Bun existiera y avanzara hasta ese punto: permitió construir el proyecto y resolver muchas dificultades iniciales. Sin embargo, el núcleo de la decisión de reescribir en Rust estuvo ligado a problemas persistentes con la gestión de memoria. La lista de errores incluía muchos fallos clásicos: use-after-free, double-free y rutas de error donde se olvidaba liberar memoria.

En Rust, este tipo de errores se convierten en fallos de compilación gracias al sistema de propiedad y al modelo de limpieza automática (equivalente a RAII con Drop). Esa garantía está directamente alineada con el deseo de no irse a dormir preocupado por crashes en producción. En otras palabras: Zig fue excelente para el arranque y la velocidad de desarrollo; Rust ofrecía una promesa de mayor seguridad en tiempo de compilación frente a categorías concretas de bugs.

El papel decisivo de la suite de pruebas en TypeScript

Una pieza clave que hizo posible automatizar gran parte del porte fue que la suite de pruebas de Bun estaba escrita en TypeScript. Eso permitió usar las pruebas como una suite de conformidad independiente del lenguaje: si la implementación en Rust pasaba las mismas pruebas que la original en Zig, entonces el comportamiento quedaba verificado.

Esa independencia facilitó que un ‘harness’ de agentes automatizara el traslado del código, convirtiendo el conjunto de pruebas en la referencia objetiva para validar cambios. En proyectos donde la base de pruebas sea débil o esté fuertemente acoplada al lenguaje original, replicar este enfoque sería mucho más difícil.

Ingeniería agentiva: flujos dinámicos, ensayos y revisión adversarial

El proceso no fue un simple “pedirle al modelo que reescriba y listo”. Se trató de una ingeniería sofisticada de agentes que incluía:

• Flujos de trabajo dinámicos y monitorizados: se ejecutaban pipelines de agentes que transformaban, probaban y refinaban el código.
• Ensayos y ejecuciones parciales: se probaban fragmentos y se comparaban resultados con la implementación original.
• Revisión adversarial: se emplearon revisiones intencionalmente agresivas para encontrar fallos, en vez de confiar solo en una revisión superficial.
• Corrección de procesos, no del código: cuando surgían fallos recurrentes, la solución fue ajustar al agente que generaba el código para evitar repetir el mismo error, en lugar de parchear manualmente la salida.

Durante más de una semana el equipo monitoreó los flujos, leyendo salidas y puliendo los prompts y la lógica del loop hasta obtener confianza en las generaciones. Esto ejemplifica cómo un sistema de producción de código asistido por LLM requiere tanto automatización como intervención humana informada.

Escalando la confianza: análisis del PR masivo

¿cómo revisar un pull request con más de un millón de líneas añadidas? La estrategia fue combinar tres elementos:

1. Una suite de pruebas independiente del lenguaje con millones de aserciones, que actúa como la verdad de referencia.
2. Revisión adversarial automatizada y manual para forzar escenarios límite.
3. Cuando algo falla, arreglar la generación del código (el proceso) en vez de corregir cada defecto a mano.

Esa combinación permitió abrir camino a un merge responsable: la confianza venía de ver que el comportamiento estaba reproducido por la suite de pruebas y que el proceso generador mejoraba con retroalimentación.

Costos y consideraciones operativas

El autor documentó el costo estimado de ejecutar este experimento con agentes LLM en términos de tokens: antes de aceptar el merge, el proceso consumió 5.9 billones de tokens de entrada no cacheados, 690 millones de tokens de salida y 72 billones de lecturas de tokens cacheados. A precios de API eso se calculó en alrededor de $165,000. Un dato relevante es que, por trabajar en Anthropic, ese costo no se le cobró directamente.

Esto es importante para equipos en América Latina: los experimentos a escala con LLM pueden tener un costo significativo si se realizan en proveedores con tarificación por token. Planificar presupuestos, negociar créditos o buscar optimizaciones de cache pueden ser decisivos para viabilizar proyectos similares.

Resultados y lecciones prácticas para equipos de software

• Tener una suite de pruebas robusta y potencialmente independiente del lenguaje es un multiplicador: permite reescrituras profundas con menor riesgo.
• Usar agentes LLM como asistentes en pipelines de porteo puede acelerar el trabajo y automatizar tareas repetitivas, pero requiere diseño de flujos, monitoreo y revisión adversarial.
• Las garantías de seguridad de memoria de Rust (propiedad y Drop) pueden eliminar categorías enteras de bugs que son difíciles de manejar en lenguajes sin esas características.
• El costo operativo de entrenar/ejecutar agentes a gran escala no es trivial; conviene estimarlo y buscar estrategias para reducir uso innecesario de tokens.

¿Qué implica esto para América Latina?

Para equipos y tomadores de decisiones en la región, el caso Bun ofrece un ejemplo concreto de cómo combinar prácticas clásicas (tests, CI) con capacidades modernas (LLM y agentes). No todos los proyectos necesitan o justifican una reescritura radical, pero cuando hay motivos técnicos sólidos —por ejemplo seguridad en memoria— y una suite de pruebas que actúe como contrato de conformidad, la ruta de usar agentes para automatizar partes del trabajo es viable.

Además, las organizaciones deben prepararse en tres frentes: fortalecer pruebas automatizadas, incorporar revisión humana experta para supervisar pipelines de agentes y gestionar los costos ligados al consumo de modelos. Con esos elementos, las empresas en la región podrán explorar migraciones tecnológicas más ambiciosas con menor riesgo.

Conclusión

La reescritura de Bun de Zig a Rust no fue sólo un cambio de lenguaje: fue una demostración de cómo las herramientas de IA generativa, bien orquestadas y supervisadas, pueden permitir proyectos que antes se consideraban prohibidos por su riesgo o costo. La clave fue combinar una suite de pruebas sólida, procesos de revisión adversarial y la capacidad de iterar sobre el generador de código mismo. Para equipos que estén considerando reescrituras o modernizaciones importantes, este caso ofrece un patrón reproducible —con la salvedad de planear costos y controles— que merece ser estudiado y adaptado según contexto.