¿Qué modelo IA escribe el mejor código?

Por qué el código es el benchmark más difícil de falsear

El código es implacable de una forma que la mayoría de tareas para modelos de lenguaje no lo son. La prosa puede ser vagamente correcta y seguir siendo útil; el código o funciona o falla. Un modelo que escribe una función que parece plausible pero maneja mal los casos límite produce una suite de tests que se pone en verde y un incidente en producción que se pone en rojo. No existe versión de este trabajo donde el crédito parcial valga algo.

Eso hace del código el benchmark más difícil de manipular. Un proveedor puede publicar una puntuación en un conjunto de tests curado, pero cualquier desarrollador con acceso a la API puede probar el modelo contra un bug real de su propio backlog en cuestión de minutos. El consenso de la comunidad sobre qué modelo escribe el mejor código suele ir meses por delante de cualquier clasificación oficial y llega al mismo resultado de forma fiable. Fíjate en qué herramientas usan realmente los mejores ingenieros, no en lo que dicen las páginas de marketing.

La naturaleza del trabajo también ha cambiado. Hace dos años, la asistencia al código significaba completiones de un solo turno: escribir un comentario, aceptar una sugerencia, seguir. Hoy el mismo flujo de trabajo abarca bucles agentivos que leen archivos, ejecutan tests, editan código e iteran sin supervisión. El modelo tiene que ser bueno no solo escribiendo código sino decidiendo qué escribir, recuperándose de fallos y parando cuando termina. Habilidades distintas, líderes distintos, perfiles de precio distintos.

Cinco cosas separan los modelos que merece la pena usar de los que no: corrección bruta, disciplina en el uso de herramientas, comprensión de contextos largos, cobertura de lenguajes y el coste total de resolver una tarea de principio a fin. El panorama completo importa más que cualquier dimensión individual.

El ritmo del progreso también influye en cómo construyes. Un stack de código que tiene un único nombre de modelo hardcodeado envejece rápido. Los mejores equipos tratan el modelo como un componente intercambiable detrás de su capa de agente y re-benchmarkan cada trimestre. Un nuevo lanzamiento que resuelve un diez por ciento más de tareas en tu backlog vale más que cualquier funcionalidad que construirías en el mismo trimestre — y la única forma de detectarlo es seguir probando.

Las cinco dimensiones que deciden qué modelo gana

Estos son los ejes con los que nuestro scorecard pondera cualquier modelo que se despliega cerca de una base de código real. La ponderación relativa depende de si el modelo vive en un IDE, un bucle agentivo o un batch job — pero todo candidato necesita superar un umbral mínimo en los cinco.

1. 01 — Corrección en el primer intento

   ¿El código se ejecuta y hace lo que debe?

   Código generado que compila pero maneja mal un null es peor que ningún código — el engineer lo lee, confía en él y lo despliega. El mejor predictor de que un modelo es apto para trabajo de código es la proporción de tareas que resuelve de principio a fin sin un segundo intento.

2. 02 — Uso de herramientas y bucles agentivos

   ¿Puede dirigir un workflow, no solo responder una pregunta?

   Los agentes de codificación modernos llaman herramientas: leer un archivo, buscar en una base de código, ejecutar un test, aplicar un parche. El modelo necesita saber qué herramienta llamar cuándo, cuándo parar y cómo recuperarse cuando la herramienta devuelve basura. Los modelos optimizados para chat fallan silenciosamente aquí; los optimizados para bucles agentivos avanzan.

3. 03 — Comprensión de contexto largo

   ¿Puede retener todo un repositorio en la cabeza?

   Un contexto de un millón de tokens no sirve de nada si el modelo solo presta atención a las primeras y últimas páginas. Prueba el rendimiento en contexto largo con sondas de recuperación a múltiples profundidades en tus propios archivos. En la práctica, el código se beneficia más de la profundidad de atención que del tamaño bruto de la ventana.

4. 04 — Cobertura de lenguajes y frameworks

   ¿Conoce tu stack o solo Python y JavaScript?

   Todos los modelos frontier dominan los lenguajes más populares. La calidad cae en picado en cuanto se pasa a Rust, Zig, Elixir, Clojure o cualquier DSL construido sobre ellos. La cobertura de frameworks es aún más desigual: un modelo que maneja React con confianza puede flaquear en Phoenix LiveView. Siempre benchmarka en tu stack real.

5. 05 — Coste por tarea resuelta

   ¿Qué pagas realmente para desplegar el cambio?

   Los bucles agentivos disparan los costes rápido. Un modelo que cuesta el doble por token pero resuelve la tarea en un intento en vez de tres es la opción más barata. Mide siempre de extremo a extremo: cada lectura, cada reintento, cada llamada a una herramienta y el tiempo que el engineer dedica a revisar el resultado.

Top 5 de Tokonomix para código hoy

Lo que sigue es lo que pondríamos concretamente en manos de un desarrollador esta semana. Cada modelo está en la lista por una razón que lo excluye de estar en todas las listas — no existe un modelo que gane a la vez en completiones inline, refactorizaciones agentivas, revisiones a escala de repo e inferencia auto-alojada. Los equipos que más sacan de los asistentes de codificación hoy ejecutan dos de estos en paralelo: un modelo rápido con cada pulsación de tecla y uno más pesado que el agente llama cuando el primero no puede con algo.

Precio de salida por millón de tokens

En codificación el coste de salida domina, porque el asistente gasta la mayor parte de sus tokens escribiendo código en vez de leyendo tu prompt. El gráfico muestra el precio de lista actual de cada uno de los cinco modelos anteriores.

Guía de campo: qué modelo para qué trabajo

El mapeo de abajo es el que usaríamos para asesorar a un equipo que parte de cero. Trátalo como punto de partida, no como veredicto — un pequeño benchmark en tu propio backlog supera cualquier recomendación general.

Benchmarka en tu propio backlog antes de comprometerte

Una guía como esta solo puede razonar sobre promedios — y los promedios no entregan tu próxima versión. Saca diez o veinte tickets cerrados de tu último sprint — los complicados, no los fáciles — y reprodúcelos con dos o tres candidatos. Usa el mismo bucle agentivo y el mismo system prompt para cada uno. Una tarde es suficiente.

Después lee los diffs uno al lado del otro. ¿Funcionó el cambio en el primer intento? ¿Recurrió el modelo a las herramientas correctas? ¿Entendió las partes de la base de código que tenía que tocar pero no modificar? ¿Se mantuvo dentro de las convenciones del framework? ¿Cuánto costó cada intento de extremo a extremo incluyendo reintentos? Elige al ganador en base a tus propios datos, aunque otro gane en todos los rankings.