¿Cómo avanza la reescritura de Bun en Rust?

• Aunque se presentó como un trabajo completado en 11 días, seis semanas después de la fusión en main, el 27 de julio de 2026, todavía no hay etiqueta de release y el trabajo relacionado continúa
• La reescritura inicial costó 165.000 dólares en la API de Anthropic entre el 3 y el 14 de mayo de 2026, pero no parece incluir los costos de Buildkite CI/CD ni los trabajos posteriores
• Los PR abiertos de robobun aumentaron de 1.277 el 9 de julio a 2.475 el 27 de julio; si cada pipeline por PR toma unos 40 minutos, procesarlos todos requeriría 86 días de ejecución continua
• El uso de Claude se disparó junto con el inicio de la reescritura, y también aumentó la participación de robobun y de empleados de Anthropic en trabajos de Rust, por lo que es difícil afirmar que la fecha de finalización y el costo total real sean de 165.000 dólares
• Como el equipo de Bun no afirmó directamente que la reescritura estuviera terminada ni cuál fue el costo total, para usar los resultados de programación con IA como base de valuación empresarial también hay que analizar el valor frente al costo y la intervención humana continua

---

La reescritura continúa después de la fusión

• Jarred Sumner dijo en Rewriting Bun in Rust que entre el 3 y el 14 de mayo de 2026, durante 11 días, gastó 165.000 dólares en llamadas a la API de Anthropic y fusionó el resultado de la reescritura en main
  • Son unos 15.000 dólares por día, una escala difícil de asumir para muchos mantenedores de open source
  • Los costos de CI/CD, que parecen haberse ejecutado continuamente en el clúster de Buildkite de la organización, no parecen estar incluidos en esa cifra
• Al 27 de julio de 2026, pasaron seis semanas desde la fusión, pero no hay una nueva etiqueta de release; desde la última etiqueta, bun-v1.3.14, pasaron 11 semanas
  • La vez anterior en que no hubo un release durante más de un mes fue una pausa de seis semanas, desde v0.2.2 del 26 de octubre de 2022 hasta v0.3.0 del 7 de diciembre
• Los PR abiertos de robobun, un indicador indirecto de los PR creados por Claude Code, aumentaron de 1.277 el 9 de julio a 2.475 el 27 de julio
  • Se observó que las verificaciones de Buildkite y la fusión en main suelen tardar alrededor de 40 minutos, y a veces hasta 1 hora y 30 minutos
  • Si se aplican 40 minutos por PR, fusionar los 2.475 requeriría ejecutar el pipeline durante 86 días seguidos
  • Algunos PR no están relacionados con código Rust, y entre los PR individuales hay casos que pasaron por muchísima revisión

Diferencia entre el costo publicado y el esfuerzo real

• Al inicio de la reescritura, el uso de Claude aumentó de forma considerable, y después también se observa una mayor participación de empleados de Anthropic y de robobun en trabajos de Rust
  • El análisis incluye la suposición de que los commits de Jarred Sumner durante el período de reescritura usaron Claude
  • Como algunos PR fueron escritos por empleados de Anthropic, hay que considerar no solo el costo de tokens, sino también la intervención directa de personal
• Si se asume que la reescritura sigue costando 10.000 dólares por día, el costo acumulado se acercaría a unos 800.000 dólares, pero eso no es un costo real publicado sino una estimación basada en supuestos
• El equipo de Bun no afirmó que la reescritura estuviera completamente terminada ni que el costo total fuera solo de 165.000 dólares
  • Es difícil aceptar, solo con este caso, que la IA reemplazó más rápido el trabajo de los mantenedores de open source
  • Anthropic está aplicando sus propias herramientas internamente, y tanto el trabajo de automatización como la participación de empleados continúan
• Más que negar la IA en sí, conviene ser cautos ante las expectativas excesivas y la valuación de empresas actuales, y evaluar si el valor obtenido justificó el costo invertido y si esa valuación empresarial es razonable
• El C compiler de Anthropic y el navegador web FastRender de Cursor no han tenido commits durante varios meses

[GN⁺]

Comentarios de Hacker News

• La reescritura en Rust de Bun ha estado en producción en Claude Code por más de un mes, pero casi nadie se dio cuenta, y en general está funcionando bien
  No planean lanzarla hasta que pase tantas pruebas de compatibilidad con Node.js como prometieron en el video de Bun v1.4, y si se fusiona el PR relacionado, es muy probable que lancen v1.4 el próximo martes

  • Está bien tomarse el tiempo que haga falta para asegurar la calidad del software. Que no haya lanzamientos durante un mes no es gran cosa, y si alguna función es urgente, uno mismo puede contribuir o compilarla
    Incluso Node.js, salvo correcciones de seguridad, suele pasar de 4 a 6 semanas cada diciembre sin lanzamientos relevantes, así que esta crítica, que empezó con un post enojado sin siquiera preguntar primero a los involucrados, tiene poca base. Lo digo como mantenedor de Node.js
  • Claude Code en sí ha tenido bugs y caídas frecuentes después de los lanzamientos, así que no sorprende que los usuarios no pudieran distinguir entre bugs causados por el cambio a Bun basado en Rust y los bugs de siempre
  • Me pregunto si alguien puede responder sobre los costos estimados en el artículo, especialmente los costos de Buildkite
  • Entiendo por qué preocupa el futuro de Bun, ya que muchos proyectos de vibe coding arrancan con fuerza y luego pueden quedar abandonados como Anthropic C. Bun es rápido y agradable de usar, así que ojalá dure mucho tiempo como GCC

• Después de un refactor grande o una reescritura, suele hacer falta tiempo para recuperar el ritmo normal de desarrollo, así que es difícil juzgar mucho solo por la cantidad de commits y la frecuencia de lanzamientos
  Aunque los desarrolladores conozcan la estructura, igual tienen que adaptarse de nuevo a una base de código en Rust, y es posible que estén concentrados en tareas como rastrear usos de unsafe más que en funciones visibles para usuarios. Como tampoco se han detectado grandes problemas ni cambios en el canal canary, hay razones de sobra para ponerse al día con trabajo pendiente en vez de lanzar todo con prisa
  El compilador C de Anthropic y el navegador FastRender de Cursor los vi más como experimentos de capacidad que como proyectos sostenidos, y espero que nadie dependa de ellos directamente hoy

  • Hace un mes migraron a todos los usuarios de Claude Code a la nueva versión, así que en cierto sentido ya hicieron un lanzamiento en producción. Como recibe mucha atención y no hay necesidad de apurarse con el lanzamiento formal, parece que van avanzando de forma gradual
  • La perspectiva de los costos de CI/CD es interesante. Normalmente, al cuestionar el ROI de la IA se dice que más código no implica más valor, pero si cada ejecución de CI se cobra, entonces los ingresos reales sí aumentan
    Esto además encaja con el hecho de que CI y las pruebas adicionales son clave para evitar que el trabajo repetitivo generado por IA se salga de control
  • Incluso desde la postura de quien escribió el artículo, no está claro cuánto se puede concluir a partir de estos números. Ojalá después del próximo lanzamiento Anthropic o Bun publiquen una retrospectiva revelando el costo total

• Que un LLM traduzca un proyecto en poco tiempo o genere de una sola vez un clon de una suite de oficina es impresionante, pero la esencia del software no está en la generación inicial rápida, sino en el desarrollo de funciones y el mantenimiento a largo plazo
  Un clon de Word puede implementar rápido las funciones básicas, pero en detalles como el diseño de páginas, tablas, imágenes o rotación es donde el LLM empieza a fallar. Incluso si se migrara SQLite de C a Rust y pasaran todas las pruebas, probablemente sería más lento por perder años de optimización de la implementación existente, y además habría que cargar con bugs nuevos por el cambio de lenguaje y con el soporte futuro
  En Reddit siguen apareciendo proyectos que dicen haber implementado X, Y o Z, pero corregir bugs, atender usuarios, seguridad y trabajar con estructuras de datos y bases de datos cambiantes no es atractivo, así que suelen quedar abandonados todavía más rápido que el vibe coding
  Si no entiendes a fondo el software que hiciste, al final explota, y la frase reescribí X en Z en Y días por sí sola no significa nada. Adelantar el arranque y entender, hacer crecer y mantener el código portado son cosas totalmente distintas, y los resultados de búsqueda pueden terminar contaminados por la versión en Rust abandonada y posts promocionales, mientras la versión en Zig que sí se mantiene queda opacada

  • Ojalá más gente documentara este proceso. Personalmente estoy aprendiendo mientras hago proyectos con alta dependencia de LLM, y cuando una función compleja empieza a funcionar rápido produce una sensación muy fuerte, pero integrar, ordenar y pulir la UI termina siendo todavía más doloroso después de haber probado esa velocidad inicial
    Si el código queda demasiado enredado con soluciones improvisadas, se llega a un punto de inercia en el que el LLM ya no puede avanzar sin generar todavía más caos, y entonces hay que arreglar la arquitectura, tirar todo y empezar de nuevo, o volver hasta el último punto en que todo estaba estable. Es como desarrollar con un jetpack: llegas más rápido a la meta, pero también te estampas contra la pared más rápido y con más dolor
    Entre el debate sobre si la IA es lo mejor o lo peor y la competencia por ver quién usa mejor las herramientas, falta información sobre qué funciona, qué fracasa y cómo hay que cambiar el comportamiento durante el uso. Quiero escribir también sobre mi experiencia directa, pero me sigo postergando porque es más divertido crear funciones nuevas o arreglar detalles visuales de la UI
  • En GitHub ya había miles de motores de juego y compiladores para lenguajes ficticios abandonados desde antes de los LLM. En los foros de sistemas operativos de inicios de los 2000 casi todos hacían su propio OS, y algunos hasta lograban ejecutar Firefox
    No todo el software necesita ser comercial ni estar muy pulido para ser útil, y con solo ser un experimento de aprendizaje ya se puede aprender bastante
  • Mientras más profundo se vuelve lo técnico, más fácil es que se lo considere reemplazable. Eso pasa porque se acepta la premisa de que en una organización el valor lo crea la pura capacidad técnica, no la persona ni sus relaciones
    Pero parece que se está empezando a aceptar que también importan factores contingentes como los efectos de red, la propiedad y la responsabilidad. Aun así, también está la paradoja de que muchos técnicos entraron al ámbito técnico justamente para evitar el amiguismo, las evaluaciones arbitrarias y los entornos donde el humo vale más que la técnica
  • Trabajé en una startup que detuvo incluso el desarrollo de funciones para reescribir por completo una base de código grande, pero aunque me asignaron a otro proyecto y me perdí todo el proceso, cuando volví casi no hubo curva de aprendizaje
    Eso fue porque, aunque el lenguaje había cambiado, la arquitectura central, las estructuras de datos y los conceptos seguían siendo los mismos. Bun tampoco se rediseñó desde cero, sino que primero se portó tal cual a un lenguaje nuevo. Incluso a la luz de experiencias previas a los LLM, si quieres hacer que el equipo cambie rápido, lo correcto es portar a otro lenguaje de la forma más simple y veloz posible, y minimizar los X días de reescritura es un buen objetivo
  • La actitud de no entender a fondo el código que uno mismo escribe es cortoplacismo extremo. Los mantenedores van a aprender por las malas dónde está la frontera entre código generado por IA y código que un ser humano realmente puede mantener

• Alguien comentó que modernizó la implementación original en Zig, aplicó buenas prácticas y corrigió errores, logrando builds incrementales de menos de 1 segundo. Eso sugiere que el problema que justificó la reescritura en realidad fue autogenerado y podía resolverse por sí solo
  https://ziggit.dev/t/buz-a-drop-in-replacement-for-bun-using...
  La versión en Zig también usa LLM, así que no tiene que ver con una guerra cultural. Quien entiende bien el dominio del problema siempre pudo lograr mejores resultados que quien solo arroja recursos como cientos de miles de dólares en tokens

  • El punto clave que justificó la reescritura no era la velocidad de compilación, sino los errores de memoria, especialmente al interactuar con objetos de JavaScript gestionados por garbage collection. Zig no tiene una forma general de bloquear eso, y tampoco parece haber afirmaciones de que Buz lo haya resuelto
  • Este proyecto parece más un meme o una broma que un intento serio. Califica las 600 mil líneas existentes como código caótico generado por IA y dice que rechazará contribuciones escritas por humanos hasta reescribir la mayoría de los subsistemas
    Es difícil tomar en serio un proyecto que limpia código desastroso con LLM mientras prohíbe contribuciones humanas

• Gracias a la reescritura de Bun, ahora se atreven mucho más a intentar portar y reescribir código, y a vendorizar dependencias externas, además de especializarlas para necesidades internas aunque no encajen con el proyecto upstream
  Al mismo tiempo, empezaron a asignar tareas más ambiciosas a los modelos de código y a concentrarse mucho más en harnesses de prueba y validación fuera de los límites del lenguaje. Ha participado en reescrituras grandes durante años, pero considera que Bun, al mantener las pruebas y la equivalencia funcional e incluso agregar mejoras, fue un enorme éxito de ingeniería

• En la discusión sobre la reescritura de Bun hubo muchas descalificaciones dramáticas y ataques personales, y parece que cada quien proyecta intereses ideológicos más profundos. Este texto es escéptico sobre qué tan exitosamente la IA puede reemplazar a los programadores, y el punto del mantenedor de Zig se acercaba más a la ética y el futuro del open source en la era de los LLM
  Desde una postura optimista sobre las capacidades de la IA, no hay demasiados motivos para dudar de que un desarrollador experto pueda guiar a un LLM de punta para traducir una biblioteca completa. La pregunta de seguimiento más importante es el costo actual y si en el futuro habrá una división total entre el bando que adopta IA y el que no

  • En el equipo no había nadie con experiencia en Rust
  • El port de Bun de Zig a Rust casi no deja lecciones generalizables sobre Zig, Rust, portabilidad entre lenguajes o uso de LLM. Hay demasiadas características difíciles de cuantificar en los codebases de antes y después, y también influyen las preferencias sobre el lenguaje, la forma de portar y la programación con LLM
    Si no se obtiene el mismo resultado o el costo en tokens es mayor, se dirá que la herramienta se usó mal; si el resultado decepciona, se dirá que solo era una prueba de concepto y que los modelos mejoraron en los últimos 6 meses, así que no se puede comparar, por lo que es difícil obtener conclusiones verificables
  • Hay muchas razones para ser escépticos, porque los LLM son excelentes para producir resultados que parecen plausibles pero están equivocados. Independientemente de la validez del resultado, este trabajo fue claramente un evento de marketing, y Anthropic tiene antecedentes de anuncios exagerados o inexactos, así que hace falta una verificación más estricta

• Sospechaba que tanto el anuncio que declaraba victoria como el análisis profundo que parecía sincero fueron algo apresurados
  El principal riesgo del furor por los LLM es que entrega resultados inmediatos a desarrolladores expertos cansados de tipear y del pensamiento manual, mientras los hace poner en garantía décadas de experiencia acumulada en software. La factura real llega mucho después

  • Tipear es algo secundario en la ingeniería de software, pero si de verdad el cuello de botella es escribir, los LLM pueden tener valor. Solo que esa situación es rara

• Reflejar en el artículo que Bun basado en Rust estuvo en producción en Claude Code desde el 17 de junio y que, tras entrar a main, también se ofreció en canary, le daría más credibilidad. Para una reescritura de este tamaño, un periodo largo en canary está totalmente justificado

  • El artículo ya trataba el uso interno real de Anthropic

• Puede que Anthropic no tenga mucho interés en lanzar públicamente la próxima versión. La versión en Rust lleva más de un mes en producción dentro de Claude Code, usado por millones de personas, y es posible que el objetivo de adquirir Bun haya sido Claude Code
  El proyecto open source en sí quizá no sea tan importante para ellos

  • Si de verdad solo importara Claude Code, habría sido mucho más eficiente reescribir Claude Code mismo en Rust que cambiar el lenguaje del runtime de TypeScript. Es posible que el costo de unos 800 mil dólares haya salido del presupuesto de marketing de Anthropic en busca de un gran impacto promocional
  • Es poco probable que abandonen a la comunidad más amplia, y mientras más usuarios haya, más se beneficia Anthropic. Si este lanzamiento sale mal, podrían recibir críticas fuertes y dañar la confianza de la comunidad, así que parece que están siendo más cautelosos de lo habitual
  • Bun es un componente importante del ecosistema web, así que el simple hecho de que Anthropic lo desarrolle con IA genera un enorme efecto publicitario
  • Claude Code probablemente podría ejecutarse en cualquier runtime de JavaScript, así que da curiosidad por qué necesitaban Bun
  • Al final, parece un evento de marketing para publicitar la reescritura de código con Claude. El mensaje de que hay que gastar mucho dinero en Anthropic para deshacerse de un codebase incómodo se transmitió con éxito
    Si el objetivo era Claude Code, pudieron haber reescrito eso primero, y si venían enfatizando que ya no escriben código directamente, entonces el lenguaje de implementación tampoco debería importar

• Quien haya reescrito software puede entender la etapa actual. Casi todo funciona, pero hay que seguir corrigiendo para que no haya regresiones, y la presión asociada al lanzamiento también es muy grande
  Cree que la decisión de reescribir fue correcta, pero no querría desplegarla en producción desde el principio. Sería menos pesado para Jarred ofrecer primero una release candidate en vez de sacar de inmediato la versión estable