Qué modelo de IA usar para programar, según el tipo de tarea

Cada pocas semanas sale un modelo nuevo, alguien publica una tabla de benchmarks y durante tres días parece que la respuesta ha cambiado. Luego vuelves a tu trabajo y la pregunta sigue siendo la misma de siempre: para esto que tengo delante, ¿cuál uso?

Los benchmarks no la responden. No porque estén mal hechos, sino porque miden otra cosa.

Dos números del mismo modelo, en el mismo examen

El ejemplo más claro lo dio el último lanzamiento de OpenAI. En ARC-AGI-3, GPT-6 Astra puntúa 62,7 %. Y también puntúa 99,9 %.

Los dos son ciertos y los publica la misma fuente, ARC Prize. La diferencia está en el andamiaje con el que se ejecuta la prueba:

Harness estándar → 62,7 %. Es el entorno mínimo, igual para todos los modelos, pensado para poder compararlos entre sí.

Adaptador del proveedor → 99,9 %. Aquí el modelo usa las funciones de gestión de contexto que su fabricante ha diseñado para él: conserva el estado de razonamiento entre llamadas y compacta la conversación cuando se alarga.

Mismo modelo. Mismo examen. Treinta y siete puntos de diferencia según lo que le montes alrededor.

Eso debería cambiar cómo lees cualquier comparativa. Cuando ves un número, no estás viendo la capacidad del modelo: estás viendo la capacidad del modelo dentro de un sistema concreto. Y el sistema en el que tú lo vas a usar no es ese.

Es la misma idea que escribí sobre n8n hace unos días, un piso más arriba: la pieza que eliges importa menos de lo que parece, y lo que construyes alrededor importa mucho más de lo que nadie cuenta.

Lo que miden los índices independientes

Si dejas los números del fabricante y miras los de terceros, el panorama se aplana bastante. Artificial Analysis, que evalúa modelos de forma independiente, publica estos:

Índice de inteligencia general → Astra 61, el modelo al que sustituye 61, Claude Fable 5.1 en 66.

Índice de agentes de código → Astra 67, Fable 5.1 en 70.

Es decir: en inteligencia general el modelo nuevo empata con el que reemplaza, y ambos van por debajo de su competencia directa. En código, la diferencia tampoco es la que sugieren los titulares.

Donde sí hay un salto grande es en tareas largas y autónomas. En Terminal-Bench, la propia OpenAI reporta 57,9 % frente al 37,3 % de su modelo anterior. Eso no es marketing: es una capacidad nueva y real. Solo que es una capacidad concreta, no una superioridad general.

Y luego está la factura

Astra cuesta 10 $ por millón de tokens de entrada y 50 $ por millón de salida. Dos veces y media lo que costaba su predecesor.

Lo interesante es que consume menos tokens que el modelo anterior para resolver lo mismo. Gasta menos y aun así te sale más caro, porque la subida de precio se come la mejora de eficiencia. Artificial Analysis lo cuantifica: en tareas de inteligencia general, alrededor de un 75 % más caro por tarea completada.

Esta distinción — coste por token contra coste por tarea terminada — es la que más me ha servido a la hora de decidir, y es la que casi nunca aparece en las comparativas.

Mi prueba, y lo que encontré

Cada vez que sale un modelo nuevo lo pruebo contra lo que ya tengo funcionando. No con un benchmark: con un encargo real, pequeño, de los que hago a menudo.

Esta vez monté la misma automatización dos veces, una con Astra y otra con Claude Fable 5.1. Mismo objetivo, mismas instrucciones de partida.

Astra va más por libre. Coge el encargo y tira sin pedir permiso, que es exactamente lo que promete. El problema apareció al final: se dejó cosas a medias, y hubo que volver a pedírselas por separado para dar el trabajo por terminado.

Fable ejecuta y, cuando encuentra algo que se sale de lo que le has dicho, para y pregunta. Avanza menos por su cuenta, pero lo que entrega está cerrado.

¿Cuál es mejor? No tengo una respuesta, y he llegado a la conclusión de que no la hay. Son dos formas distintas de entender qué es ayudar.

Lo que sí saqué en claro es esto: la autonomía no sale gratis. Lo que te ahorras en instrucciones por delante lo pagas revisando por detrás. Si el trabajo de revisión es mayor que el que te ahorraste, has perdido tiempo aunque el modelo parezca más capaz.

Entonces, ¿cuál para qué

Con eso, mi criterio actual. No es una tabla de puntuaciones: es una forma de mirar el encargo antes de elegir.

Cuando el radio de daño es pequeño, prefiero autonomía. Prototipos, exploración, código que va a un entorno de pruebas, scripts que corro yo y reviso yo. Aquí que el modelo tire solo compensa: si se equivoca, lo tiro y vuelvo a empezar, y el coste de un error es cero.

Cuando la tarea toca algo que no se puede deshacer, prefiero que pregunte. Migraciones de datos, cambios en producción, cualquier cosa que borre o sobrescriba. Aquí un modelo que decide por su cuenta es un riesgo, no una ventaja, por mucho que puntúe más alto.

Cuando el encargo es largo y de varios pasos, gana el que mantenga el hilo. Es donde más ha cambiado el panorama este año y donde más merece la pena probar el modelo nuevo, porque es justo la capacidad que están mejorando.

Cuando el volumen es alto y repetitivo, decide el coste por tarea. No el precio por token, ni la puntuación. Cuánto cuesta que una unidad de trabajo esté terminada y revisada. Muchas veces gana el modelo más barato y algo peor, porque la diferencia de calidad no compensa el multiplicador.

Cuando lo que necesitas es criterio y no producción, da bastante igual cuál uses. Ninguno va a decidir por ti qué problema merece la pena resolver, que sigue siendo donde está el oficio.

Cómo montar tu propia prueba en una tarde

Esto es lo que de verdad recomiendo, más que leer comparativas ajenas. No hace falta montar nada sofisticado.

Elige un encargo que ya hayas hecho. Que sepas cómo termina y cuánto te costó. Ese es tu punto de referencia, y sin él no estás midiendo, estás opinando.

Dale las mismas instrucciones a los dos modelos. Las mismas de verdad, no una versión mejorada para el segundo porque ya has aprendido del primero.

Apunta cuatro cosas mientras trabajas: cuántas veces has tenido que intervenir, qué se quedó sin terminar, qué hizo mal que tú no habrías hecho mal, y cuánto tiempo te llevó revisarlo.

Ese último dato es el que manda. El tiempo de revisión es el coste oculto de todo esto y el que ninguna tabla publica. Un modelo que va rápido y te deja dos horas de repaso es más caro que uno lento que entrega cerrado.

Repítelo cuando salga el siguiente. Con el mismo encargo. Así, en tres o cuatro lanzamientos, tienes algo que ningún benchmark te da: una serie propia, medida sobre tu trabajo real.

Lo que me llevo

Salen modelos cada pocas semanas y esa velocidad no va a bajar. Intentar seguir cuál es el mejor en cada momento es una carrera que no se puede ganar y que además no hace falta correr.

Lo que sí se puede hacer es tener claro qué tipo de ayuda necesitas en cada tarea, y una prueba propia que te diga en una tarde si el modelo de moda te sirve o no.

Porque la pregunta útil nunca fue cuál es el más avanzado. Es cuál termina mejor el trabajo que tú tienes que entregar.