Harness Engineering: construir sistemas en lugar de prompts
En el artículo anterior de esta serie defendía que la verdadera palanca no es cómo redactas un prompt, sino el contexto al que tiene acceso el agente: qué sabe, qué puede tocar, qué límites debe respetar.
Pero un contexto que solo vive en tu cabeza, o que tienes que parchear a mano cada vez que algo falla, es frágil. Depende de que te acuerdes. Depende de que estés presente.
Ahí es donde entra el Harness Engineering: no se trata de escribir mejores prompts, ni siquiera de escribir mejores archivos de contexto, sino de construir el sistema que mantiene ese contexto vivo, actualizado y estable — estés prestando atención en ese momento o no.
El momento en que me di cuenta de que había construido un harness sin ponerle nombre
Después de escribir el artículo anterior, empecé a hacer exactamente lo que describía en él: cada vez que un Coding Agent se equivocaba en algo, en lugar de limitarme a reexplicárselo en el chat, iba y arreglaba la causa raíz — actualizaba una regla en el CLAUDE.md, editaba una Skill, ajustaba un permiso, añadía una comprobación a un hook.
Unas semanas haciendo esto, y al mirar lo que tenía de verdad: un conjunto de instrucciones de proyecto, una carpeta de Skills para los procedimientos que uso a menudo, una lista corta de servidores MCP con permisos concretos, hooks que ejecutan validaciones automáticamente, y una regla que dice que nada sale a producción sin que yo lo revise antes.
Nada de eso lo planifiqué como "un sistema". Era simplemente yo arreglando un problema cada vez. Pero eso es exactamente lo que es un harness: normalmente se construye por accidente antes de que nadie le ponga nombre a propósito.
Un harness no es un prompt. Es un entorno.
Pensad en la diferencia entre decirle a alguien qué hacer una vez, y darle un entorno donde hacer lo correcto sea la opción por defecto.
Un prompt es lo primero. Es una instrucción puntual, válida para una conversación, que desaparece en cuanto termina la sesión.
Un harness es lo segundo. Es el entorno duradero en el que trabaja un agente, sesión tras sesión, que hace que el buen comportamiento sea el camino de menor resistencia en lugar de algo que hay que pedir cada vez.
En concreto, un harness para un Coding Agent está hecho de cosas que ya tienen nombre en este ecosistema:
- Instrucciones de proyecto (
CLAUDE.md,AGENTS.md) — la arquitectura, las convenciones y las restricciones que el agente ya debería conocer sin que se le digan. - Skills — procedimientos empaquetados para cosas que de otro modo tendrías que reexplicar cada vez.
- Servidores MCP — las herramientas y fuentes de datos externas a las que el agente tiene permitido llegar, y nada más.
- Hooks — comprobaciones automáticas que se ejecutan independientemente de si el agente se acuerda de hacerlo.
- Permisos — un límite explícito de lo que el agente puede hacer sin preguntar, y lo que no puede hacer en absoluto.
- Tests — la definición objetiva de "terminado" que no depende del criterio del propio agente.
- Puntos de revisión humana — los momentos en los que nada avanza hasta que una persona lo dice.
Ninguna de estas piezas es nueva. Lo nuevo es tratarlas como un solo sistema en lugar de un montón de archivos sueltos que actualizas de vez en cuando cuando te acuerdas.
Las instrucciones son las paredes, no todo el edificio
Un archivo CLAUDE.md o AGENTS.md suele ser lo primero que se escribe, y con razón — es la forma más barata de darle a un agente arquitectura, convenciones y límites en un solo sitio.
Pero las instrucciones solo funcionan si el agente las lee, las sigue, y nada las pisa por accidente. Son las paredes del edificio. No son la fontanería, ni el cableado, ni la alarma.
Tratar un buen archivo de instrucciones como "ya he terminado con el contexto" es el mismo error que pensar que una guía de estilo por sí sola evita el mal código. Ayuda. No obliga a nada.
Skills: convertir "esto ya lo expliqué" en una unidad reutilizable
Todo ingeniero senior tiene una lista mental de "así es como hacemos X aquí" que repite a cada nueva incorporación, a cada colaborador externo, a cada compañero bien intencionado que lo hace de otra forma una vez.
Las Skills son esa lista, hecha ejecutable. En lugar de reexplicarle un procedimiento a un agente en cada sesión — cómo ejecutar una migración de forma segura, cómo estructurar la descripción de una PR, cómo validar una feature antes de darla por terminada — lo escribes una vez como Skill, y el agente lo recupera cuando es relevante.
El fallo aquí no es tener pocas Skills. Es tener Skills que se solapan, que quedan desactualizadas, o que el agente no sabe distinguir con fiabilidad. Un harness necesita tanta precisión como cobertura.
MCPs y permisos: qué puede tocar el agente de verdad
Un agente con quince herramientas que podría usar en teoría no es más capaz que uno con cinco que sabe usar con fiabilidad. Es simplemente más difícil de predecir.
Los servidores MCP definen a qué sistemas externos puede llegar un agente — una base de datos, un sistema de tickets, un pipeline de despliegue. Los permisos definen exactamente qué puede hacer con ellos: leer pero no escribir, proponer pero no fusionar, ejecutar en un sandbox pero nunca en producción.
Esta es la parte del harness que no tiene nada que ver con la inteligencia y todo que ver con el radio de impacto. Un agente bien acotado y con permisos estrechos es más seguro y, paradójicamente, más útil que uno máximamente capaz sin límites — porque puedes confiar de verdad en lo que produce sin tener que revisarlo todo a mano.
Hooks y tests: las partes que no dependen de que el agente se acuerde
Las instrucciones y las Skills describen lo que debería pasar. Los hooks y los tests son lo que garantiza de verdad que pasó.
Un hook que ejecuta el linter automáticamente después de cada cambio no depende de si el agente "se acordó" de ejecutarlo. Una suite de tests que tiene que pasar antes de marcar algo como terminado no se fía de la palabra del agente.
Esta es la diferencia entre esperar que el agente siga las reglas y hacer que le resulte estructuralmente difícil no seguirlas. Todo lo que en un harness puedas convertir de regla escrita en comprobación automática, deberías convertirlo, porque las reglas escritas se saltan y las comprobaciones automáticas no.
Puntos de revisión humana: quedarte en el bucle a propósito
Nada de esto va de eliminarte del proceso. Un harness que funciona completamente sin supervisión no es más maduro, es simplemente más arriesgado.
La regla que uso es sencilla: el agente no pasa al siguiente paso hasta que yo haya revisado y aprobado el actual. No porque no confíe en el sistema que he construido, sino porque el objetivo de construirlo era hacer mi revisión más rápida y más enfocada, no hacerla desaparecer.
Conclusión
El Context Engineering os decía qué necesita saber un agente. El Harness Engineering es lo que hace que ese conocimiento sea duradero — instrucciones, Skills, MCPs, hooks, permisos, tests y puntos de revisión humana funcionando como un solo sistema en lugar de arreglos sueltos que aplicas sesión a sesión.
Así es como lo veo ahora: un harness es el equivalente al entorno controlado en el que dejas trabajar a un agente. No consigues más confianza esperando que el agente se comporte bien. La consigues diseñando un entorno donde comportarse bien es el único camino disponible.
En el próximo artículo de esta serie veré cómo se conectan de verdad estas piezas entre sí — The Orchestrator: CI/CD Thinking Applied to AI Agents — y por qué la forma de secuenciar los pasos de Refiner, Implementation y Verification se parece mucho más a un pipeline de despliegue que a una conversación de chat.
Hasta entonces, la pregunta que merece la pena hacerse no es:
¿Ha hecho el agente lo que le pedí?
Es:
Si no hubiera estado mirando, ¿lo habría detectado igualmente el sistema que hay a su alrededor?
Si estáis construyendo algo parecido, me gustaría saber cómo es vuestro harness — no dudéis en escribirme.