Ingeniería de harness: la era de diseñar el entorno de trabajo, más importante que el modelo

Este es un análisis sobre “Harness Engineering” resumido por Addy Osmani. Según su diagnóstico, durante los últimos dos años la atención de la industria se ha concentrado únicamente en la pregunta de “qué modelo de IA es más inteligente”. Se hicieron comparaciones interminables sobre si GPT escribe código más limpio o si Claude alucina menos, pero su argumento es que, en la práctica, el rendimiento real de la IA para programar se decide más por el harness que rodea al modelo que por el modelo en sí. Harness es un término que abarca todo excepto el modelo: el system prompt con el que se le asigna trabajo a la IA, las herramientas y servidores externos que puede usar, las políticas de gestión de contexto, los mecanismos de verificación automática que se insertan durante la ejecución (hooks), los espacios seguros de ejecución (sandboxes), las IAs auxiliares (subagentes), los ciclos de retroalimentación e incluso los flujos de recuperación cuando el trabajo se atasca. Viv Trivedy formalizó esta idea con la frase “AI agent = model + harness”, y personas como el equipo de ingeniería de Anthropic, HumanLayer y Simon Willison están afinando esta línea de trabajo. Osmani considera que esta corriente ya se ha consolidado como un campo de ingeniería propio.

Si desglosamos los puntos clave, quedan así.

• Qué es un harness. Con solo el modelo no se obtiene una IA capaz de terminar un trabajo. Para que exista una “IA que trabaja”, hay que sumarle código y configuración que le permitan recordar el progreso, ejecutar herramientas, revisar resultados, volver a decidir y bloquear acciones que no debería hacer. Productos como Claude Code, Cursor, Codex, Aider o Cline son todos harnesses, y aunque usen el mismo modelo por dentro, el comportamiento que percibimos depende del harness. Tomando la expresión de Simon Willison, un agente de IA es “un sistema que ejecuta herramientas de forma repetida para cumplir un objetivo”, y la verdadera habilidad está en cómo se diseñan esas herramientas y esa estructura iterativa.

• La idea de que no es culpa del modelo, sino de la configuración. Cuando la IA hace algo absurdo, los ingenieros suelen culpar al modelo y concluir que “hay que esperar a la siguiente versión”. La ingeniería de harness rechaza esa reacción. En palabras de HumanLayer, “no es un problema del modelo, es un problema de configuración (skill issue)”. Hay casos en los que el mismo modelo Claude Opus 4.6 se queda en la parte baja de Terminal Bench 2.0 dentro del harness por defecto de Claude Code, pero salta a los primeros lugares cuando se lo mueve a un harness ajustado a mano. El equipo de Viv logró llevar el mismo modelo del rango de puesto 30 al top 5 solo cambiando el harness. Eso implica que muchas veces el harness está limitando el potencial real del modelo.

• El principio de “ratchet” para convertir errores en reglas. Si la IA comete un error aunque sea una sola vez, no se lo trata como un accidente aislado, sino como una señal permanente. La idea es ir apretando una muesca a la vez para que ese mismo error no vuelva a ocurrir: se agrega una línea al documento de reglas, se coloca un bloqueo automático o se incorpora una IA auxiliar encargada de revisar. Por ejemplo, si la IA comentó el código de prueba, en la siguiente versión del documento de reglas se añade una línea como “no comentar pruebas; eliminarlas o corregirlas”, y antes del commit se suma una verificación que detecte ese patrón. La clave es que cada línea de un buen documento de reglas debe estar vinculada a un fallo concreto ocurrido en el pasado. Por eso la ingeniería de harness no consiste en tomar un framework ya hecho y usarlo tal cual, sino que se parece más a una “disciplina” que se cultiva siguiendo el historial de fallos de tu propia base de código.

• Diseñar al revés desde el comportamiento deseado. La forma de pensar más útil que propone Viv es diseñar al revés: “quiero este comportamiento → qué componentes del harness hacen posible ese comportamiento”. Si no se puede explicar en una sola línea para qué comportamiento existe un componente, probablemente sea mejor quitarlo. En términos concretos: el sistema de archivos y Git sirven para conservar el trabajo a largo plazo y revertir cambios; bash y la ejecución de código son herramientas universales para intentar cualquier cosa; el sandbox es un espacio seguro donde se puede romper algo sin afectar al sistema principal; los archivos de memoria y las herramientas de búsqueda web o MCP son canales para acumular conocimiento nuevo; la compresión por resúmenes, la separación de salidas de herramientas y la función de skills amplían los límites de memoria de la IA; y el Ralph loop junto con la separación entre planificador y evaluador permiten sostener tareas largas de varios días.

• El problema del context rot. La IA tiene un límite de texto que puede leer de una vez, y a medida que se acerca a ese tope su capacidad de juicio se degrada de forma visible. Por eso el harness también es un conjunto de mecanismos para usar bien ese espacio limitado. Primero, cuando el límite se va llenando, se comprime inteligentemente el contenido antiguo con resúmenes. Segundo, en salidas grandes como un log de 2,000 líneas, se dejan solo la cabecera y el final, y el cuerpo se aparta a un archivo para releerlo solo cuando haga falta. Tercero, en vez de mostrar desde el principio todas las herramientas e instrucciones, se usa “divulgación progresiva”, mostrándolas solo en el momento real en que se necesitan para esa tarea. En trabajos realmente largos, incluso se puede reiniciar desde cero en una ventana nueva llevando solo un documento de traspaso. Anthropic señala que “en tareas largas, la compresión con resúmenes por sí sola no basta y a veces hace falta reiniciar con un documento de traspaso estructurado”. Es parecido a preparar un documento ordenado cuando se le entrega trabajo a una persona nueva.

• Patrones para sostener trabajos largos. Una de las debilidades actuales de los modelos es que intentan terminar demasiado pronto, no descomponen bien problemas grandes y pierden continuidad cuando cambia la ventana de contexto. El harness debe compensar esas debilidades. El Ralph loop es una técnica simple donde, cada vez que el modelo intenta dar por terminado el trabajo, un hook intercepta esa salida y vuelve a inyectar el objetivo original en una nueva ventana de contexto para que continúe. Cada iteración empieza en un estado limpio, pero los resultados de la iteración anterior se mantienen a través del sistema de archivos. Por otro lado, Anthropic subraya que conviene separar en IAs distintas a quien “genera” y a quien “evalúa”, porque cuando una IA evalúa su propio trabajo tiende a calificarse con benevolencia. Sumado a eso, el patrón de “sprint contract”, que consiste en acordar de antemano qué significa exactamente que algo esté terminado, sirve para evitar que el objetivo se vaya estirando silenciosamente a mitad del trabajo.

• El papel de los hooks. “Decirle a la IA que actúe de cierta forma” no es lo mismo que “hacer que el sistema la obligue a actuar así”. Los hooks son los mecanismos automáticos que cierran esa brecha e intervienen en momentos como antes de usar una herramienta, después de modificar un archivo, antes de un commit o al iniciar una sesión. Por ejemplo, pueden ejecutar automáticamente chequeos de sintaxis, lint y pruebas cada vez que se toca código; bloquear comandos peligrosos como rm -rf o git push --force; o exigir aprobación humana antes de abrir un PR. El principio es “éxito en silencio, fallo con ruido”. Si la verificación pasa, la IA no escucha nada; si falla, el mensaje de error se inyecta tal cual en el flujo para que la propia IA lo corrija. Es una estructura que casi no cuesta nada en el día a día, pero ayuda con precisión justo cuando aparece un problema.

• Documentos de reglas y selección de herramientas: cortos y claros. El archivo AGENTS.md en la raíz del proyecto es el archivo de configuración con más impacto, porque entra en el system prompt en cada turno. HumanLayer recomienda mantener este documento por debajo de 60 líneas. Cuanto más largo se vuelve, menos peso tiene cada línea; por eso sugieren que no sea una guía de estilo general, sino algo más parecido a una lista de verificación de piloto, donde solo queden los puntos indispensables. Con las herramientas pasa lo mismo: como su nombre, descripción y esquema quedan incrustados en el prompt en cada solicitud, es mejor tener 10 herramientas bien pulidas que 50 parecidas entre sí. HumanLayer también destaca el ángulo de seguridad. Como la descripción de la herramienta es texto que la IA lee, conectar un servidor MCP externo no verificado puede convertirse en un canal para inyectar instrucciones escritas por terceros sin que nadie lo note.

Estos son algunos aspectos que se pueden ver como ventajas.

• Aclara dónde vale la pena invertir esfuerzo. Los datos de benchmark muestran que el harness es un punto donde se puede elevar mucho el comportamiento sin cambiar de modelo. En vez de una expectativa vaga de “esperemos al próximo modelo”, aparece un área concreta que se puede mejorar desde ya.
• Crea una estructura donde el know-how se acumula. Gracias al enfoque ratchet, que convierte errores en reglas, una lección aprendida una vez queda como activo del equipo. Aunque cambien las personas, el documento de reglas y los hooks permanecen para proteger a quien sigue.
• Aparición de harnesses listos para usar (HaaS). La corriente que Viv llama “Harness-as-a-Service” se está asentando rápidamente. Están surgiendo productos como Claude Agent SDK, Codex SDK y OpenAI Agents SDK, que ya agrupan el bucle de trabajo, las herramientas, la gestión de contexto, los hooks y el sandbox, permitiendo concentrarse en el conocimiento del dominio sin tener que construirlo todo desde cero.

También hay partes más pesadas o problemáticas.

• El alcance de lo que hay que atender es amplio. Hay que asumir directamente la responsabilidad sobre instrucciones, herramientas, espacios seguros de ejecución, verificaciones automáticas y observación de logs. La clave es que no es un área que el proveedor del modelo vaya a resolver por ti.
• Riesgo de acoplamiento entre modelo y harness. Los modelos actuales se entrenan con posprocesamiento dentro de harnesses concretos, así que al moverlos a otro harness su rendimiento puede caer de golpe. Basta cambiar el nombre de una herramienta o el formato de un argumento para que el resultado tiemble. Un modelo realmente general no debería depender del nombre de una herramienta, pero por la forma en que se entrena junto con el harness aparece una especie de sobreajuste.
• Riesgos de seguridad en herramientas externas. Como los servidores MCP hacen que la descripción de la herramienta sea leída directamente por la IA, en cuanto se conecta una herramienta no verificada, el texto externo empieza a influir en la IA incluso antes de que el usuario escriba una sola palabra.

Estos son algunos enfoques diferenciadores.

• Tomar distancia del discurso centrado en el modelo. En vez de quedarse esperando un GPT más inteligente, propone un método de ingeniería para empujar el límite de lo que se puede lograr con el modelo que ya se tiene. Su diagnóstico es que la brecha entre las limitaciones visibles de la IA hoy y las capacidades reales del modelo es, en su mayoría, una brecha de harness.
• El harness no desaparece; solo cambia de lugar. Cuando el modelo mejora, algunos componentes del harness dejan de ser necesarios. Por ejemplo, Opus 4.6 casi eliminó la típica ansiedad de Claude Sonnet 4.5 de “el contexto está por acabarse, así que debo terminar rápido”, y por eso varios mecanismos auxiliares de contención quedaron convertidos en código muerto. Pero en las nuevas áreas a las que el modelo sí logra llegar aparecen debilidades nuevas, y otra vez hacen falta nuevos harnesses para cubrirlas. Aquí encaja muy bien la frase de Anthropic: “cada componente del harness contiene una hipótesis sobre aquello que el modelo no puede hacer por sí solo”.
• El ciclo de aprendizaje entre modelo y harness. Otro punto que señala Viv es el bucle de retroalimentación entre el diseño del harness y el entrenamiento del modelo. Cuando se descubre un patrón útil dentro del harness, ese patrón se estandariza; la siguiente generación de modelos se entrena tomando ese patrón como referencia; y sobre ese nuevo modelo vuelven a surgir nuevos patrones de harness. De ahí la conclusión de que un “buen harness” no es simplemente el harness con el que fue entrenado el modelo, sino uno que se vuelve a adaptar al trabajo concreto que se quiere hacer.
• La industria converge hacia formas parecidas. IAs de programación como Claude Code, Cursor, Codex, Aider y Cline usan modelos distintos, pero la forma de sus harnesses se va pareciendo cada vez más. El hecho de que los modelos sean diferentes pero los harnesses converjan es una señal de dónde se está asentando este campo.

El texto de Osmani plantea que la competitividad de la IA para programar depende más del diseño del harness que la rodea que de la elección del modelo, y que el harness no es un archivo de configuración que se define una vez y listo, sino un sistema vivo que se actualiza continuamente según el historial de fallos. Aunque el modelo mejore, el harness no desaparece; lo que ocurre es que la capa del problema se desplaza un nivel hacia arriba y un nuevo harness ocupa ese lugar. Como dice Viv en la cita que recoge Osmani, “crear un buen agente es el arte de iterar, y sin una primera versión no hay iteración”. Eso se puede leer como que, al final, este campo se decide por quién empieza antes y refina con más frecuencia. En resumen, la conclusión es que el lugar donde los ingenieros deberían invertir tiempo no es en cambiar una y otra vez el modelo de moda, sino en ajustar sin descanso el harness a su propio trabajo para ir elevando, un escalón a la vez, el techo al que puede llegar el modelo.

[kimjoin2]

Cada vez siento más que solo están apareciendo un montón de términos de marketing.

[dongho42]

Pero cuando en el prompt le dices que haga A y que no haga B, si de verdad lo entiende muy bien, siento que este enfoque podría ser válido, pero si cumple el prompt de forma probabilística según el estado del servidor de IA, ¿este enfoque seguiría siendo válido?

[dongho42]

Antes, aunque dejaba claramente escrito en el prompt que hiciera A, con cierta probabilidad seguía sin respetarlo, así que probé de todo: resaltarlo en negritas de Markdown, escribirlo dos veces, ponerlo en inglés, redactarlo con una estructura circular, escribirlo en XML... pero igual, con cierta probabilidad, seguía ignorando el prompt...

[kurthong]

Yo también estaba metiéndole de todo, parecido a lo que dice Osmani,
mientras hacía una app salió este tema y por eso me apresuré un poco,
pero siento que habría sido mejor si Osmani no se hubiera quedado solo en palabras
y hubiera puesto lo que decía en Google Anti-Gravity.
Lo mismo con Kaparthy; eso de ya ni pensar en construir nada y solo aventar un texto por ahí... ¡qué sé yo!

https://github.com/hang-in/tunaFlow

[tangokorea]

En lugar de verlo desde la perspectiva de cuál es mejor, el modelo o el arnés, ¿qué tal si damos un paso atrás y pensamos en qué arnés es más adecuado para cada modelo?

[jimmy2056]

Si el modelo es bueno, también se reduce la carga del diseño de arneses.

[akapwhd]

Aunque se aplique este tipo de cosas, al ver la programación real parece que no ayuda mucho en la práctica... supongo que es porque es desarrollo con un nivel de dificultad como para dejar un plan en codex y poner a correr al agente jaja

[blackfabric]

Resumen en 3 líneas

• El sistema (arnés) importa más que el modelo: el rendimiento de la IA no depende tanto del modelo en sí, como GPT o Claude, sino del diseño del entorno de trabajo que lo rodea, llamado "arnés", incluyendo prompts, herramientas, sandbox y bucles de retroalimentación
• El principio de "ratchet": los errores no deben tratarse como incidentes aislados, sino reflejarse de inmediato en documentos de reglas (como AGENTS.md) o hooks, para que el sistema se vuelva más robusto con el tiempo
• No es culpa del modelo, sino de la configuración (skill): cuando una IA no rinde bien, muchas veces se debe más a un mal diseño del arnés que a una falta de inteligencia del modelo, y es indispensable un enfoque de ingeniería que diseñe en reversa los componentes y restricciones necesarios a partir del resultado deseado

[yungoun]

Pero Harness hasta la semana pasada lo estuvieron vendiendo muchísimo, y desde esta semana está más calmado... no sé si será por las metidas de pata de Anthropic y porque Codex 5.5 es tan bueno........

[click]

Parece que cosas como SDD ya perdieron el hype y ahora lo que viene son los harness.
La parte algo curiosa de los harness es que, aunque claramente no estaba en los datos de entrenamiento, el modelo entendió bastante rápido el concepto de harness.
Será porque usa tal cual el significado de una palabra que ya existía, pero aunque yo ni lo mencioné, incluso hizo comentarios como que primero actualiza el harness.

[kurthong]

Es un análisis incluso de un texto de un desarrollador senior que hace que un argumento sin mucho contenido suene convincente (personalmente, disculpen que no me guste Google). Por supuesto, creo que abordar el fenómeno desde una perspectiva de comprensión es un buen intento.