Un estudio de la Universidad de Shandong cuestiona que añadir más instrucciones y herramientas a los agentes de programación mejore su rendimiento: en las configuraciones analizadas, el coste por tarea llegó a variar hasta tres veces con el mismo modelo.
El coste oculto de la sofisticación en agentes de código
Los agentes de inteligencia artificial para programar necesitan algo más que un modelo capaz de generar código. Para trabajar sobre un proyecto deben localizar archivos, interpretar instrucciones, ejecutar herramientas y comprobar si sus cambios funcionan.
Alrededor del modelo se construye una infraestructura que organiza esas operaciones. Sin embargo, incorporar más funciones también puede aumentar el consumo de recursos sin que la mejora en los resultados sea evidente.
Una investigación de Yangze Liu y Zhongyi Han, de la Universidad de Shandong, examina precisamente esa relación. Su trabajo, publicado como preprint bajo el título What Does a Harness Buy? Tokens, Mostly, compara Claude Code, OpenCode y mini-SWE-agent manteniendo fijo el modelo en cada comparación.
La cuestión resulta relevante para cualquier equipo que esté incorporando agentes a su desarrollo: ¿cuánto del rendimiento procede del modelo y cuánto de la infraestructura que lo rodea?
Separar ambos factores permite valorar si una configuración más sofisticada justifica su coste o si una alternativa sencilla puede resolver las mismas tareas con menos recursos.
¿Qué es un arnés y por qué se utiliza?
Un arnés, o harness, es la infraestructura de software que permite a un modelo de lenguaje actuar dentro de un entorno de trabajo.
En programación, puede encargarse de proporcionar instrucciones, ofrecer herramientas para leer y editar archivos, ejecutar comandos y organizar el historial de la conversación.
La diferencia es importante: generar una respuesta con código no equivale a trabajar sobre un repositorio. Para corregir un fallo, el agente necesita encontrar su origen, modificar los archivos adecuados y comprobar las consecuencias del cambio.
Imagina que el modelo es un mecánico y el arnés es su taller. El taller pone a su disposición herramientas, manuales y procedimientos para realizar el trabajo.
Un equipamiento adecuado puede facilitar una reparación. Pero llenar el taller de instrumentos y obligar al mecánico a revisar un manual enorme antes de cada movimiento no garantiza que termine antes ni que arregle mejor la avería.
La clave está en que cada herramienta y cada instrucción tengan una función útil para la tarea que se está realizando.
Un coste por tarea que puede multiplicarse por tres
El estudio encontró diferencias de hasta tres veces en el coste calculado por tarea al cambiar de arnés, utilizando el mismo modelo y una misma referencia de precios.
En el conjunto amplio de 447 tareas, evaluado con dos modelos, Claude Code y mini-SWE-agent mostraron resultados estadísticamente equivalentes dentro de un margen de cinco puntos porcentuales.
Conviene entender qué significa esa equivalencia: se refiere a la tasa de resolución medida en esas pruebas y al margen establecido por los investigadores. No implica que ambos productos sean idénticos en todas sus funciones.
Tampoco significa que cualquier agente complejo vaya a costar siempre el triple. El gasto depende de la combinación entre modelo, instrucciones, herramientas y recorrido necesario para completar el trabajo.
Para una empresa, la diferencia práctica está entre pagar por capacidad útil y pagar por procesamiento adicional que no mejora el resultado que necesita obtener.
Por qué repetir una prueba cambia la interpretación
En las 45 tareas difíciles analizadas, cambiar de arnés alteró el resultado del 13% de las tareas, en la mediana. Repetir la misma configuración produjo una variación equivalente.
Este punto corrige una interpretación importante: la investigación no demuestra que dar dos intentos a un agente sencillo sea siempre más rentable que utilizar uno complejo.
Lo que pone de relieve es la necesidad de distinguir una mejora consistente de la variación entre ejecuciones. Un agente puede resolver una tarea en un intento y fallar en otro sin que se haya modificado su configuración.
Por eso, una pequeña ventaja obtenida en una única ronda de pruebas puede resultar insuficiente para decidir qué herramienta funciona mejor.
Antes de atribuir el progreso a un nuevo sistema de instrucciones, conviene comprobar si ese progreso se mantiene al repetir la evaluación.
¿Dónde se acumula el gasto?
Los autores relacionan la diferencia de coste con las instrucciones del sistema y las definiciones de herramientas enviadas en cada paso, junto con el número de pasos necesarios.
Estas instrucciones explican al modelo cómo debe comportarse. Las definiciones de herramientas describen qué operaciones puede realizar y qué parámetros necesita para ejecutarlas.
Todo ese contenido forma parte del texto procesado. Su extensión importa porque los modelos trabajan con tokens, unidades que pueden representar palabras, fragmentos de palabras o símbolos.
Si un agente necesita numerosas interacciones para completar una tarea, el contexto que acompaña a esas interacciones puede convertirse en una parte relevante del consumo.
Esto no permite afirmar que las instrucciones largas sean inútiles por definición. Una indicación necesaria puede evitar un error costoso. El problema aparece cuando se acumulan reglas repetidas o explicaciones que no aportan una mejora comprobable.
Además, consumo de tokens y factura no son exactamente lo mismo. Las tarifas de entrada, salida y reutilización mediante caché también influyen en el importe final.
Impacto directo en las empresas de software
Para un equipo que ejecuta agentes de forma habitual, una diferencia pequeña por tarea puede acumularse a lo largo del mes.
Pero reducir el precio de cada ejecución tampoco debería convertirse en el único objetivo. Un agente barato puede resultar poco rentable si obliga a los desarrolladores a dedicar mucho tiempo a revisar o rehacer sus cambios.
La comparación útil debe incluir el coste de completar una tarea correctamente y el esfuerzo humano necesario para aceptar el resultado.
También conviene separar la capacidad para resolver problemas de otras funciones del producto. La gestión de permisos, la trazabilidad de las acciones o la integración con los procesos internos pueden tener valor aunque no aumenten la puntuación de una prueba de programación.
Por tanto, el estudio no justifica afirmar que las herramientas comerciales avanzadas sean simplemente un empaquetado más caro. Sí invita a exigir una explicación concreta de qué aporta cada capa adicional.
Una pregunta práctica para los responsables técnicos sería: si eliminamos este componente, ¿qué empeora de forma medible y cuánto ahorramos?
Alternativas más sencillas y eficientes
Como aplicación práctica de estos resultados, los equipos pueden revisar sus configuraciones antes de añadir nuevas instrucciones o herramientas. El objetivo es encontrar la estructura suficiente para trabajar bien, con un coste razonable.
- Instrucciones claras y sin redundancias: Revisar los textos del sistema para eliminar repeticiones y contradicciones, conservando las reglas necesarias para ejecutar la tarea correctamente.
- Herramientas adecuadas al trabajo: Valorar qué operaciones necesita realmente el agente. Incorporar más herramientas debería responder a una necesidad identificada.
- Evaluaciones repetidas: Ejecutar las mismas tareas varias veces antes de interpretar una pequeña diferencia de resultados como una mejora estable.
- Comparaciones en condiciones equivalentes: Mantener constantes el modelo, las tareas y los límites relevantes para entender qué efecto tiene el cambio de configuración.
- Coste por resultado válido: Medir conjuntamente consumo, tareas resueltas y tiempo de revisión humana, en lugar de fijarse únicamente en el precio de una llamada.
- Pruebas sobre proyectos propios: Comprobar si las ventajas observadas se mantienen en los repositorios y procesos que utiliza el equipo.
Conclusión para el desarrollo de software
La investigación se concentra principalmente en SWE-bench Verified y reconoce diferencias en algunos límites de ejecución. Además, OpenCode quedó por detrás hasta unos nueve puntos en el conjunto amplio: no todos los sistemas obtuvieron resultados equivalentes.
Estas limitaciones importan porque impiden convertir el hallazgo en una regla universal sobre todos los agentes y todos los proyectos.
La enseñanza para el desarrollo de software es más concreta: añadir complejidad no basta para demostrar una mejora, y una factura más elevada necesita justificarse con resultados o funciones que aporten valor.
Diseñar un buen entorno para un agente exige decidir qué instrucciones necesita, qué herramientas le ayudan y qué controles permiten evaluar su trabajo.
La eficiencia empieza cuando cada componente tiene un propósito claro y su contribución puede comprobarse.
Fuentes:
- Estudio original: What Does a Harness Buy? Tokens, Mostly — Yangze Liu y Zhongyi Han.
- Repositorio de código y datos de la investigación.
- The Decoder: Fancy harnesses make coding agents more expensive but not better, study finds.
Sombra Radio · Apoyo de lectores
Ayuda a mantener viva Sombra Radio
Tu aportación voluntaria nos ayuda a seguir publicando sobre IA. Puedes apoyarnos desde 1 € al mes.
