Los benchmarks de IA ignoran el 90% del trabajo: haz tu propia prueba con Bun

Según Mercor, el 90% de las horas trabajadas en Estados Unidos se van en tareas que los benchmarks de IA no cubren bien. Seguro ya viste el gráfico de turno: un modelo nuevo bate un récord en alguna prueba y todo el mundo lo celebra. El problema es que esa prueba mide una parte muy pequeña de lo que hacemos en el día a día. Este texto trata de esa distancia entre los benchmarks de IA y el trabajo real. También de cómo usar Bun para medir lo que de verdad te importa.

Qué midió Mercor en los benchmarks de IA

La investigación salió en el Labor Index de Mercor. La idea es fácil de explicar. Se toman las tareas que la gente hace en el trabajo, se mide cuánto tiempo ocupan y se revisa qué benchmarks evalúan cada una.

El resultado incomoda. La mayor parte de las horas de trabajo cae en tareas que ningún benchmark popular evalúa bien. Las pruebas se concentran donde es fácil poner nota: preguntas de opción múltiple, problemas de matemáticas con una sola respuesta, funciones aisladas con su test unitario ya listo.

El trabajo de verdad está en otro lado. Está en las reuniones, en decidir con información incompleta, en leer código ajeno, en negociar alcance. Está en entender qué quiso decir el cliente cuando escribió "hazlo más moderno".

Esto no significa que la IA no sirva para esas tareas. Significa que nadie lo está midiendo. Son cosas muy distintas.

Por qué importa si programas

Solemos creernos la excepción. Al fin y al cabo, programar es el área con más benchmarks que existe: SWE-bench, HumanEval, LiveCodeBench, Terminal-Bench y una docena más que salieron el mes pasado.

Pero piensa en tu última semana. ¿Cuánto tiempo pasaste escribiendo código nuevo a partir de una descripción clara? ¿Y cuánto tiempo se fue en esto?

• averiguar por qué el deploy funciona en staging y se rompe en producción;
• leer un PR de 40 archivos y decidir si lo apruebas;
• migrar una tabla de PostgreSQL sin tumbar nada;
• explicarle a producto por qué ese "cambio rápido" lleva dos semanas.

Los benchmarks de código suelen evaluar la parte del trabajo que ya viene con un enunciado bien escrito. En la vida real, armar el enunciado es la mitad del trabajo.

También está el problema de la contaminación. Muchos benchmarks públicos terminan filtrándose en el entrenamiento de los modelos. Un modelo que saca buena nota en una prueba que ya vio se está aprendiendo el examen de memoria. Y tú no sabes cuánto de eso pasó.

El benchmark dice lo que el modelo sabe hacer en el examen. Tu backlog dice lo que necesitas que haga.

Qué cambia en tu flujo de trabajo

La conclusión práctica no es "ignora los benchmarks". Sirven como filtro grueso. Un modelo que va mal en todos probablemente también irá mal en tu proyecto.

La conclusión es otra: para decidir qué modelo usar en tu código, necesitas una prueba tuya. Un eval pequeño, hecho con tareas reales de tu repositorio. Lo corres cada vez que sale un modelo nuevo o cuando cambias el prompt de tu agente.

Suena a trabajo de un equipo de investigación, pero no lo es. Si tienes un test runner, ya tienes el 80% de la infraestructura. Y aquí Bun ayuda bastante. bun test arranca rápido, corre TypeScript sin configuración y trae Bun.spawn y Bun.file listos para el resto.

Cómo armar tu propio eval con Bun

La estructura que uso es muy simple. Cada caso es un JSON con el prompt y el archivo de test que el código generado tiene que pasar.

{
  "nombre": "paginación por cursor en el endpoint de pedidos",
  "prompt": "Implementa paginación por cursor en listarPedidos(). Hoy usa OFFSET.",
  "archivo": "src/pedidos.ts",
  "prueba": "src/pedidos.test.ts"
}

Lo importante es que los casos salgan de tu historial. Toma tareas que ya resolviste de verdad: ese bug de zona horaria, el refactor del servicio de pagos, la query que hacía N+1. Ya tienes la respuesta correcta y el test que demuestra que funciona.

Después, un archivo de test que recorre los casos, le pide el código al modelo, lo aplica en una copia del proyecto y corre los tests originales:

// evals/codigo.test.ts
import { test, expect } from "bun:test";
import { Glob, $ } from "bun";
import { generarCodigo } from "./modelo";

const casos = await Array.fromAsync(new Glob("evals/casos/*.json").scan("."));

for (const ruta of casos) {
  const caso = await Bun.file(ruta).json();

  test(caso.nombre, async () => {
    const tmp = `/tmp/eval-${crypto.randomUUID()}`;
    await $`cp -r fixture ${tmp}`;

    const codigo = await generarCodigo(caso.prompt, caso.archivo);
    await Bun.write(`${tmp}/${caso.archivo}`, codigo);

    const proc = Bun.spawn(["bun", "test", caso.prueba], { cwd: tmp });
    expect(await proc.exited).toBe(0);
  }, 120_000);
}

generarCodigo es solo un fetch a la API del modelo que quieres evaluar. Cambia el modelo con una variable de entorno y corre:

MODELO=modelo-a bun test evals/
MODELO=modelo-b bun test evals/

Al final tienes un marcador del tipo "pasaron 17 de 20 casos" para cada modelo. Ese número pesa más en tu decisión que cualquier ranking público, porque salió de tu código.

Algunos consejos que aprendí equivocándome:

• Empieza con 10 casos. Diez casos reales valen más que cien inventados. Ya los ampliarás después.
• Corre cada caso más de una vez. Los modelos no son deterministas. Si pasa 2 de cada 3 veces, anótalo.
• Aísla el entorno. El código generado puede correr un rm en el lugar equivocado. Usa un directorio temporal, un contenedor o un sandbox. No corras esto en tu repositorio principal.
• Guarda las salidas. Cuando un caso falle, vas a querer leer lo que escribió el modelo. No solo ver un rojo en la terminal.

¿Y las tareas que no caben en un test?

Esa es la objeción honesta, y es justo el punto de la investigación de Mercor. Revisar un PR, diseñar una arquitectura y decidir qué no hacer no se convierten fácilmente en un expect().toBe().

Se puede uno acercar. Para revisión de código, arma casos con PRs viejos que tenían un bug conocido y mira si el modelo señala el problema. Para decisiones de arquitectura, guarda el contexto de una decisión que ya tomaste y compara el razonamiento del modelo con el tuyo. Aquí la nota es manual. Lees y marcas "ayudó", "no ayudó" o "estorbó".

¿Da trabajo? Sí. Pero es el mismo tipo de trabajo que harías para evaluar a un dev junior que entra al equipo. Nadie contrata a alguien solo porque sacó buena nota en un examen de opción múltiple. Bueno, nadie debería.

Mi opinión sobre los benchmarks de IA

La investigación de Mercor me parece más útil que la mitad de los lanzamientos de modelos de este año. Justamente porque no vende nada. Solo muestra hasta dónde no llega la regla.

Mi lectura es que tercerizamos la evaluación a quien tiene interés en mostrar números bonitos. Quien lanza el modelo elige el benchmark, y el benchmark elige la tarea fácil de medir. Nadie necesita mentir para que el resultado salga distorsionado.

La salida está al alcance de cualquier dev: una carpeta evals/, veinte casos de tu historial y un bun test. Se arma en una tarde y te ahorra meses de "creo que este modelo es mejor". Si quieres ver cómo aplico esto en proyectos reales, échale un vistazo a mis proyectos.

Según Mercor, el 90% de las horas de trabajo se van en tareas que ningún benchmark de IA mide bien.

Las pruebas se quedan donde es fácil poner nota: opción múltiple, matemáticas con respuesta única, función aislada.

Pero mi día real es leer un PR de 40 archivos, migrar una tabla sin tumbar nada y entender qué quiso decir el cliente con "hazlo más moderno".

Por eso dejé de elegir modelo por el ranking de la semana. Armé una carpeta evals/ con 20 tareas que ya resolví de verdad y lo corro todo con bun test.

"17 de 20 pasaron" en mi código vale más que cualquier gráfico de lanzamiento.

Escribí en el blog cómo armar el tuyo en una tarde. Si ya haces algo parecido, cuéntame cómo lo mides.

#InteligenciaArtificial #Bun #DesarrolloDeSoftware #LLM #TypeScript