De 6.7% a 68.3% de tasa de éxito: el harness, no el modelo, marcó la diferencia de 10x

Grok Code Fast tenía una tasa de éxito del 6.7% en el benchmark de codificación. Se cambió un solo formato de edición sin tocar el modelo y el resultado fue 68.3%. Ni un solo bit de los parámetros del modelo cambió.

Durante las vacaciones corrí agentes por mi cuenta y viví una experiencia similar. El ritmo de lanzamiento de modelos es frenético, pero lo que realmente separó el rendimiento de forma extrema en la práctica no fue el modelo en sí. Fue el harness que lo envuelve: la combinación de prompt de sistema, configuración de herramientas y middleware.

El mismo modelo, un ranking distinto

El equipo de LangChain corrió Terminal Bench 2.0 con su propio agente de codificación. Dejaron GPT-5.2-Codex intacto y solo tocaron el prompt de sistema, la configuración de herramientas y el middleware. El puntaje pasó de 52.8 a 66.5 y el agente escaló desde fuera del puesto 30 hasta el top 5 del leaderboard. El costo en entrenamiento del modelo: cero.

La clave fue la distribución del presupuesto de razonamiento. Aplicar xhigh de manera uniforme a todas las tareas se quedaba en 53.9%, pero dividirlo en xhigh-high-xhigh según la dificultad de cada tarea lo llevó hasta 66.5%. Los problemas que antes fallaban por timeout se resolvieron con esta estrategia de distribución. El mismo modelo, el mismo presupuesto de tokens, solo cambiaba la forma de repartirlos.

El formato de edición que ocultaba la verdadera capacidad

Un desarrollador de agentes open source creó un método de edición llamado hashline. Al leer un archivo, cada línea recibe una etiqueta hash de 2 o 3 caracteres, y cuando el modelo realiza modificaciones solo referencia esa etiqueta.

Con el método anterior, el modelo tenía que reproducir el texto original sin equivocarse en ni un solo carácter. Un espacio de más ya era un fallo. Quien haya usado agentes de codificación conoce bien el sufrimiento del error “String not found” que se repite una y otra vez. hashline esquiva este problema de forma estructural.

Los resultados fueron espectaculares. Grok Code Fast saltó de 6.7% a 68.3%, y Grok 4 Fast redujo sus tokens de salida un 61%. GPT-4 Turbo pasó de 26% a 59% con solo cambiar el formato, y Gemini 3 Flash superó su mejor marca anterior en 5 puntos porcentuales. Sin costo de entrenamiento, únicamente cambiando la interfaz de edición.

Sin loop de verificación, el agente se detiene en la primera respuesta

Hay un patrón de fallo muy común. El agente escribe código, lo vuelve a leer, concluye que está bien y termina ahí sin haber corrido ni una sola prueba.

El equipo de LangChain introdujo un middleware que obliga a validar el trabajo contra la especificación de la tarea justo antes de que el agente finalice. Un middleware separado detecta el “doom loop”, donde el agente edita el mismo archivo repetidas veces, y lo impulsa a reconsiderar el enfoque. Sin estos dos mecanismos, la mejora de puntaje habría sido mucho menor. También resultó efectivo inyectar previamente la estructura de directorios y las herramientas disponibles, además de usar avisos de presupuesto de tiempo para empujar al agente a entrar en la fase de verificación.

Los modelos más baratos son más sensibles al harness

MiniMax M2.5 y Kimi K2.5 son rápidos y buenos usando herramientas de agentes, a un precio mucho menor que los modelos grandes. A cambio, su conocimiento base es inferior al de los grandes modelos americanos. MiniMax da la impresión de haber sido entrenado desde el principio como modelo especializado en agentes: al tener menos recursos, apostó por la especialización en lugar de la generalización, y gracias a su bajo precio su uso está creciendo rápidamente en plataformas como Openclaw.

Los resultados del benchmark de hashline muestran que entre más débil es el modelo, más extrema es la variación de rendimiento causada por el cambio de formato. MiniMax más que duplicó su tasa de éxito al aplicar hashline. El costo total del benchmark fue de aproximadamente $300.

El benchmark no es lo mismo que producción

Hay un punto importante que considerar. Tanto Terminal Bench como el benchmark de hashline son métricas medidas en entornos controlados. En producción real hay muchas más variables: el tamaño del codebase, conflictos de dependencias, requerimientos ambiguos. Que un agente que marca 66.5% en el benchmark vaya a rendir igual en un proyecto legacy de 100,000 líneas está todavía por verse. Que la optimización del harness es efectiva está claro, pero extrapolar directamente el ranking del benchmark al rendimiento en producción es arriesgado.

Aun así, la dirección es clara. Hay un punto donde diseñar el harness supera al modelo en términos de ROI. Una parte significativa de los rankings de benchmark que vemos hoy no refleja la capacidad del modelo, sino la calidad del harness.