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” recopilado por Addy Osmani. Su diagnóstico es que, durante los últimos dos años, la atención de la industria se ha concentrado demasiado en una sola pregunta: “¿Qué modelo de IA es más inteligente?”. Se han hecho 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 desempeño real de una IA para programar se decide menos por el modelo en sí que por el harness que lo rodea. “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áticos que se insertan durante la ejecución (hooks), los entornos seguros de ejecución (sandboxes), las IAs auxiliares (subagentes), los bucles de retroalimentación y hasta el flujo de recuperación cuando el trabajo se atasca. Viv Trivedy formalizó esta idea con una frase: “AI agent = model + harness”, y personas como el equipo de ingeniería de Anthropic, HumanLayer y Simon Willison han ido refinando esta corriente. Osmani sostiene que esto ya se consolidó como una disciplina de ingeniería.

Si desglosamos los puntos clave, quedan así.

• Qué es un harness Con solo un modelo no se obtiene una IA capaz de terminar trabajo. Hace falta sumarle código y configuración para que recuerde el progreso, ejecute herramientas, revise resultados, vuelva a decidir y bloquee acciones que no debería realizar. Solo entonces se convierte en una “IA que trabaja”. Productos como Claude Code, Cursor, Codex, Aider o Cline son todos harnesses, y aunque el modelo interno sea el mismo, 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 iterativa para lograr un objetivo”, y la verdadera capacidad está en cómo se diseñan esas herramientas y esa estructura de repetición.

• La idea de que no es culpa del modelo sino de la configuración Cuando una IA hace algo absurdo, los ingenieros suelen culpar al modelo y concluir que “hay que esperar la siguiente versión”. Harness Engineering rechaza esa reacción. En palabras de HumanLayer, “no es un problema del modelo, es un problema de configuración (skill issue)”. Incluso usando el mismo modelo Claude Opus 4.6, dentro de Claude Code —su harness base— se queda en la parte baja de Terminal Bench 2.0, pero al moverlo a un harness ajustado manualmente puede saltar a los primeros puestos. El equipo de Viv logró llevar el mismo modelo del rango de los 30 mejores 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”: convertir errores en reglas permanentes Si la IA comete un error aunque sea una sola vez, no se toma como un accidente aislado, sino como una señal permanente. La idea es apretar un clic más cada vez: agregar una línea al documento de reglas para que ese error no vuelva a ocurrir, incorporar un bloqueo automático o asignar una IA auxiliar que revise ese punto. Por ejemplo, si la IA alguna vez comentó el código de pruebas, la siguiente versión del documento de reglas debería incluir algo como “no comentar las pruebas; elimínalas o corrígelas”, y antes del commit se añadiría 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 una falla concreta del pasado. Por eso, Harness Engineering 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 fallas de tu propia base de código.

• Diseñar en reversa a partir del comportamiento deseado La forma de pensar más útil que propone Viv es diseñar al revés: “quiero este comportamiento → ¿qué piezas del harness hacen posible ese comportamiento?”. Si no puedes explicar en una línea para qué comportamiento existe cierta pieza, probablemente conviene quitarla. En concreto: el sistema de archivos y Git sirven para conservar trabajo a largo plazo y revertirlo; bash y la ejecución de código son herramientas universales para probar cualquier cosa; el sandbox es un entorno seguro donde incluso si algo sale mal no afecta al sistema principal; los archivos de memoria y herramientas como búsqueda web o MCP son vías para acumular conocimiento nuevo; la compresión por resúmenes, la separación de salidas de herramientas y las funciones de skill amplían los límites de memoria de la IA; y el Ralph loop, junto con la separación entre planificador y evaluador, permite sostener trabajos largos de varios días.

• El problema de la degradación de contexto (context rot) La IA tiene un límite en la cantidad de texto que puede leer de una vez, y a medida que se acerca a ese límite su capacidad de juicio cae visiblemente. Por eso el harness también es un conjunto de mecanismos para usar bien ese espacio limitado. Primero, cuando se llena el límite, el contenido viejo se resume y comprime de forma inteligente. Segundo, si hay salidas grandes como logs de 2,000 líneas, se deja solo el inicio y el final en contexto y el cuerpo se mueve a un archivo para releerlo solo cuando haga falta. Tercero, no se muestran todas las herramientas e instrucciones desde el inicio, sino que se aplica una “divulgación progresiva”: se exponen solo en el momento en que realmente se necesitan para esa tarea. En trabajos muy largos, incluso se puede reiniciar desde una ventana nueva llevando solo un documento de handoff. Anthropic señala que “en tareas largas no basta con la compresión por resúmenes, y a veces hace falta reiniciar con un documento de handoff estructurado”. Es parecido a cuando una persona entrega trabajo a alguien nuevo con documentación bien organizada.

• Patrones para sostener trabajos largos Una debilidad actual de los modelos es que tienden a querer terminar demasiado pronto, no saben dividir 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 el flujo y vuelve a inyectar el objetivo original en una nueva ventana de contexto para que continúe. Cada iteración empieza en limpio, pero el resultado anterior se mantiene vía el sistema de archivos. Por otro lado, Anthropic insiste en separar la IA “generadora” de la IA “evaluadora”, porque cuando una IA juzga su propio resultado tiende a ser demasiado indulgente. Además, el patrón de “sprint contract”, que define de antemano qué significa exactamente “terminado” antes de comenzar la tarea, es eficaz para evitar que el objetivo se vaya expandiendo silenciosamente a mitad del trabajo.

• El rol de los hooks “Decirle a la IA que actúe de cierta manera” no es lo mismo que “hacer que el sistema la obligue a actuar así”. Los hooks son mecanismos automáticos que cubren esa diferencia: se ejecutan antes de usar herramientas, después de modificar archivos, antes de hacer commit o al iniciar una sesión. Por ejemplo, pueden lanzar automáticamente comprobaciones de sintaxis, lint y tests 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 silencioso, fallo ruidoso”. Si la verificación pasa, la IA no oye nada; si falla, el mensaje de error se inyecta directamente al flujo para que ella misma lo corrija. Es una estructura que casi no cuesta nada en condiciones normales y ayuda justo en el momento en que surge un problema.

• Documentos de reglas y selección de herramientas: cortos y claros El archivo AGENTS.md ubicado en la raíz del proyecto es el archivo de configuración más influyente porque entra al system prompt en cada turno. HumanLayer recomienda mantenerlo por debajo de 60 líneas. Mientras más largo sea, menos peso tiene cada línea, así que no debe funcionar como una guía de estilo general sino como una lista de verificación de piloto: dejar solo lo imprescindible. 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 afinadas que 50 parecidas entre sí. HumanLayer también advierte sobre la seguridad. Como la descripción de una herramienta es texto que la IA lee directamente, conectar un servidor MCP externo no verificado puede convertirse en un canal para inyectarle instrucciones escritas por terceros.

Estos son algunos aspectos que pueden verse como ventajas.

• Queda más claro dónde vale la pena invertir esfuerzo Los datos de benchmark muestran que el harness es el punto donde puede mejorarse mucho el comportamiento sin cambiar de modelo. En lugar de una expectativa vaga de “esperemos el próximo modelo”, aparece un área concreta que puede ajustarse desde ya.
• Se crea una estructura donde el conocimiento se acumula Gracias al enfoque ratchet, que convierte errores en reglas, cada lección aprendida queda como un activo del equipo. Aunque cambien las personas, el documento de reglas y los hooks permanecen para proteger a quien llegue después.
• Aparición de harnesses ya preparados (HaaS) La tendencia que Viv llama “Harness-as-a-Service” se está consolidando rápidamente. Productos como Claude Agent SDK, Codex SDK y OpenAI Agent SDK ya empaquetan de antemano el loop de trabajo, herramientas, gestión de contexto, hooks y sandboxes, permitiendo que uno se enfoque en su conocimiento de dominio en vez de construir todo desde cero.

También hay partes más exigentes.

• El ámbito a cubrir es amplio Hay que hacerse responsable de prompts, herramientas, entornos seguros de ejecución, verificaciones automáticas y observación de logs. El punto clave es que no es un área que el proveedor del modelo vaya a resolver por ti.
• El riesgo de acoplamiento entre modelo y harness Los modelos actuales reciben entrenamiento posterior dentro de harnesses específicos, 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 los resultados se alteren. Un modelo realmente general no debería depender del nombre de la herramienta, pero como se entrena junto con esa estructura, aparece una especie de sobreajuste.
• Riesgos de seguridad en herramientas externas Como la descripción de un servidor MCP se le muestra tal cual a la IA, en cuanto conectas una herramienta no verificada, texto externo empieza a influir en la IA incluso antes de que el usuario escriba una sola palabra.

Estos son los puntos de vista que lo diferencian.

• Tomar distancia del discurso centrado en el modelo En vez de esperar un GPT más inteligente, propone una vía de ingeniería para exprimir al máximo el modelo que ya tienes. Su diagnóstico es que gran parte de la brecha entre los límites visibles de la IA actual y las capacidades reales del modelo es, en el fondo, una brecha de harness.
• El harness no desaparece, solo cambia de lugar Cuando el modelo mejora, algunas piezas del harness dejan de ser necesarias. Por ejemplo, Opus 4.6 casi eliminó la ansiedad típica de Claude Sonnet 4.5, esa tendencia a pensar “el contexto está por acabarse, mejor cierro rápido”, y gracias a eso varios mecanismos de apoyo usados hasta ahora pasaron a ser código muerto. Pero en las nuevas áreas a las que llega el modelo aparecen nuevas debilidades, y vuelve a hacer falta un nuevo harness para cubrirlas. Encaja bien aquí la frase de Anthropic: “cada componente de un harness contiene una suposición sobre qué cosas el modelo no puede hacer por sí solo”.
• El ciclo de aprendizaje entre modelo y harness Otro punto que destaca 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 en el harness, este se estandariza; la siguiente generación de modelos se entrena tomando ese patrón como base; y encima de esos nuevos modelos surgen otros patrones de harness. Por eso, la conclusión es que un “buen harness” no es el harness con el que se entrenó el modelo, sino uno que fue afinado de nuevo para tu propio trabajo.
• La industria converge hacia formas parecidas IAs de programación como Claude Code, Cursor, Codex, Aider y Cline usan modelos distintos por dentro, pero la forma de sus harnesses se parece cada vez más. El hecho de que los modelos sean distintos pero los harnesses se estén volviendo similares puede leerse como una señal de hacia dónde se está estabilizando este campo.

El texto de Osmani plantea que la competitividad de una IA para programar depende más del diseño del harness que rodea al modelo que de la elección del modelo en sí, y que el harness no es un archivo de configuración que se ajusta una vez y ya, sino un sistema vivo que se actualiza continuamente según el historial de fallas. Aunque el modelo mejore, el harness no desaparece: simplemente se desplaza a un nivel superior del problema y otro nuevo ocupa su lugar. Como dice Viv en una de las citas que recoge: “Construir un buen agente es el arte de iterar, y sin una primera versión no puede haber iteración”. Eso sugiere que, al final, este campo será una competencia por quién empieza antes y refina con más frecuencia. En última instancia, la conclusión es que el lugar donde los ingenieros deben invertir tiempo no es en cambiar constantemente al modelo de moda, sino en ajustar sin descanso un harness alineado con su propio trabajo para ir empujando, paso a paso, el techo de lo que el modelo puede lograr.

[kimjoin2]

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

[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

[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

[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.