Burbuja de la IA y rescate: qué cambia para quien usa Bun

Cuando la palabra "bailout" aparece junto a "IA" en un documento del Congreso estadounidense, el dev que paga facturas de API debería levantar la cabeza. Eso acaba de pasar: los representantes Greg Casar y Maxine Waters lideran una resolución demócrata contra cualquier rescate público de la burbuja de la IA, y el tema llega más cerca de tu código de lo que parece. Sobre todo si usas Bun.

¿Qué propone la resolución contra el rescate de la IA?

La idea central cabe en una frase: si la burbuja de la IA estalla, el dinero público no debe salvar a las big tech, y la prioridad tiene que ser proteger a la población. El anuncio salió por el Congressional Progressive Caucus. Vale la pena leer el texto original para ver los términos exactos y quién firmó.

Dos salvedades antes de que alguien salga gritando:

• Nadie aprobó un rescate. La discusión es preventiva.
• Las resoluciones de este tipo suelen marcar una posición política. Rara vez mueven dinero por sí solas.

Así que nada cambia en tu package.json mañana. Lo que llama la atención es otra cosa: la pregunta "¿y si quiebra?" salió de Twitter y entró en el Legislativo.

¿Por qué hablar de bailout ahora?

El sector gasta a un ritmo que asusta hasta a quienes lo apoyan. Solo el proyecto Stargate se anunció, en enero de 2025, con la meta de hasta US$ 500 mil millones en infraestructura. Buena parte de ese dinero se convierte en data centers y GPUs, activos caros que pierden valor rápido.

En noviembre de 2025, la CFO de OpenAI, Sarah Friar, mencionó la idea de un "backstop" del gobierno para financiar infraestructura. La repercusión fue mala, ella se retractó, y Sam Altman dijo públicamente que la empresa no quería garantías del gobierno. Aun así, la palabra quedó en el aire.

Quien vivió 2008 conoce el guion. El TARP autorizó hasta US$ 700 mil millones para estabilizar el sistema financiero. En 2023, el gobierno estadounidense garantizó los depósitos de Silicon Valley Bank, y muchas startups pudieron pagar la nómina solo por eso. "Demasiado grande para quebrar" es una frase vieja que aprende trucos nuevos en cada ciclo.

No sé si es una burbuja, y desconfío de quien dice saber la fecha del estallido. Pero el plan de contingencia cuesta poco, y de eso quiero hablar.

¿Qué tiene que ver Bun con la burbuja de la IA?

Más de lo que imaginas. En diciembre de 2025, Anthropic compró Bun. Claude Code se distribuye como un ejecutable hecho con Bun, así que la compra tuvo lógica: la empresa necesitaba el runtime y se trajo al equipo. El proyecto siguió siendo open source, con licencia MIT.

En ese momento, la noticia fue buena para quien usa Bun. Antes, la pregunta incómoda era cómo una startup de runtime iba a ganar dinero. La respuesta pasó a ser: ahora paga una empresa de IA.

Solo que esa respuesta cambia un riesgo por otro. Antes, Bun dependía de la caja de la propia Oven. Hoy depende de las prioridades de una empresa de un sector cuyo financiamiento llegó a la agenda del Congreso.

No estoy prediciendo que Anthropic va a quebrar o a abandonar el proyecto. Estoy diciendo que tu runtime ahora tiene exposición indirecta al mercado de la IA, aunque tu app no llame a ningún modelo. Eso es nuevo, y poca gente lo incluyó en la cuenta.

La licencia MIT protege el código. No le paga a quien mantiene el código.

La MIT garantiza que se puede hacer un fork. No garantiza que exista gente capaz de mantener un runtime escrito en Zig, con JavaScriptCore por debajo, y a la velocidad de hoy. Un fork en GitHub es fácil. Mantener el fork durante tres años es el trabajo de verdad.

El riesgo real para tu proyecto es el precio

Que un runtime muera de un día para otro es el escenario menos probable. Lo más probable es que cambie el precio de las APIs.

Mucha gente sospecha que parte del precio actual todavía está subsidiada por la carrera por el mercado. Si el dinero se encarece, alguien va a cobrar la cuenta. Y un rescate público vetado, como quiere la resolución, hace ese ajuste más directo.

Haz la cuenta con un número hipotético. Tu producto hace 1 millón de llamadas al mes, a US$ 0,002 cada una. Son US$ 2.000. Si el proveedor duplica el precio, son US$ 4.000, sin ningún cliente nuevo. Si tu margen era de US$ 1.500, pasaste a pagar por trabajar.

Ahora, lo que yo haría en el código, sin drama.

¿Cómo proteger tu stack con Bun sin reescribir nada?

Primero, averigua el tamaño de tu acoplamiento. Toma diez segundos:

grep -rnE "Bun\.|bun:" src/ | wc -l

Si da 4, cambias de runtime en una tarde. Si da 400, la decisión de salir ya se tomó por ti. Yo sigo usando Bun.serve y bun:sqlite donde tiene sentido. Solo dejo ese uso en pocos archivos, para que el resto de la app no sepa en qué runtime corre.

Segundo, pon el modelo detrás de una sola función:

// ai.ts: el resto de la app solo conoce esta función
type Provider = (prompt: string) => Promise<string>

export async function complete(prompt: string, providers: Provider[]) {
  for (const provider of providers) {
    try {
      return await provider(prompt)
    } catch (err) {
      console.error('el provider falló', err)
    }
  }

  throw new Error('ningún provider respondió')
}

Son pocas líneas, sin framework y sin capa de abstracción para impresionar a un colega. Cuando un proveedor suba el precio o se caiga, cambias el orden del array. Si el SDK de un proveedor está esparcido por 60 archivos, no tienes una integración, tienes un matrimonio sin acuerdo prenupcial.

Tercero, congela lo que instalas:

bun install --frozen-lockfile

Esto no es paranoia. Con el lockfile en el repositorio, el CI falla si alguien cambia una dependencia sin querer, y tú decides cuándo actualizar. También tiene sentido fijar una versión conocida de Bun en el Dockerfile, en lugar de latest.

Por último, registra el costo por funcionalidad. Saber que la factura total fue de US$ 2.000 ayuda poco. Saber que el resumen automático consume el 70% de ella permite tomar una decisión.

¿Debo cambiar Bun por Node por esto?

No. Cambiar de runtime por una resolución sería una exageración graciosa. Bun sigue siendo rápido, bun test sigue siendo excelente, y correr TypeScript sin configuración sigue siendo una de las mejores cosas que le pasaron a mi rutina.

Lo que cambia es el peso de la pregunta a la hora de elegir. Para una API nueva, yo seguiría eligiendo Bun. Para un sistema que debe durar diez años, con un equipo grande y un contrato enterprise, tendría una conversación más larga, y Node gana puntos por tener una gobernanza más distribuida.

Lo que me llevo de esta historia

Mi opinión: quien acumula la ganancia en la subida debe asumir la pérdida en la caída. Si la cuenta de la burbuja de la IA cae sobre el contribuyente, el mensaje para el mercado es pésimo, y en ese punto estoy del lado de la resolución. Si va a avanzar, es otra historia.

Para el dev, el mensaje es menos político. Toda dependencia tiene un balance financiero detrás, y ahora eso incluye el runtime. Usa Bun, usa IA, exige valor de ambos. Solo mantén la puerta de salida sin llave. Así intento armar mis proyectos.

Mi runtime ahora tiene exposición al mercado de la IA, y casi nadie lo incluyó en la cuenta.

El Congreso estadounidense ya discute una resolución contra el rescate público de la burbuja de la IA. Nadie aprobó ningún bailout, pero la pregunta "¿y si quiebra?" salió de Twitter y entró en el Legislativo.

Desde que Anthropic compró Bun, el runtime depende de las prioridades de una empresa de ese sector, aunque tu app no llame a ningún modelo.

La licencia MIT protege el código. No le paga a quien mantiene el código.

No voy a cambiar Bun por Node por esto. El riesgo más probable es otro: que suba el precio de las APIs y tu margen desaparezca sin ningún cliente nuevo.

Por eso dejo el uso de Bun en pocos archivos, pongo el modelo detrás de una sola función, congelo el lockfile y mido el costo por funcionalidad.

Usa Bun, usa IA, solo mantén la puerta de salida sin llave. Escribí el paso a paso en el blog, y quiero saber: ¿cuántos archivos tendría que cambiar tu proyecto para salir?

#Bun #InteligenciaArtificial #JavaScript #Tecnologia #DesarrolloDeSoftware