Anthropic y Bun: ¿el runtime seguirá el camino de Claude Code?

⏱️ Lectura: 13 min

El ecosistema JavaScript vive una de sus tensiones más interesantes desde que apareció la primera alternativa seria a Node.js. Bun, el runtime hiperveloz que prometía competir con Node sin las cicatrices de 16 años de retrocompatibilidad, ahora pertenece a Anthropic. La adquisición se concretó en diciembre de 2025 y, en aquel momento, el anuncio sonaba a noticia ideal: Bun mantendría su licencia MIT, el equipo continuaría intacto y la hoja de ruta no cambiaría. Pero en abril de 2026, una serie de incidentes con Claude Code —el agente de programación que se distribuye como binario de Bun— sembraron una duda incómoda en la comunidad: ¿está el runtime camino a la enshittification?

📑 En este artículo

1. Bun y Anthropic: qué pasó realmente en diciembre de 2025
2. La caída de Claude Code: del amor al deja vu
3. Los números detrás de la inquietud
   1. El factor pnpm: ¿adónde migran los desarrolladores?
4. Impacto y análisis: ¿qué cambia para los devs en LATAM?
5. Cómo evaluar el riesgo en tu propio stack
   1. 1. ¿Qué partes de Bun usás realmente?
   2. 2. ¿Cuál es tu superficie de exposición?
   3. 3. ¿Estás preparado para mantener un toolchain manual?
6. Lo que viene: forks, federalismo o consolidación
   1. Calendario probable
7. Preguntas frecuentes
   1. ¿Qué es exactamente la enshittification y por qué se aplica al caso Bun?
   2. ¿Bun sigue siendo open source después de la adquisición?
   3. ¿Puedo migrar fácilmente de Bun a pnpm si solo uso instalación de paquetes?
   4. ¿Qué pasa con el bundler y el test runner si dejo Bun?
   5. ¿Hay un fork comunitario de Bun?
   6. ¿Esto cambia algo para Node.js?
8. Referencias

La pregunta no es retórica. La relación bun anthropic ya no es la de un patrocinador y un proyecto open source: es la de un dueño y un activo estratégico. Cuando Anthropic compró Bun, parte del argumento público fue precisamente ese alineamiento de incentivos —si Bun se rompe, Claude Code se rompe—. Sin embargo, el último trimestre demostró que las prioridades de un producto SaaS no siempre coinciden con las de un runtime usado por miles de desarrolladores que no son clientes pagos de la empresa.

Bun y Anthropic: qué pasó realmente en diciembre de 2025

En diciembre de 2025, Anthropic anunció la compra de Oven Inc., la empresa detrás de Bun. Las condiciones públicas fueron favorables: Bun seguiría siendo open source bajo licencia MIT, el mismo equipo permanecería al frente y la hoja de ruta seguiría enfocada en herramientas JavaScript de alto rendimiento y compatibilidad con Node.js. Para muchos, era un cierre lógico. Bun era un proyecto financiado con capital de riesgo y la pregunta de “cómo se monetiza un runtime” siempre flotaba en el ambiente. Convertirse en infraestructura de un producto comercial enorme parecía la salida natural y, hasta cierto punto, la mejor casa posible para el proyecto.

El producto en cuestión era —y sigue siendo— Claude Code, el agente de programación de Anthropic que se distribuye como ejecutable de Bun. La integración no era una metáfora: cada instalación de Claude Code embebía Bun. Si Bun fallaba, Claude Code fallaba. Esa simbiosis fue, durante meses, la garantía implícita de que Anthropic invertiría en mantener el runtime estable y rápido. La realidad de 2026, sin embargo, fue más compleja.

En abril, un encadenado de problemas en Claude Code generó una ola de quejas: degradación de calidad en sesiones largas, comportamientos extraños cuando se invocaba con argumentos sospechosos, cobros adicionales por terceros como OpenClaw, y un soporte que se volvió cada vez más opaco. Anthropic publicó un postmortem técnico reconociendo varios errores —entre ellos un default de razonamiento más bajo, un bug de sesiones obsoletas y un cambio de prompt que afectaba la calidad del código generado—. Fue, irónicamente, la primera vez que Anthropic admitía abiertamente que la culpa era suya.

La caída de Claude Code: del amor al deja vu

Claude Code llegó al mercado como una de las herramientas más impresionantes de su categoría. Leía proyectos completos, hacía ediciones quirúrgicas, ejecutaba comandos, corregía sus propios errores y mantenía contexto a lo largo de tareas largas. Combinado con la calidad de los modelos Claude Opus, era difícil encontrar un competidor que ofreciera la misma experiencia integrada en CLI. Equipos enteros adoptaron el flujo de trabajo agentic con Claude Code como pieza central de su productividad.

Lo que cambió en los últimos meses no fue una sola decisión, sino el patrón. Primero, los desarrolladores notaron que el agente “se volvía tonto” después de cierto número de turnos. Después llegaron los reportes de cobros confusos: instalar herramientas externas como OpenClaw activaba cargos adicionales que no estaban claramente comunicados. Y más tarde, la crónica más extraña de todas: incluso tener la palabra OpenClaw en el historial de git podía hacer que Claude Code rechazara solicitudes o cobrara extra. El streamer Theo demostró el comportamiento en un repositorio vacío llamando a claude -p "hi" y mostrando cómo un commit con un blob JSON que mencionaba OpenClaw era suficiente para disparar la conducta anómala.

⚠️ Ojo: el patrón observado —donde texto en el git log altera el comportamiento del agente— sugiere que las reglas de cobro y bloqueo se aplican sobre el contexto crudo del repositorio, no sobre intenciones explícitas del usuario. Para un runtime serio, ese tipo de decisiones de producto es un terreno minado.

Más allá del incidente puntual, el problema de fondo es de cultura. Esos comportamientos no se descubren si el equipo dogfoodea su producto. Y si la empresa propietaria de Bun no dogfoodea Claude Code —que corre sobre Bun—, ¿qué garantiza que sí dogfoodee el runtime mismo? Esa es la pregunta que dio nombre al post original que desató el debate.

Los números detrás de la inquietud

El malestar no es anecdótico. Las cifras lo respaldan:

• Diciembre 2025: Anthropic anuncia la adquisición de Bun. Cláusulas públicas: licencia MIT preservada, equipo intacto, roadmap sin cambios.
• Abril 2026: Claude Code recibe una avalancha de reportes negativos en GitHub, X y Hacker News. El postmortem oficial admite tres causas técnicas en el “product layer”.
• Millones de usuarios: la base instalada de Claude Code, todos ejecutando un binario de Bun, según el propio comunicado de adquisición.
• 41% del código mundial se genera con asistencia de IA en 2026, según el último Stanford AI Index. La presión sobre los CLIs de coding nunca había sido tan alta.
• Cero respuestas oficiales de Anthropic ante las preguntas concretas sobre cómo van a aislar las decisiones de producto de Claude Code de la dirección técnica de Bun.

El factor pnpm: ¿adónde migran los desarrolladores?

El autor original que destapó el debate, Will WJ, anunció que vuelve a pnpm. La decisión es interesante porque pnpm no reemplaza a Bun: pnpm es un gestor de paquetes, mientras que Bun es runtime, gestor, bundler y test runner integrados. La migración implica volver a ensamblar un toolchain con piezas separadas: pnpm para paquetes, vitest para tests, Vite para bundling, tsx o tsc para TypeScript. Pero para muchos desarrolladores, esa fragmentación es un precio aceptable a cambio de no depender del rumbo corporativo de una sola empresa.

Impacto y análisis: ¿qué cambia para los devs en LATAM?

Para los equipos de Latinoamérica, esta historia importa por tres razones. Primero, muchas startups en la región adoptaron Bun en 2024 y 2025 precisamente por su velocidad: instalaciones que tardaban minutos con npm pasaban a segundos con Bun, lo que se traduce en pipelines de CI más baratos y feedback más rápido. Segundo, Claude Code es uno de los agentes más usados en equipos pequeños donde una sola licencia rinde el trabajo de un junior. Y tercero, la enshittification es un fenómeno global: lo que pasa hoy en Anthropic puede repetirse mañana en cualquier ecosistema controlado por una empresa con métricas de monetización agresivas.

El riesgo concreto para Bun no es que el código se degrade —el equipo técnico sigue siendo el mismo y excelente—, sino que las decisiones de producto empiecen a filtrarse al runtime. Un ejemplo hipotético: Anthropic podría decidir que Claude Code requiere ciertas características exclusivas en Bun que aceleran su agente, pero que rompen casos de uso de la comunidad. O podría priorizar bugs que afectan a Claude Code antes que bugs reportados por usuarios externos. Nada de esto ha pasado todavía, pero la dirección apunta hacia ahí y conviene tenerlo en el radar.

📌 Nota: la licencia MIT garantiza que cualquier comunidad pueda forkear Bun si Anthropic toma decisiones que la mayoría considere abusivas. Es la red de seguridad clásica del open source —y la razón por la que estos debates rara vez terminan en tragedia—.

Cómo evaluar el riesgo en tu propio stack

Si tu equipo usa Bun en producción, hay tres preguntas concretas que conviene responder antes de cambiar de runtime o duplicar esfuerzo migrando.

1. ¿Qué partes de Bun usás realmente?

Si solo usás bun install, la migración a pnpm es trivial y reversible. Si dependés del bundler, del test runner y del soporte nativo de TypeScript, la cosa se complica.

# macOS / Linux
npm install -g pnpm
rm -rf node_modules bun.lockb
pnpm install

# Windows (PowerShell)
npm install -g pnpm
Remove-Item -Recurse -Force node_modules, bun.lockb
pnpm install

# Verificar qué scripts del package.json invocan Bun
grep -E "bun (run|install|test|build)" package.json

2. ¿Cuál es tu superficie de exposición?

Un script CLI casero que corre con Bun localmente tiene una superficie distinta a un servicio en producción que sirve millones de requests con bun --hot. El segundo caso justifica monitoreo activo de releases y un plan de migración pre-armado. El primero, en general, no.

3. ¿Estás preparado para mantener un toolchain manual?

Bun ofrece un valor real: una sola dependencia, una sola CLI, una sola lockfile. Volver a un toolchain manual implica gestionar más versiones, más configuraciones y más superficies de fallo. Para equipos pequeños, eso puede ser caro en horas-persona.

Lo que viene: forks, federalismo o consolidación

La historia del open source ofrece tres precedentes que pueden anticipar el destino de Bun. El primero es OpenSearch, el fork de Elasticsearch que apareció cuando Elastic cambió su licencia. El segundo es OpenTofu, fork de Terraform después de la decisión de HashiCorp de migrar a BSL. El tercero es Valkey, fork de Redis tras un cambio similar. Los tres forks demuestran que la comunidad open source ya tiene anticuerpos: cuando una empresa cruza el límite, se forkea y se sigue.

Bun no está en ninguno de esos escenarios todavía. Anthropic no ha cambiado la licencia, no ha bloqueado contribuciones externas y no ha quitado funcionalidades. La preocupación es preventiva, no reactiva. Pero el hecho de que ya se discuta abiertamente —en blogs, en X, en Hacker News— es una señal de que la comunidad está atenta y que el costo reputacional de un movimiento equivocado sería alto.

💡 Tip: si tu CI depende de Bun, mantené un job paralelo con pnpm + Node como póliza de seguro. Cuesta poco, te da una ruta de salida verificada el día que la necesites y suele revelar bugs específicos del runtime que de otra forma pasarían inadvertidos.

Calendario probable

Lo más realista es esperar que en los próximos 12 meses ocurran tres cosas. Primero, Anthropic resolverá el desorden de Claude Code y la conversación bajará en intensidad. Segundo, alguna decisión técnica de Bun favorecerá un caso de uso de Claude Code y generará fricción menor con la comunidad. Tercero, aparecerán dos o tres voces influyentes proponiendo un fork preventivo si el patrón se repite. Ninguno de estos escenarios es catastrófico per se, pero el conjunto define la trayectoria.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué es exactamente la enshittification y por qué se aplica al caso Bun?

El término popularizado por Cory Doctorow describe el deterioro progresivo de plataformas que primero atraen usuarios, luego priorizan a sus clientes corporativos y finalmente extraen valor a expensas de ambos. En el caso Bun, la preocupación es que el runtime se subordine al rumbo monetizado de Claude Code y deje de optimizarse para la comunidad amplia que no paga suscripciones a Anthropic.

¿Bun sigue siendo open source después de la adquisición?

Sí. La licencia MIT se mantiene y el código sigue disponible públicamente en GitHub. La preocupación no es la licencia presente, sino la dirección estratégica futura y la posibilidad de que decisiones de producto contaminen la dirección técnica.

¿Puedo migrar fácilmente de Bun a pnpm si solo uso instalación de paquetes?

Sí. Eliminás bun.lockb, instalás pnpm globalmente y corrés pnpm install. La compatibilidad con package.json es completa para la mayoría de proyectos y rara vez vas a notar diferencias funcionales.

¿Qué pasa con el bundler y el test runner si dejo Bun?

Necesitás reemplazar piezas: Vite para bundling, vitest para tests, tsx o el compilador de TypeScript para ejecución directa. Es más mantenimiento, pero el ecosistema está maduro y bien documentado.

¿Hay un fork comunitario de Bun?

No hay un fork público con tracción al momento de redactar este artículo. La comunidad observa, pero la situación todavía no justifica ese paso. Mientras Anthropic no cambie la licencia ni rompa la compatibilidad, el incentivo para forkear es bajo.

¿Esto cambia algo para Node.js?

Sí. Node.js gana legitimidad como opción “neutral” porque es un proyecto sin dueño corporativo único, gestionado por la OpenJS Foundation. Esa neutralidad es exactamente lo que la comunidad valora cuando Bun pierde su independencia.

Referencias

• I am worried about Bun (wwj.dev) — artículo original que desató el debate sobre la adquisición de Bun por Anthropic.
• Bun.sh — sitio oficial del runtime con documentación, releases y benchmarks.
• pnpm.io — documentación oficial del gestor de paquetes alternativo más popular del ecosistema.
• Anthropic — empresa propietaria de Bun y de Claude Code.
• Hacker News — discusión continua sobre el rumbo de Bun y Claude Code en la comunidad técnica.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.