Bun y LLMs: por qué la percepción sobre la IA está tan dividida

En la misma semana, dos devs a los que respeto me dijeron cosas opuestas. El primero me contó que un agente escribió una feature entera suya en Bun, con tests, y él solo la revisó. El segundo juró que la IA "no sirve ni para un CRUD", porque el modelo se inventó un import que no existe. Los dos decían la verdad. Y justo de eso se quejó Andrej Karpathy en un post reciente en X: la distancia entre lo que la gente cree que los LLMs pueden hacer está creciendo, no achicándose.

Este texto trata de esa distancia, usando Bun como termómetro. Tiene sentido: es un runtime que cambia rápido, que hoy pertenece a Anthropic y que corre por debajo de una de las herramientas de IA para código más usadas.

Lo que señala Karpathy

La idea central es simple. Antes, casi todo el mundo usaba lo mismo: un chat, un modelo, un prompt. Las opiniones variaban, pero la experiencia de base era parecida.

Hoy ya no es así. Hay gente que usa un modelo gratuito en una pestaña del navegador, pega un trozo de código y copia la respuesta de vuelta. Y hay gente que corre un agente en la terminal, con acceso al repositorio, que ejecuta tests, lee errores y corrige solo durante media hora. Son productos distintos que llevan el mismo nombre: "IA".

Cuando esas dos personas discuten, cada una describe una herramienta distinta. Hablar de IA en el grupo del trabajo se volvió un debate de fútbol: cada uno vio un partido distinto y todos están seguros del marcador.

Quien probó la IA una vez en 2024 está peleando con un producto que ya no existe.

Por qué la percepción sobre los LLMs se aleja cada vez más

No creo que sea cuestión de que alguien sea tonto o esté deslumbrado. La distancia crece por motivos muy concretos:

• El modelo importa mucho. La diferencia entre el modelo de entrada y el de punta, en tareas de código con varios archivos, es enorme. Quien solo usó el gratuito tiene una muestra que no representa al resto.
• El entorno importa todavía más. Un buen modelo en un chat sin contexto se equivoca en un import. El mismo modelo dentro de un agente que lee el package.json y corre bun test corrige el import solo en el segundo intento.
• La opinión envejece rápido. Mucha gente se formó una opinión hace un año y medio y nunca volvió a probar. En ese tiempo, el producto cambió unas cuatro veces.
• El tipo de tarea lo cambia todo. Generar un endpoint es una cosa. Depurar una condición de carrera en un worker es otra. Los dos bandos generalizan a partir de su propio caso.

El resultado es que la conversación pública no sirve para nada. El hype dice que los devs desaparecen el año que viene. El escéptico dice que es un autocompletado con aires. Ninguno de los dos te ayuda a decidir si vale la pena usarlo mañana a las 9 en tu proyecto.

Bun es un buen termómetro para esto

Bun es un caso interesante por tres motivos.

Primero, cambia rápido. APIs como Bun.serve con routes, bun:sqlite, Bun.password y el cliente nativo de S3 y Postgres fueron llegando a lo largo de las versiones. Un modelo con conocimiento desactualizado, o sin acceso a la documentación, te va a sugerir Express con better-sqlite3. Funciona, pero tira por la borda el motivo por el que elegiste Bun.

Segundo, Anthropic compró Bun a finales de 2025, y Claude Code se distribuye como ejecutable de Bun. O sea, el runtime se volvió una pieza de infraestructura de una herramienta de IA. Eso no significa que los modelos conozcan mejor Bun por arte de magia. Significa que hay gente con muchos incentivos para que Bun funcione bien dentro de flujos de agentes.

Tercero, Bun tiene un ciclo de feedback muy corto. bun test arranca en milisegundos, sin configurar Jest, sin transpilar TypeScript aparte. Para un agente que necesita correr tests, leer el fallo y volver a intentar veinte veces, eso hace una diferencia real en el tiempo total.

Mira la diferencia en la práctica. Pedí lo mismo en dos escenarios: "endpoint que busca un usuario por id en SQLite". En el chat sin contexto, salió Express, better-sqlite3 y un app.listen. En el agente con acceso al repositorio, que ya usaba Bun, salió esto:

import { Database } from "bun:sqlite";

const db = new Database("app.db");
const findUser = db.query("SELECT id, name FROM users WHERE id = ?");

Bun.serve({
  routes: {
    "/api/users/:id": (req) => {
      const user = findUser.get(req.params.id);
      return user
        ? Response.json(user)
        : new Response("Not found", { status: 404 });
    },
  },
});

Cero dependencias nuevas. La query se prepara una sola vez. Ese es el tipo de diferencia que hace que un dev piense que la IA es inútil y otro piense que es genial. El modelo hasta pudo haber sido el mismo. El contexto fue distinto.

Cómo medir la capacidad del LLM en tu propio código

La salida para no caer en ninguno de los dos extremos es dejar de opinar y empezar a medir. Y se puede hacer con lo que ya tienes.

Arma un eval casero. No hace falta un framework. Toma de 5 a 10 tareas reales que ya resolviste en tu repositorio: un bug que te costó una tarde, un endpoint nuevo, una migración de schema. Para cada una, escribe el test que demuestra que está resuelta.

// evals/user-endpoint.test.ts
import { test, expect } from "bun:test";

test("devuelve 404 para un usuario inexistente", async () => {
  const res = await fetch("http://localhost:3000/api/users/999999");
  expect(res.status).toBe(404);
});

test("devuelve el usuario con id y name", async () => {
  const res = await fetch("http://localhost:3000/api/users/1");
  const body = await res.json();
  expect(body).toMatchObject({ id: 1, name: expect.any(String) });
});

Después, para cada tarea, crea una branch limpia, pásale la descripción al modelo o agente que quieres evaluar y corre:

bun test evals/

Anota tres cosas: si pasó o no, cuántas intervenciones tuyas hicieron falta y cuánto tiempo tomó. Repítelo cada vez que cambies de modelo o de herramienta. En una tarde tienes un dato que vale más que cien hilos en X.

Dos consejos que aprendí equivocándome:

1. Usa tareas que ya resolviste. Así sabes cómo se ve una buena solución y no te impresiona código que solo parece correcto.
2. Incluye al menos una tarea difícil de verdad. Si todas son CRUD, vas a concluir que la IA lo resuelve todo. No lo resuelve.

Qué cambia en tu flujo de trabajo

Si la distancia de percepción es real, la consecuencia práctica es que no puedes tercerizar tu opinión sobre la IA. Ni al influencer entusiasmado, ni al colega escéptico. Los dos describen su herramienta, no la tuya.

En el día a día, eso se traduce en algunos cambios pequeños:

• Escribe código que se verifique solo. Un buen test se volvió insumo para el agente, no solo seguridad para ti. Con Bun, correr tests cuesta tan poco que no hay excusa.
• Da contexto en lugar de un prompt ingenioso. Un CLAUDE.md o AGENTS.md que diga "este proyecto usa Bun, bun:sqlite y Bun.serve, no instales Express" resuelve la mitad de los errores tontos.
• Vuelve a evaluar cada pocos meses. Ponlo en el calendario. En serio. Tu opinión de marzo puede estar equivocada en octubre.
• En las discusiones del equipo, pregunta "¿qué herramienta y qué tarea?" antes de pensar en estar de acuerdo o no. Eso corta muchas peleas inútiles.

Y algo que no cambia: la revisión. El agente escribió, tú firmas. Si el código llega a producción con SQL concatenado porque "lo hizo la IA", la culpa sigue siendo tuya en el post-mortem.

Mi opinión

Creo que Karpathy tiene razón, y creo que la distancia va a seguir creciendo por un tiempo. Las herramientas de punta mejoran más rápido de lo que la percepción promedio logra seguir. Quien usa el mejor setup todos los días se va alejando cada vez más de quien probó una vez y se rindió.

Pero la solución es aburrida y está al alcance de cualquiera: medir en tu propio código, con tus propios tests. Bun lo facilita porque el ciclo es rápido y las herramientas ya vienen listas. No necesitas creerme a mí ni a nadie. Corre bun test y mira el resultado.

Así es como vengo probando la IA en mis proyectos con Bun y React Native. Si quieres ver dónde esto ya está funcionando de verdad, échale un vistazo a mis proyectos.

En la misma semana, un dev me dijo que la IA escribió una feature entera en Bun y otro juró que no sirve ni para un CRUD.

Los dos tenían razón. Solo que usaban herramientas completamente distintas con el mismo nombre: "IA".

Karpathy lo señaló: la distancia entre lo que la gente cree que los LLMs pueden hacer no deja de crecer. Un chat sin contexto se equivoca en un import. Un agente con acceso al repo lee el error y lo corrige solo.

Mi salida fue dejar de opinar y empezar a medir. Tomo de 5 a 10 tareas reales que ya resolví, escribo los tests y corro `bun test` cada vez que cambio de modelo.

Una tarde de eval casero vale más que cien hilos en X. Y la revisión sigue siendo mía: el agente escribe, yo firmo.

Escribí el paso a paso completo en el blog. ¿Ya mediste la IA en tu propio código?

#Bun #InteligenciaArtificial #LLM #DesarrolloDeSoftware #TypeScript