Harness engineering vs. loop engineering: en qué se diferencian

¿Qué es un harness?

Por sí solo, un modelo de lenguaje recibe una entrada y produce texto. No puede ejecutar código, no recuerda nada de una conversación a otra y no tiene acceso a lo que apareció después de su entrenamiento. Para que pueda hacerlo, se monta un andamiaje a su alrededor: un bucle que lo llama una y otra vez, herramientas que puede invocar, archivos que se le dan en cada sesión y comprobaciones que ponen a prueba su salida. A ese andamiaje se le llama harness.

De las fuentes que leímos, la definición más amplia está en el artículo de LangChain: «A harness is every piece of code, configuration, and execution logic that isn’t the model itself.» Es decir, todo código, toda configuración y toda lógica de ejecución que no sea el propio modelo. Dentro de los agentes de programación también funciona una capa así: OpenAI llama «Codex harness» a la capa que aporta el bucle del agente y la lógica de ejecución; Anthropic llama «agent harness» a la capa que hace funcionar Claude Code.

El harness engineering es el trabajo de diseñar ese andamiaje. Nosotros también hacemos uno: diffox es una herramienta de revisión de código con IA que revisa pull requests. Los ejemplos de abajo salen de su proceso de revisión y del bucle que monta a lo largo de un pull request (cómo funciona, en otro artículo).

Cómo definen las fuentes el harness engineering

El término es nuevo y las fuentes que leímos no lo definen igual. La tabla recoge cada fuente con sus propias palabras y su fecha.

Fuente: la página de cada artículo, 15 de octubre de 2026. Las citas, en su idioma original.

Hashimoto describe una costumbre y, en el mismo párrafo, escribe que no sabe si ya existe un término aceptado. LangChain, en cambio, traza una frontera: todo lo que queda fuera del modelo es harness. Uno te dice qué hacer; el otro, dónde mirar.

Hay dos detalles que la tabla no muestra. La fórmula «Agent = Model + Harness» aparece en el artículo de LangChain, no en el de Hashimoto. Y la palabra «harness» es anterior al término: Anthropic ya había llamado al Claude Agent SDK «general-purpose agent harness» el 26 de noviembre de 2025. En los cinco artículos de Anthropic que leímos no aparece la expresión «harness engineering».

Qué cambias en cada capa

Los cuatro términos no son intercambiables: son cuatro capas, una dentro de otra. Según la definición de Anthropic, el prompt engineering abarca los métodos para escribir y organizar las instrucciones del modelo. El context engineering, en cambio, abarca las estrategias para elegir y mantener los tokens que el modelo tiene delante durante la inferencia, incluida toda la información que le llega aparte del prompt. El contexto es todo lo que ve el modelo en esa llamada.

No encontramos ninguna fuente primaria que atribuya el context engineering a una sola persona. Los dos usos que leímos son de junio de 2025: Tobi Lütke escribió el 19 de junio que prefería ese nombre a «prompt engineering» («the art of providing all the context for the task to be plausibly solvable by the LLM»), y Andrej Karpathy se sumó el 25 de junio. La definición de Anthropic es del 29 de septiembre de 2025.

El harness engineering está una capa más hacia fuera. No se queda en lo que ve el modelo; diseña también lo que pasa después de que responde: por qué comprobación pasa la salida, cómo se divide el trabajo, qué cambia cuando un error se repite. Las capas se contienen unas a otras: según LangChain, los harness de hoy sirven sobre todo para poner en práctica un buen context engineering. El loop engineering está todavía un piso más hacia fuera: no diseña una sola ejecución, sino las ejecuciones a lo largo del tiempo. Le dedicamos una sección aparte más abajo.

De qué piezas se compone un harness

Los artículos que leímos les dan nombres distintos a las piezas. Cada uno de los seis apartados de abajo aparece en al menos dos fuentes.

El bucle es el núcleo. Anthropic describe a los agentes como modelos que usan herramientas dentro de un bucle, guiados por la retroalimentación del entorno. En el artículo sobre el Agent SDK, los pasos del bucle son estos: reunir contexto, actuar, verificar el trabajo, repetir. Las herramientas y la observabilidad le muestran al modelo el resultado de lo que hizo: en el repositorio que describe OpenAI, el agente puede leer los logs, las métricas y las trazas. Los subagentes reparten el trabajo; según Anthropic, cada uno recibe una tarea acotada y empieza con una ventana de contexto limpia.

Las comprobaciones van aparte, porque no las escribe el modelo, sino tú. Según el artículo sobre el Agent SDK, la mejor retroalimentación son reglas claramente definidas para la salida, junto con la explicación de cuál se incumplió y por qué. OpenAI hace cumplir sus reglas de arquitectura de forma automática, con linters propios y tests estructurales.

¿Qué es el loop engineering?

El harness se ocupa de una sola ejecución. El loop engineering hace una pregunta más: ¿quién pone en marcha al agente y cuándo, y quién decide si el trabajo está terminado? El nombre se lo puso Addy Osmani en un artículo del 7 de junio de 2026: «Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.» Es decir, dejar de ser quien le escribe al agente turno a turno y diseñar el sistema que lo hace por ti.

Dos frases dieron pie al término. Peter Steinberger propuso ese mismo día dejar de escribirles prompts a los agentes y diseñar bucles que se los escriban. Según cuenta Osmani, Boris Cherny, responsable de Claude Code, había dicho: «My job is to write loops». Ninguno de los dos usa la expresión «loop engineering»; el nombre lo puso el artículo de Osmani.

Fuente: la página de cada artículo, 15 de octubre de 2026. Las citas, en su idioma original.

Las piezas en las que coinciden las fuentes son seis. La recopilación las enumera así: ejecuciones que se disparan, condiciones de parada que la máquina puede comprobar, archivos de estado persistentes, subagentes verificadores, presupuestos de tokens y puntos de traspaso a una persona.

• Disparador. Lo que pone en marcha la ejecución: un temporizador o un evento.
• Condición de parada. Un criterio con el que la máquina puede decidir que el trabajo está terminado: los tests pasan, la lista queda vacía.
• Estado. El registro que pasa de una ejecución a la siguiente; vive fuera de la ventana de contexto.
• Verificador. Un supervisor separado del agente que hace el trabajo.
• Presupuesto. Un límite de turnos o de tokens; al superarlo, el bucle se detiene.
• Traspaso a una persona. El punto en el que el trabajo que el bucle no resuelve pasa a una persona.

El artículo de Anthropic muestra tres de las piezas juntas. Cada vez que Claude Code intenta parar, un modelo evaluador aparte comprueba la condición. Lo devuelve al trabajo hasta que se cumple el objetivo o se llega al número de turnos que fijaste. Como dice Osmani, así el agente que escribe el código no es el que le pone nota.

Las fuentes se separan en un punto: ¿de qué bucle se habla cuando se dice «loop»? La recopilación distingue dos. En el bucle del agente, el modelo llama a herramientas dentro de una sola ejecución y actúa según el resultado; ese bucle forma parte del harness. El loop engineering, en cambio, se ocupa de las estructuras que arrancan, verifican y vuelven a arrancar esas ejecuciones a lo largo del tiempo. Algunos artículos de proveedores usan la palabra en el primer sentido, y el blog de ingeniería de Anthropic también define el harness como «el bucle que llama a Claude». En este artículo, loop tiene el segundo sentido.

Tampoco el término está asentado todavía. La misma recopilación dice que el debate no ha aclarado si el loop engineering es una disciplina nueva, una técnica de transición o una etiqueta de marketing. En julio de 2026 se llegó a proponer un sucesor, con el nombre de «graph engineering».

Cómo es un harness en una herramienta de revisión de código

El proceso de revisión de diffox muestra cómo encajan las piezas. Un pull request pasa por cuatro etapas hasta convertirse en comentarios, y en cada etapa se ve una idea del harness.

Contexto y asignación es lo que el harness le da al modelo antes de que empiece a trabajar. Los agentes especializados reciben cuatro cosas: el diff, los archivos antes y después del cambio, la descripción del pull request y, si existe, el archivo de reglas de tu repositorio (AGENTS.md o CLAUDE.md). El archivo de reglas se lee de la rama en la que se fusionará el pull request, no de la rama del propio pull request; así, un pull request no puede cambiar las reglas de su propia revisión. Esa garantía no la da una frase de las instrucciones, sino el sitio del que se lee el archivo.

Revisión especializada es el reparto del trabajo. «¿Hay algún error aquí?» es una pregunta amplia, así que diffox pone a agentes especializados a leer el mismo cambio. El equipo tiene 17; cada uno tiene su propia instrucción y busca una sola cosa: uno, errores de lógica; otro, problemas de concurrencia; otro, tests que no ponen a prueba nada.

La forma de la salida también la fija el harness. Para que un hallazgo cuente, tiene que decir tres cosas: qué afirma, qué sale mal y en qué situación, y el código en el que se apoya, citado literalmente. Los agentes no dan números de línea; diffox encuentra la línea él mismo, buscando la cita en el archivo.

Elegir y publicar es un paso aparte. Cada hallazgo tiene una clase: Crítico, Advertencia o Sugerencia. Al pull request llega lo que tienes que corregir, es decir, los hallazgos críticos y las advertencias. Las sugerencias esperan un tiempo en la página de Hallazgos de la consola, y desde ahí puedes publicar las que quieras. La revisión nunca bloquea el merge.

Una comprobación que el modelo no puede sortear con palabras

La tercera etapa, la verificación de pruebas, es donde la idea del harness se ve con más claridad en este ejemplo. Un modelo de lenguaje puede escribir algo convincente pero falso: cita una línea que no está en el archivo, objeta código que el pull request no tocó, repite el mismo problema tres veces con tres frases distintas. Esta etapa ata cada hallazgo al propio archivo, no a la palabra del modelo.

Las comprobaciones no son una llamada a un modelo, sino código normal: la misma entrada recibe siempre la misma respuesta.

• La cita del hallazgo se busca en el archivo. Una cita que no se encuentra no tiene línea que señalar; si la línea encontrada no está en lo que cambió el pull request, el hallazgo queda fuera de alcance.
• Los hallazgos que hacen la misma objeción en el mismo sitio se unen en uno solo.
• Si un hallazgo dice que el código contradice un texto, su segunda cita también se busca palabra por palabra.

El modelo no puede convencer a la comprobación de la cita: la comprobación no valora argumentos, busca la cita en el archivo.

También se puede poner a un modelo a supervisar a otro, pero el resultado sigue siendo el juicio de un modelo. Anthropic cuenta que su modelo evaluador, en las primeras pruebas, encontraba problemas reales y luego se convencía de que no eran importantes y aprobaba el trabajo. Por eso, comprobar con código lo que se puede comprobar con código es una pieza aparte; la pregunta que pide criterio se queda en manos del modelo.

En un proyecto pequeño, la misma idea cabe en unas pocas líneas. El ejemplo de abajo no es código de diffox; muestra el patrón.

# EJEMPLO: busca en el archivo la cita que dio el modelo
def quote_exists(finding: dict, files: dict[str, str]) -> bool:
    quote = finding.get("quote", "").strip()
    source = files.get(finding.get("file", ""), "")
    return bool(quote) and quote in source

El bucle que dura todo el pull request

Una revisión pasa por un harness; un pull request, en cambio, pasa por muchas revisiones. Se escribe el código, diffox lo revisa, el código cambia y se vuelve a hacer push. Lo escriba una persona o un agente de programación, esto es un bucle, y cada una de sus seis piezas tiene su equivalente en el código de diffox.

La lección de fondo de este bucle está en dos decisiones. La primera: el verificador no da un cambio por bueno. Cuando cambian las líneas de un hallazgo, al final del comentario solo se añade en qué commit cambiaron. No se escribe «corregido», porque el código reescrito puede seguir conteniendo el error. Un artículo de junio de 2026 pone la misma condición a la regla de parada: no confundir nunca un error con un éxito.

La segunda: la condición de parada la eliges tú. Las revisiones automáticas se detienen en un límite por pull request, que cambias en la pestaña Ajustes de la consola. Pasado el límite, pides una revisión nueva mencionando a diffox en un comentario. La decisión de hacer merge también es tuya: la revisión nunca bloquea el merge. Ese es el punto en el que el bucle le pasa el trabajo a una persona.

Cómo crece un harness a partir de los errores

Un harness no se monta una vez y se deja. Hashimoto describe dos caminos: una línea en el archivo de reglas para los errores simples y una herramienta escrita en código para el resto. Escribe que cada línea del archivo de reglas de su proyecto salió de un mal comportamiento del agente.

El artículo de OpenAI cuenta el mismo ciclo dentro de un equipo: todo el código del producto lo escribe Codex, y los ingenieros montan el entorno. Cuando al agente le cuesta algo, lo toman como una señal: buscan la herramienta, la protección o la documentación que falta y la añaden al repositorio. Cuando la documentación no basta, la regla pasa al código. El archivo de reglas se mantiene corto: un AGENTS.md de unas 100 líneas, que es un índice y no una enciclopedia.

También existe la dirección contraria. Según Anthropic, cada pieza del harness es una suposición sobre algo que el modelo no puede hacer por sí solo, y puede quedarse anticuada a medida que los modelos mejoran. Cuando llega un modelo nuevo, se vuelve a examinar el harness y se quita la pieza que ya no sostiene nada.

Mientras desarrollábamos esta herramienta, de ese ciclo salieron tres costumbres en nuestro propio repositorio:

• Cada regla va junto al error que la motivó. Una regla sin su motivo escrito la borra el primero al que le estorba.
• Un test es de fiar solo después de verlo ponerse en rojo al deshacer la corrección. Un test que no pone a prueba nada también sale en verde.
• Cuando cambia una comprobación escrita en código, la versión antigua y la nueva se vuelven a ejecutar sobre los resultados guardados. No hace falta una ejecución nueva y de pago; se ve, uno por uno, cada caso en el que las dos versiones no coinciden.

Por dónde empezar en tu proyecto

Para empezar no tienes que elegir un framework ni cambiar de modelo. Dentro del agente de programación que usas ya funciona un harness; tú le añades las piezas de tu propio proyecto.

Primero mira el error y luego elige el remedio más barato. Para los errores simples, el primer remedio es una línea en el archivo de reglas. Si el error se repite a pesar de la regla, lleva la regla al código: una regla de linter, un test, un script. La recomendación general de Anthropic vale también aquí: busca la solución más simple y aumenta la complejidad solo cuando haga falta.

Al montar tu primer loop, el orden es el mismo: primero comprueba que una sola ejecución es fiable y después escribe la condición de parada y su límite. La recomendación de Anthropic es clara: parar cuando se alcanza el objetivo o al llegar al número máximo de turnos; para controlar el uso de tokens, el bucle tiene que tener límites claros.