Me preocupa Bun
(wwj.dev)- Bun es un runtime rápido de JavaScript y una herramienta que facilita el trabajo con TypeScript, pero ha crecido la preocupación de que, tras la adquisición por parte de Anthropic en diciembre de 2025, pueda verse afectado por políticas de producto y formas de operación
- En el anuncio de la adquisición se afirmó que Bun seguiría siendo open source y mantendría la licencia MIT, y que el mismo equipo continuaría desarrollándolo; además, como Claude Code se distribuye como un ejecutable de Bun, se dijo que Anthropic tenía un incentivo directo para mantener Bun estable
- Después de abril de 2026, surgieron problemas en Claude Code relacionados con degradación de calidad, comportamiento restrictivo, limitaciones a harnesses de terceros, confusión en los cobros y comunicación lenta; el postmortem de ingeniería de Anthropic atribuye la causa a problemas de la capa de producto, como la reducción del esfuerzo de razonamiento predeterminado y cambios en los prompts
- Según reportes de TechCrunch y Gigazine, Claude Code puede exigir pagos extra para dar soporte a harnesses de terceros como OpenClaw, o incluso rechazar solicitudes y activar cobros adicionales solo por menciones a
OpenClawen el historial de git, lo que deja ver un comportamiento inesperado - La inquietud no surge por problemas de calidad de Bun en sí ni de su equipo, sino por la posibilidad de que las políticas de Anthropic terminen impregnando a Bun; por eso, algunos proyectos están migrando a pnpm para la gestión de paquetes y ahora lo recomiendan también para nuevos proyectos de JavaScript y TypeScript
Contexto detrás de la creciente preocupación por Bun
- Bun es un runtime de JavaScript rápido y práctico que hace más cómodo trabajar con TypeScript en scripts pequeños, apps, pruebas y herramientas
- Se esperaba que triunfara como alternativa a Node.js por su instalación rápida, pruebas rápidas, mejor bundling y una menor carga en la cadena de herramientas
- El centro de la preocupación no es la calidad de Bun en sí, sino que, al haber pasado a formar parte de Anthropic, podría verse afectado por sus políticas de producto y su forma de operar
La adquisición de Anthropic y las expectativas iniciales
- Anthropic adquirió Bun en diciembre de 2025
- Según el anuncio, Bun seguiría siendo open source bajo licencia MIT, el mismo equipo continuaría desarrollándolo y la hoja de ruta seguiría enfocada en herramientas JavaScript de alto rendimiento y compatibilidad con Node.js
- El anuncio incluía la frase: “Claude Code ships as a Bun executable to millions of users. If Bun breaks, Claude Code breaks. Anthropic has direct incentive to keep Bun excellent.”
- En ese momento, parecía razonable pensar que, como Claude Code funcionaba sobre Bun, Anthropic tenía un incentivo directo para mantener Bun rápido y estable
- Esa lógica sigue siendo válida, pero ha surgido la inquietud de que están empezando a verse grietas en la manera en que Anthropic opera sus productos de software
Cómo cambió la evaluación sobre Claude Code
- La principal preocupación no es la calidad de los modelos de Anthropic en sí
- La familia de modelos, presumiblemente Claude Opus 4.6, sigue siendo considerada buena para programación, escritura, razonamiento y trabajo general de desarrollo
- El problema está en la capa de producto alrededor del modelo, y la idea central es que la usabilidad actual de Claude Code ha empeorado mucho
- Hace alrededor de un año, Claude Code se sentía como una herramienta capaz de leer proyectos, hacer cambios enfocados, ejecutar comandos, corregir errores y seguir avanzando
- En ese momento, Claude Code era una de las primeras herramientas de programación con IA que daba la impresión de que el flujo de trabajo del desarrollador podía pasar de estar centrado en autocompletado a estar centrado en agentes
- Incluso en diciembre de 2025 Claude Code ya estaba empeorando, pero seguía siendo utilizable, y la adquisición de Bun por parte de Anthropic todavía parecía comprensible desde la idea de que estaban construyendo el futuro de las herramientas de programación
Problemas de Claude Code después de abril de 2026
- En abril de 2026, los desarrolladores empezaron a cuestionar la calidad de Claude Code, su comportamiento restrictivo, las limitaciones a harnesses de terceros, los cobros confusos y la lentitud en la comunicación
- Anthropic publicó un postmortem de ingeniería y atribuyó las causas a problemas de la capa de producto, como la reducción del esfuerzo de razonamiento predeterminado, un bug de sesiones antiguas y cambios en los prompts que dañaron la calidad de programación
- Ese análisis posterior fue mejor que fingir que no había pasado nada, y se recibió como uno de los pocos casos en que Anthropic reconoció su propia responsabilidad
- Según TechCrunch, Anthropic informó a los suscriptores de Claude Code que tendrían que pagar extra para obtener soporte para OpenClaw y otros harnesses de terceros
- Según Gigazine, el simple hecho de que
OpenClawaparezca en el historial de git puede hacer que Claude Code rechace solicitudes o active cobros adicionales - Ese reporte cita declaraciones de Theo según las cuales bastaba con que OpenClaw apareciera en commits recientes dentro de un blob JSON para que el comportamiento se activara incluso al invocar directamente
claude -p "hi"en un repositorio vacío - La escena relacionada también puede verse en este clip de video
- Este tipo de comportamiento hace que el producto parezca uno donde se lanzan cambios sin haber probado suficientemente la experiencia real de uso a nivel de código
- Desde fuera, Claude Code parece ir en la dirección equivocada, con más restricciones, cobros extraños y comportamientos inesperados que cambian según el texto de los commits
- Esta tendencia se describe como enshittification
La inquietud que se extiende a Bun
- Bun está profundamente integrado en Claude Code, y como Claude Code parece estar empeorando, surge la preocupación de que Bun pueda ir en la misma dirección
- Eso no significa que Bun sea malo ni que el equipo de Bun haya perdido el interés
- El problema es que, cuanto más se integren Bun y su equipo con Anthropic, más podrían entrar también sus políticas
- Si las políticas que parecen haber dañado a Claude Code también afectan a Bun, podrían aparecer en Bun problemas que hagan parecer que el equipo no usa realmente su propio producto
- Esa sola posibilidad ya hace más difícil tener confianza para seguir usando Bun en algunos proyectos
Por ahora, migrar a pnpm
- Bun ofrece más funcionalidades dentro de una sola herramienta que pnpm
- Bun soporta TypeScript sin una etapa de build separada, ofrece un bundler en lugar de
Vitee incluye pruebas en lugar devitest - El hecho de reunir esas funciones en una sola cadena de herramientas es, en la práctica, una gran ventaja
pnpmno es un reemplazo de Node.js ni de Bun; es solo un gestor de paquetes- Aun así, si la parte de Bun que más se usa en el trabajo diario es la gestión de paquetes, tanto Bun como pnpm ofrecen instalaciones rápidas, buen soporte para monorepos y un uso razonable de disco
- Por eso, algunos proyectos que hoy usan Bun están optando por alejarse de Bun y migrar a pnpm
- Si hoy preguntan qué recomendar para proyectos de JavaScript o TypeScript, la respuesta pasa a ser pnpm
No es una recomendación de abandonar Bun
- Aunque algunos proyectos se estén moviendo fuera de Bun, no hace falta tomarlo como una respuesta general para todos los casos
- Para proyectos nuevos, pnpm tiene sentido
- En proyectos existentes, también es válido decidir quedarse con Bun hasta que haya una razón suficiente para migrar
Lo que queda posible y la conclusión
- La esperanza es que Bun siga siendo excelente, que el equipo de Bun continúe haciendo buen trabajo y que Anthropic les dé la autonomía necesaria para tomar decisiones adecuadas para el ecosistema JavaScript
- Anthropic tiene dinero, capacidad de distribución y razones prácticas para preocuparse por el rendimiento y la estabilidad de Bun
- Bun todavía podría salir fortalecido de esta situación
- Pero hoy hay menos confianza en la situación que en diciembre de 2025
- Antes, Claude Code parecía una prueba de que Anthropic entendía las herramientas para desarrolladores; ahora parece más bien una advertencia de que quizá Anthropic no sabe qué se necesita para mantener y mejorar un producto a largo plazo
- Bun sigue siendo excelente, pero es difícil saber hacia dónde irá de aquí en adelante
- Como en un año la situación podría ser completamente distinta, la intención es volver a revisar entonces si esta predicción resultó correcta
3 comentarios
Reconozco que gracias a Bun, Node también cambió bastante, pero cuando veo en el repositorio a IAs armando y celebrando PRs entre ellas, me da miedo pisar una mina de regresiones donde algo que funcionaba deja de funcionar.
Antes de la adquisición por parte de Anthropic usaba Bun como principal, pero ahora volví otra vez a Node.
Sigo pensando que la función de
sfxes una killer feature, pero si no necesitas eso, no tengo muy claro por qué habría que usar Bun ahora mismo.Comentarios en Hacker News
No estoy de acuerdo con toda la premisa: incluso antes de la adquisición, Bun en algún momento iba a tener que encontrar una forma de monetizarse.
Que la empresa matriz haya mostrado malas prácticas en otro software, Claude Code, no significa automáticamente que vaya a empeorar Bun. Entiendo la preocupación, pero por ahora sigo siendo optimista con Bun.
Claude Code es el producto principal de Anthropic y está creciendo a una velocidad extrema, así que incluso cambios pequeños pueden terminar en problemas de cobro. En cambio, Bun es un runtime de JavaScript que puede enfocarse en ser el mejor runtime posible, y como no afecta directamente los ingresos ni las pérdidas de Anthropic, es menos probable que necesite parches urgentes por abuso como Claude Code.
Sigue sin estar claro qué va a pasar en los próximos años, pero justo ahora, recién después de la compra, no me preocupa demasiado.
Estos laboratorios quieren eliminar esa competencia porque las herramientas de ejecución de terceros amenazan con convertir al modelo base de lenguaje grande en una mercancía, y al mismo tiempo están jugando a ver quién aguanta más tiempo perdiendo dinero.
Al final van a tener que ponerle precio correctamente al producto, y solo pueden esperar haber eliminado toda la competencia para entonces. Pero parece que ya están perdiendo ese juego. Los modelos útiles son cada año más pequeños y más baratos de ejecutar, así que ya pasamos el umbral donde el desarrollo de herramientas de ejecución de terceros puede seguir incluso sin una base de usuarios de suscripción.
La apuesta principal —que la IA útil requería hardware extremadamente caro— ya fracasó, y la segunda apuesta, atar a los usuarios al ecosistema y monetizar después, también va a fracasar. Al final van a tener que competir solo por la calidad real del producto, y eso es mucho menos rentable.
Hay equipos que ahora le están apostando todo a la IA y se mueven con la idea de ni siquiera mirar el código directamente. Lo he visto en la práctica y el resultado es el esperable. Hasta cierto punto funciona, pero especialmente cuando cada equipo maneja términos técnicos y entendimientos distintos, la complejidad se acumula, los errores también, y al final ya no queda ninguna persona o equipo que entienda realmente cómo funciona el software.
También existe esa tendencia de dejar que la IA controle el navegador o herramientas, además de pruebas unitarias e integrales, sin que haya pruebas o aseguramiento de calidad hechos por humanos. La cultura de Anthropic podría cambiar la forma de operar y de pensar del equipo de Bun.
Si esta cultura y esta forma de pensar se vuelven el estándar, o los modelos van a mejorar muchísimo, o va a bajar la calidad del software.
Hay una muy buena charla de Matt Pocock: https://youtu.be/v4F1gFy-hqg
“El código no es barato. El código malo se ha vuelto más caro que nunca, porque si tienes una base de código difícil de cambiar, no puedes aprovechar la abundancia que la IA puede ofrecer. En una buena base de código, la IA funciona realmente, realmente bien.”
Una vez que el mal código empieza a acumularse por sí solo, es muy difícil salir de eso.
No entiendo por qué la gente usa Deno o Bun en vez de Node. Está bien que haya competidores para el runtime de JavaScript, pero no veo muy claro qué se gana al cambiar desde Node.
Bun no tiene REPL y su motor de JavaScript es peor; Deno me parece como un Node con un sistema de permisos limitado y molesto, y según yo tampoco tiene sqlite. Ambos dicen tener buen rendimiento, pero parece que solo en benchmarks escogidos; en cargas de trabajo que probé yo mismo hace como un año, ambos eran más lentos que Node.
Eso sí, una vez entregando una herramienta ERP pequeña, usé Bun porque sus herramientas para empaquetar el proyecto como
*.exeeran las más sólidas. Todo estaba hecho en Node con JavaScript sin dependencias, y solo usé Bun para distribuirlo; esa experiencia sí fue claramente mejor que con Node.La verdad es que Bun nunca ha estado especialmente bien gestionado. Había muchos bugs y huecos en cada función, y en cada release arreglaban unas cosas pero rompían otras.
En un solo patch release reciente metieron tantas funciones importantes y cambios incompatibles como los que la mayoría del software mete en dos versiones mayores.
Incluso usándolo básicamente solo como ejecutor de scripts y gestor de paquetes npm, la cantidad de trabajo que implica encontrar una versión “buena” es sorprendente. Varias veces se me ha quedado congelado de repente durante la instalación en versiones patch, y por eso no pude actualizar por un tiempo.
Hace como dos versiones menores parece que rompieron por completo los scripts
postinstalljunto con trustedDependencies. No dijeron ni una palabra en las notas de la release y en GitHub tampoco parecía que nadie lo hubiera reportado. Cerca de la 1.1 todavía se podía lograr que Bun hiciera builds de trustedDependency enpostinstall, pero después dejó de funcionar y lleva meses roto.spawnse queda colgado en silencio sin error, y como el escáner va aparte depostinstall,--ignore-scriptstampoco ayuda. Está roto al menos desde la 1.3.5.Trabajo en Bun, y este post me parece un poco confuso. Tanto yo como el equipo usamos Bun todos los días para mejorar Bun, y el ritmo de desarrollo de hecho se ha acelerado. Desde que nos unimos a Anthropic, la estabilidad de Bun también ha mejorado muchísimo.
Entre las cosas que vienen en la próxima versión de Bun están una reducción de 17 MB en el binario de Windows x64 [0], una reducción de 8 MB en el binario de Linux [1], el flag de CLI
--no-orphanspara terminar recursivamente procesos hijos remanentes [3], cacheo de contexto SSL para clientes TCP y sockets Unix que reduce fuertemente el uso de memoria en clientes de base de datos como Mongoose/MongoDB [4], clientes experimentales HTTP/3 y HTTP/2 en fetch [5], soporte experimental de HTTP/3 enBun.serve()[6] y la biblioteca integrada de procesamiento de imágenesBun.Image[7].Además de eso, también vienen mejoras de confiabilidad en
node:fs, Worker, BroadcastChannel y MessagePort.Gracias a la adquisición por Anthropic, Bun ya no necesita ser un negocio que genere ingresos. Claude Code depende de Bun, y muchos ingenieros de software dependen de Claude Code para trabajar, así que hay un incentivo fuerte para seguir mejorando Bun.
[0]: https://github.com/oven-sh/bun/pull/30219
[1]: https://github.com/oven-sh/bun/pull/30098
[2]: https://github.com/oven-sh/WebKit/pull/211
[3]: https://github.com/oven-sh/bun/pull/29930
[4]: https://github.com/oven-sh/bun/pull/29932
[5]: https://github.com/oven-sh/bun/pull/29863
[6]: https://github.com/oven-sh/bun/pull/30032
Puede que Bun sea la excepción, pero no se puede decir que la preocupación no tenga fundamento.
El CEO de Anthropic ha hecho repetidamente predicciones exageradas como si la IA fuera a reemplazar casi por completo a los programadores humanos, y Anthropic está aplicando esa creencia a Claude Code hasta convertirlo en un espagueti inmantenible.
Pasé unas horas migrando el backend del sitio web de afilado de cuchillos de Bun a Node, y me siento bien de haber evitado el lock-in. Al principio estaba bastante entusiasmado con Bun, pero con el tiempo fui perdiendo confianza.
Lo que sí voy a extrañar es hacer consultas sqlite con tagged template literals, que
Bun.password.verifyuse argon2 por defecto, importar HTML, la transformación JSX y la carga automática de archivos.env.https://burlyburr.com llama a https://backend.burlyburr.com
https://nodejs.org/api/sqlite.html#databasecreatetagstoremax...
.envy sqlite.Yo no diría que Bun funcionara bien ni siquiera antes de la adquisición. Lo seguí usando para scripts pequeños, pero en el trabajo no habría desplegado servicios con Bun.
Entre problemas de memoria e incompatibilidades sin resolver, me parecía más bien un juguete interesante que mostraba bien que Node.js todavía tiene margen para mejorar.
Por ejemplo, seguí de cerca https://github.com/oven-sh/bun/issues/14102 y al final las librerías terminaron agregando ramas del tipo “si es Bun haz x”, y eso es lo opuesto a la compatibilidad.
La dirección de Claude Code y Anthropic da la impresión de querer esconderle cosas al usuario a la fuerza. Algunos recordarán el escándalo cuando leer
xxx.yypasó a contarse como leer 1 archivo o 2 archivos.Después siguieron más cambios así, imposibles o muy difíciles de configurar. Entiendo la intención comercial: lograr que se use la mayor cantidad posible de IA, sacar a los humanos del ciclo y obtener más datos de entrenamiento y más consumo de tokens.
Pero el resultado, en mi opinión, es que Claude Code se ha vuelto mucho peor y mucho menos confiable. Se siente como un intento de quitarle el volante al usuario a escondidas. Si sigues esa lógica, cada vez se pueden justificar más cosas.
Por ahora, lo que ha crecido sobre todo es la desconfianza.
Estoy de acuerdo con el post original, y también entiendo que para algunas personas todavía pueda parecer una reacción prematura.
Vivimos en un mundo muy distinto al de antes, y la gente está más consciente de las preocupaciones éticas y más dispuesta a resistirse para no repetir errores del pasado.
Desde un criterio técnico podría ser una conclusión apresurada, pero desde un criterio de preocupación ética sí tiene sentido. La mala conducta ya no se puede deshacer tan fácilmente como antes, y hacen falta medidas preventivas para evitar el gran impacto que pueden generar esas decisiones.
El autor al final enumera cosas que le gustan de Bun pero que pnpm no tiene. La lista es básicamente soporte nativo para TS, un bundler estilo Vite y un test runner estilo Vitest/Jest.
Excepto el bundler, Node ya tiene todo eso. El test runner puede tener sintaxis distinta, pero TypeScript funciona “sin más” por defecto y el test runner integrado es perfectamente usable. No sé si de verdad haya tanto motivo para lamentar a Bun.
También se puede decir que el marketing muy hábil de Jarred Sumner en redes sociales generó buena parte del impulso actual. Hizo que la gente hablara del tema, y eso también mejoró Node.
Además, como Bun empujó con fuerza para soportar la mayor cantidad posible de APIs de Node, Deno también se movió hacia ese mismo nivel de compatibilidad, y ahora la mayor parte del código en la práctica está menos atada al runtime. No sé si usaría Bun en producción real, pero me alegra que haya existido porque hizo avanzar muchísimo al ecosistema JavaScript.
node main.tssin dependencias?Si soy sincero, no he usado tanto Bun más allá de probar módulos de vez en cuando. En el día a día uso más que nada Deno, y en los últimos años también he escrito muchos scripts de shell en Deno.
Su usabilidad actual me ha gustado bastante, y la forma de referenciar módulos directamente desde un repositorio me parece especialmente buena para scripts de shell.
Aun así, me preocupa si va a poder lograr suficiente monetización manteniendo las funciones abiertas, o al menos si va a permitir que otros lo repliquen. Así que entiendo parte de la preocupación.
https://github.com/oven-sh/bun/issues/17723
Si al menos arreglaran esto, creo que lo probaría una vez en backend...