Harness vs modelo: 176 setups prueban qué pesa más

Por qué el 'harness' pesa más de lo que crees

176 configuraciones matched, 4 modelos, dos benchmarks y un solo veredicto: el 'harness' — el software que envuelve al modelo — puede importar más que el modelo mismo. Esa es la conclusión de un nuevo estudio de Fan et al. publicado el 18 de septiembre de 2026 en arXiv (2609.20804), que disecciona por primera vez las piezas internas de un coding agent.

Un 'harness' — en inglés, 'arnés' — es el software que envuelve a un modelo de IA y decide qué información ve, qué acciones puede tomar y cómo interactúa con tu código. Es, en la práctica, el sistema operativo del coding agent. Y según el paper, optimizarlo bien puede rendir más que pasarse al último modelo del mercado.

La conversación sobre coding agents suele girar en torno al modelo. Pero un creciente cuerpo de evidencia apunta a que el debate está mal encuadrado. Según una entrevista en Ars Technica con Cat Wu, jefa de producto de Claude Code en Anthropic, el equipo mantiene deliberadamente un 'harness ligero' y evita construir herramientas con opiniones fuertes alrededor del modelo. La razón que da Wu: 'los modelos cambian cada pocos meses', así que invertir en un harness con muchas herramientas especializadas es construir sobre arena. Una línea de investigación citada por TechTimes sobre el proyecto open source Everything Claude Code (ECC) lleva la hipótesis más lejos: estima que Claude Code es 'aproximadamente 98% infraestructura y 2% modelo'. El paper que nos ocupa llega a una conclusión compatible, pero con evidencia experimental.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El setup del estudio: 176 configuraciones matched

Los autores (Run-Ze Fan, Zihao Zhang, Simin Ma, Yebowen Hu, Shouju Wang, Kaiqiang Song, Fei Liu, Hamed Zamani y Xiaoyang Wang) construyen un harness ligero con un execution loop fijo y varían solo tres componentes: planning, action space y context management. En lugar de evaluar el harness como un sistema monolítico — la práctica habitual hasta ahora — comparan 176 configuraciones matched que cubren cinco estrategias de gestión de contexto, cuatro presupuestos de context window y ablaciones específicas de planning y herramientas. Todo se mide sobre SWE-Bench Verified y Terminal-Bench 2.1 con 4 modelos. Los 43 páginas del paper dan para una lectura densa, pero los cuatro hallazgos de fondo se pueden resumir así.

Hallazgo 1: la gestión de contexto se vuelve crítica cuando el budget aprieta

La gestión de contexto se vuelve más valiosa cuanto más apretado es el budget. ¿La razón principal? La mayor parte del beneficio viene de evitar fallos por context overflow, no de optimizaciones sofisticadas. Para un founder, esto significa que invertir en compactación y elisión de contexto paga sobre todo cuando trabajas con modelos de context window pequeño o con sesiones largas. El paper no aporta una cifra concreta de ahorro, pero la dirección es clara: si tu agente falla porque se quedó sin contexto, ningún modelo más caro te salva. Lo que te salva es un harness que elide o resume a tiempo.

Hallazgo 2: elisión rule-based antes que summarization con LLM

Cuando llega el momento de reducir contexto, hacerlo en dos etapas — primero reglas deterministas de elisión, después resumen con un LLM — ofrece la mejor eficiencia. Intentar hacer que el contenido elidido sea 'recuperable' añade maquinaria que los modelos casi nunca usan y no mejora la accuracy. La lección práctica es clara: no caigas en la trampa de construir un sistema de memoria reversible elegante. Un pipeline de dos etapas con una capa de reglas barata y una segunda capa de LLM cubre el grueso del trabajo con una fracción del código y los tokens.

Hallazgo 3: el planning cambia de función según el modelo

El planning cambia de rol según el modelo. Para modelos débiles, funciona como un andamio de accuracy: les ayuda a no perderse. Para modelos fuertes, su aporte se reduce — apenas cambia la accuracy — pero sirve como ahorrador de costo: con un plan explícito, el agente gasta menos tokens decidiendo sobre la marcha. Implicación operativa: si ya usas un modelo frontier, el planning detallado puede no mejorar tus resultados, pero sí bajar tu factura de API. Y si usas un modelo open source pequeño, un planning bien estructurado es probablemente la palanca de mayor impacto.

Hallazgo 4: bash-only vs herramientas predefinidas

Para modelos buenos en bash, una interfaz bash-only funciona tan bien como un set de herramientas predefinidas, con la ventaja de un costo sustancialmente menor, sobre todo en tareas centradas en línea de comandos. Las herramientas predefinidas solo marcan diferencia cuando el modelo es débil en shell. En el ecosistema actual esto ya se ve en la práctica: según Gizmochina, Xiaomi lanzó en junio MiMo Code, su coding agent con interfaz terminal, y reportó 62% en SWE-Bench Pro y 73% en Terminal Bench 2 — alrededor de 5 puntos por encima de Claude Code en esa fecha. La decisión de diseño del harness no es un detalle; es el producto.

¿Qué significa esto para tu startup?

Para un equipo técnico que está eligiendo o construyendo su coding agent, el mensaje del paper es incómodo: probablemente estás optimizando la variable equivocada. Tres acciones concretas que puedes aplicar esta semana:

Mide el harness, no solo el modelo. Cuando un coding agent falla en tu repositorio, la causa raíz suele estar en el harness (contexto, herramientas, planning), no en el modelo. Invierte una hora en hacer una ablación: cambia solo el context management, mantén todo lo demás fijo, y mide.
Elige bash-only si tu modelo es fuerte en shell. El estudio sugiere que un set de herramientas predefinidas no aporta cuando el modelo ya maneja bien la línea de comandos. Mantener un harness minimalista reduce el costo de tokens y la superficie de bugs.
Diseña el planning pensando en costo, no en accuracy. Con modelos frontier, un plan explícito no sube la accuracy pero sí baja tokens. Con modelos débiles, el plan sí sube la accuracy. Adapta el nivel de planning al modelo que usas y al presupuesto de la tarea.

Conclusión

El paper de Fan et al. no va a detener la carrera por el modelo más grande, pero sí la pone en perspectiva. Mientras Anthropic, OpenAI y Xiaomi compiten por score en SWE-Bench, un grupo de investigadores está diciendo en voz alta lo que varios sospechaban: la magia está en el andamiaje. Para los founders hispanohablantes que están adoptando coding agents en sus stacks, la conclusión operativa es directa: antes de cambiar de modelo, prueba a cambiar de harness. La inversión es menor y el retorno, según estos 176 setups, suele ser mayor.