- Al probar varios LLM bajo las mismas condiciones, se observó que cambiar solo la herramienta de edición de código puede mejorar mucho el rendimiento
- En lugar de los métodos tradicionales de Patch y Replace, se aplicó el formato “Hashline”, que asigna hash tags a cada línea de código, para aumentar la precisión de las modificaciones
- Hashline mostró mayor precisión que los métodos anteriores en 14 de 16 modelos, y también se confirmó un efecto de reducción promedio de tokens del 20~30%
- En particular, el modelo Grok Code Fast 1 pasó de una tasa de éxito de 6.7% a 68.3%, una mejora de 10 veces con un simple cambio de harness
- El estudio muestra que, más que el modelo en sí, el “harness” es el cuello de botella del rendimiento real, y enfatiza la necesidad de colaboración en el ecosistema open source
Resumen del benchmark de edición de código
- El experimento comparó tres formatos de edición: Patch, Replace y Hashline
- Se aplicaron las mismas tareas de corrección de código a 16 modelos
- Cada modelo fue probado corrigiendo bugs en archivos elegidos al azar dentro de un codebase de React
- El formato Hashline mostró mejores resultados que Patch en 14 modelos y, en promedio, ahorró entre 20% y 30% de tokens
- La mejora más grande fue en Grok Code Fast 1, cuya tasa de éxito subió de 6.7% a 68.3% (+61.6 pp)
- Gemini 3 Flash mejoró 5.0 pp y Claude Sonnet 4.5 mejoró 1.6 pp
El problema del harness
- La discusión actual suele centrarse en “qué modelo programa mejor”, pero el verdadero cuello de botella es el harness, no el modelo
- El harness es la interfaz clave que gestiona los tokens de entrada y conecta la salida del modelo con los cambios en el workspace
- La mayoría de los fallos no provienen del modelo, sino de las limitaciones estructurales del harness
- El autor intentó mejorar esto a través de oh-my-pi, un proyecto personal derivado del agente de código open source Pi, realizando alrededor de 1,300 commits
- Este entorno es independiente del modelo y permite experimentar dejando solo el harness como variable
Limitaciones de las herramientas de edición existentes
- El método
apply_patch de Codex usa un formato diff específico de OpenAI, por lo que la tasa de fallos es alta con otros modelos
- Ejemplo: tasa de fallo de patch de 50.7% en Grok 4 y de 46.2% en GLM-4.7
- El método
str_replace de Claude Code exige una coincidencia exacta de la cadena, por lo que diferencias en espacios o indentación generan errores
- El error “String to replace not found in file” se ha reportado muchas veces en GitHub
- Cursor entrena un modelo aparte de 70B para manejar el merge, pero en archivos de menos de 400 líneas una reescritura completa (full rewrite) da mejores resultados
- Los estudios Diff-XYZ y EDIT-Bench de JetBrains también confirmaron que el rendimiento cambia mucho según el formato de edición
Cómo funciona el método Hashline
- A cada línea de código se le asigna un hash de contenido de 2 a 3 caracteres, para que el modelo pueda identificar con claridad el objetivo de la modificación
- Ejemplo:
22:f1| return "world";
- El modelo solicita la edición basándose en el hash, por ejemplo: “replace line 2:f1”
- Si el archivo cambia y el hash ya no coincide, la modificación se rechaza para evitar corrupción
- Este método evita que el modelo tenga que reproducir el contenido existente, lo que reduce errores de espacios e indentación y permite ediciones más estables
Resultados del benchmark
- La prueba consistió en 180 tareas de corrección de bugs, 3 repeticiones y 4 herramientas (read, edit, write, etc.)
- Como resultado, el formato Patch fue el peor en casi todos los modelos, mientras que Hashline fue equivalente o mejor que Replace
- Cuanto más débil era el modelo, mayor era la mejora
- Grok 4 Fast redujo en 61% los tokens de salida, y MiniMax mejoró más del doble
- El aumento de +8% en la tasa de éxito de Gemini supera la mejora típica de un upgrade de modelo, y se logró sin entrenamiento adicional
Políticas de los vendors y ecosistema open source
- Anthropic bloqueó el acceso de Claude Code desde el agente de código open source OpenCode
- La razón fue “ingeniería inversa de una API privada”, pero en la práctica se interpretó como una señal de “usen solo nuestro propio harness”
- Google bloqueó la cuenta del autor e impidió el acceso a Gemini
- Esto ocurrió justo después de un benchmark en el que Gemini 3 Flash alcanzó 78.3% de rendimiento con Hashline
- El autor señala que estas medidas son acciones regresivas que bloquean oportunidades de mejora del modelo
- Optimizar el harness es investigación pública que eleva la calidad de todos los modelos, no de uno en particular
- Con la frase “el modelo es el foso, el harness es el puente”, subraya que un enfoque cerrado frena el desarrollo del ecosistema
Conclusión
- Se confirmó que el problema del harness es un factor medible que afecta directamente el rendimiento real
- Con un simple cambio de formato se puede obtener una mejora comparable a un upgrade de modelo
- La dirección futura no debería ser la mejora cerrada de una sola empresa, sino la colaboración abierta basada en la comunidad
- Todo el código, los benchmarks y los resultados de ejecución están publicados en el repositorio de GitHub oh-my-pi
3 comentarios
El modelo está raro, ¿por qué otra vez ingeniería de prompts..
El harness y la ingeniería de prompts son cosas completamente distintas.
Comentarios en Hacker News
Leí este artículo con muchísimo interés. Creo que el autor dio exactamente en el clavo.
Incluso con los modelos que ya existen hoy, todavía hay muchísimo margen para hacerlos mucho más eficientes según cómo diseñemos el harness de agentes.
Yo no veo la “IA” simplemente como el LLM en sí, sino como todo el sistema cibernético donde el LLM y el harness están conectados en un bucle de retroalimentación.
Como el modelo y el harness se refuerzan mutuamente y evolucionan juntos, ambos son igual de importantes.
Esta perspectiva no solo mejora el rendimiento, sino que también permite reinterpretar la IA generativa como un proyecto neurosimbólico
De hecho, yo hice un agente de programación con la versión 2023 de GPT-4.
Trabajar con modelos viejos te obliga a mantener las cosas simples, y eso hace que veas el problema de otra manera.
Por ejemplo, en Python, una compresión semántica simple como
grep -r def .es indispensable.Si agregas hooks así de simples a una herramienta como Claude Code, puede captar de inmediato la estructura del código sin desperdiciar tokens
Con solo unas pocas horas de ajuste de prompts y código para procesar respuestas, la calidad de salida de modelos locales pequeños mejora de forma sorprendente
Enlace de GitHub
OpenAI depuró su propio proceso de entrenamiento y gestionó despliegues usando una versión inicial de GPT-5.3-Codex.
Claude Code envía más de 20 PR al día, todos generados por su propio código
Ni siquiera está claro qué modelos son sensibles a una buena ingeniería de contexto.
Pero sí coincido en que claramente hay mucho fruto al alcance de la mano
La técnica es interesante, pero da la impresión de estar sobrevalorada.
El autor vio una mejora del 5% en un benchmark simple de find/replace que él mismo hizo, y lo cuenta como si el rendimiento general hubiera subido 14 puntos.
En la práctica, probablemente sea una mejora de menos del 1% en eficiencia total de tokens.
Además, el tono exagerado del texto y ese estilo tan característico de ChatGPT le quitan credibilidad
Este artículo muestra muy bien cuánto margen de mejora hay a nivel de harness.
Los agentes desperdician muchos tokens en edición, sandboxing y transferencia de datos entre llamadas a herramientas.
La combinación de direccionamiento basado en contenido + numeración de líneas es práctica y elegante
Facilita el desarrollo inicial, pero termina llamando modelos innecesariamente grandes y eso es ineficiente
En CC puedes revisar el costo por sesión con el comando
/cost, y está bueno usar esa métrica para evaluar la eficiencia de un pluginLa importancia del harness es muchísimo mayor de lo que la mayoría cree.
Por ejemplo, el puntaje de Opus en el benchmark CORE casi se duplicó al cambiar de su harness propio a Claude Code
Enlace relacionado
también explica que el mejor puntaje de TerminalBench se debió al harness Terminus 2
Quedar atado a un harness específico por una suscripción de 20 dólares al mes no tiene sentido
Hice una herramienta llamada tilth que implementa un método de lectura/edición basado en hash.
Se puede instalar con npm y cargo, y se integra con editores como Claude Code o Cursor
Enlace de GitHub
El objetivo es que los LLM usen herramientas de manera más eficiente y desperdicien menos tokens
Yo ideé de forma independiente un método parecido, pero lo abandoné por la dependencia de abstracciones.
En su lugar, usé la distancia de Damerau-Levenshtein para calcular similitud de edición, y si supera cierto umbral, el cambio se acepta.
Así el modelo tiene que emitir explícitamente los tokens de origen que va a reemplazar, lo que mejora la precisión
Ejemplo de código
La clave es que los mensajes de error sean específicos: el manejo de errores debe incluir instrucciones de recuperación, como “Content mismatch. Reread the file”.
Este enfoque funciona bien incluso con modelos 4B, y para modelos que no soportan tool calling se resuelve con un hack de inyección en el system prompt
Código relacionado
Incluso con modelos antiguos se podían obtener resultados bastante precisos.
La clave era “tratarlos correctamente”.
Este artículo sugiere que se podrían lograr avances mayores si el modelo pudiera manipular directamente no solo texto, sino una representación estructural del código fuente (AST).
Por ejemplo, OpenRewrite usa un Lossless Semantic Tree que incluye tipos, formato e información de dependencias del código.
Si el modelo pudiera aprovechar esa estructura, sería posible hacer modificaciones muy precisas sin desperdiciar tokens innecesariamente.
Al final, es la misma razón por la que en el debate de “Vim vs Emacs” la respuesta termina siendo “IntelliJ”: la información estructural es un arma potentísima.
Si un modelo aprendiera a la vez código, documentación y árboles sintácticos/semánticos, entonces sí tendríamos un verdadero modelo de programación neurosimbólico
Experimentando con LLM desde gptel en Emacs, descubrí que a los LLM se les da mal modificar código con la herramienta Unix patch.
Así que aproveché tree-sitter de Emacs para crear mis propias herramientas para gptel.
Hice que modificara directamente nodos del AST con comandos como
tree_sitter_list_nodesytree_sitter_update_nodes, y funcionó perfectoEl
apply_patchde Codex en realidad usa un esquema de muestreo restringido.Código relacionado
El autor hizo la comparación sin saber eso, así que un benchmark más realista debería hacerse con ese esquema activado
Hubo una parte de las citas de este artículo que me impactó especialmente
“No es que el modelo no entienda el problema, es que la representación es inestable. No culpes al piloto por un problema del tren de aterrizaje.”
“El modelo es el moat, el harness es el puente.”
“La diferencia entre un demo llamativo y una herramienta confiable no es magia, sino ingeniería aburrida pero meticulosa.”