Harness engineering: qué es, cómo se monta y cuándo sobra

Cuando un agente hace un mal trabajo, la tentación es cambiar de modelo. Sale uno nuevo, lo pruebas, parece que mejora y a la semana vuelves a tener los mismos problemas.

A mí me ha pasado muchas veces, y casi nunca era culpa del modelo. Eran tres fallos que aparecen con cualquiera:

• Se inventa decisiones que nadie le ha dado: si no sabe si un invitado puede comprar sin cuenta, lo decide él mientras programa. Y no te pregunta.
• Empieza cada sesión desde cero: lo que acordasteis ayer se quedó en el chat.
• Da por hecho lo que no ha comprobado: que diga “listo” no significa que lo haya verificado.

Los tres se arreglan con lo que rodea al modelo: el contexto que recibe, cómo se corta el trabajo y cómo se comprueba. A eso se le llama arnés (harness, en inglés), y a diseñarlo, harness engineering.

En este artículo te cuento qué es, de dónde sale el término, qué piezas tiene un arnés y cómo se ve dentro de un repositorio. También cuándo sobra, porque un arnés que nadie mide gasta tokens, alarga el trabajo y puede llegar a estorbar al modelo.

La versión corta

• Un agente es un modelo más todo lo que lo rodea. Eso que lo rodea es el arnés: lo que el agente sabe, lo que puede hacer y lo que lo frena.
• Con el mismo modelo, cambiar de arnés puede mover más de 18 puntos el resultado en un benchmark de agentes. Pero no siempre suma: con un modelo frontera, a veces solo encarece el trabajo.
• El arnés vive en tu repositorio y no depende de la herramienta: el mismo AGENTS.md, las mismas skills y el mismo gate sirven con Claude Code, Codex u OpenCode.
• Lo que se pueda comprobar con código no se le pide al modelo. Un test, un linter o un hook se ejecutan siempre.
• Quien escribe el código no decide si está terminado. Pasar los checks deja una feature en passing. Para llegar a accepted, la tiene que revisar alguien que no la escribió.
• Cada capa tiene que demostrar que aporta algo. Con cada modelo nuevo toca revisar cuáles siguen aportando y quitar las que estorban.

Qué es el harness engineering

Un modelo de lenguaje solo genera texto. Para que programe necesita un software alrededor que le dé herramientas (leer ficheros, ejecutar comandos, buscar en el código), lo ponga a trabajar en bucle y decida qué tiene delante en cada paso. Ese software es el arnés.

En el sector se resume con una fórmula: agente = modelo + arnés. El modelo lo pone el proveedor. El arnés es todo lo demás.

Producto · lo entrega

Interfaz, reglas de negocio, datos y límites del usuario.

Arnés · le da un marco

esto lo diseñas tú

Contexto, capacidades y control: qué sabe el agente, qué puede hacer y qué lo frena.

Agente · actúa

El modelo en bucle: decide, usa una herramienta, mira el resultado y repite.

Modelo · genera

Predice el siguiente token. Lo pone el proveedor y cambia cada pocos meses.

Aquí conviene separar dos cosas que se mezclan mucho:

1. El arnés que trae la herramienta: Claude Code, Codex u OpenCode ya son arneses, con su bucle de agente, sus herramientas, su forma de resumir el contexto cuando se llena y su sandbox. Eso lo diseña el proveedor y tú lo eliges.
2. El arnés que añades tú: el que vive en tu repositorio, con el mapa del proyecto, las specs, las skills, los permisos, las comprobaciones y la memoria entre sesiones.

El harness engineering, en el día a día de un equipo de desarrollo, es diseñar esa segunda parte para que el resultado sea fiable: que el agente sepa qué construir, que no toque lo que no debe y que no dé por bueno lo que no ha comprobado.

De dónde sale el término

La palabra viene de test harness, el montaje que rodea a un programa para ejecutarlo y probarlo. En agentes se usaba desde 2025 para hablar del software que mueve al modelo: Anthropic llamaba así a su Agent SDK, y Viv Trivedy, de LangChain, escribió sobre el harness as a service.

La expresión harness engineering aparece por primera vez, que se sepa, en un tuit de Trivedy de septiembre de 2025 que pasó casi desapercibido. Mitchell Hashimoto llegó al mismo nombre por su cuenta en febrero de 2026, en My AI Adoption Journey. Su paso cinco, Engineer the Harness, consiste en que cada vez que el agente se equivoca inviertes en algo que le impida repetir ese error. Seis días después, OpenAI lo puso en el título de un artículo en el que contaba cómo un equipo había construido un producto interno sin escribir una línea de código a mano. A partir de ahí se disparó.

Hoy hay bastante material detrás: los artículos de Anthropic sobre arneses para agentes de larga duración, los de Birgitta Böckeler en la web de Martin Fowler, los de LangChain, que popularizó la fórmula de arriba, y un tema propio en el Technology Radar de Thoughtworks de noviembre de 2026.

Una nota sobre la traducción. La versión oficial en español del artículo de OpenAI lo traduce como “ingeniería de sistemas”, que en castellano ya significa otra cosa. Aquí uso arnés para la pieza y harness engineering para la disciplina.

Prompt, contexto y arnés: tres niveles

Estas tres expresiones se usan casi como sinónimos, pero responden a preguntas distintas, y cada una contiene a la anterior.

nivel 1

Prompt engineering

Pregunta

¿Cómo se lo pido?

Qué diseñas

El mensaje

Cuánto dura

Una petición

Ejemplo

Rol, tarea, formato y ejemplos en el prompt

nivel 2 · incluye el 1

Context engineering

Pregunta

¿Qué tiene que tener delante ahora?

Qué diseñas

Todo lo que entra en la ventana de contexto en cada paso

Cuánto dura

Una sesión

Ejemplo

AGENTS.md, documentación bajo demanda, resultados de herramientas

nivel 3 · incluye el 2

Harness engineering

Pregunta

¿Cómo hago que salga bien una y otra vez?

Qué diseñas

El entorno completo en el que trabaja el agente

Cuánto dura

La vida del proyecto

Ejemplo

Specs, skills, permisos, gates, validación y memoria entre sesiones

El prompt engineering trabaja una petición. El context engineering, que popularizaron Tobi Lütke y Andrej Karpathy en junio de 2025 y que Anthropic desarrolló en un artículo de referencia, trabaja todo lo que el modelo tiene delante en cada paso. El harness engineering incluye eso y también lo que actúa aunque el modelo no lo lea: un hook, una regla de permisos, un test o la CI no pasan por la ventana de contexto, salvo como mensaje de error.

No todo el mundo lo ordena igual. Para HumanLayer, el harness engineering es una parte del context engineering. Para LangChain o Thoughtworks, es al revés. A mí me sirve una distinción más práctica, que también usa la documentación de Claude Code: las instrucciones que el agente lee puede ignorarlas, pero un hook o un test se ejecutan igual.

¿Importa tanto como el modelo?

Terminal-Bench 2.0 es un benchmark de 89 tareas de terminal para agentes. En su clasificación, cada entrada es una pareja de modelo y arnés, así que se puede ver el mismo modelo con arneses distintos:

Claude Opus 4.6

• Claude Code · el del fabricante58,0 %
• Meta-Harness · el mejor76,4 %

GPT-5.5

• clnkr · el peor66,1 %
• Codex CLI · el del fabricante82,2 %
• NexAU-AHE · el mejor84,7 %

Gemini 3.1 Pro

• Gemini CLI · el del fabricante61,4 %
• TongAgents · el mejor80,2 %

Claude Haiku 4.5

• OpenHands · el peor13,9 %
• Claude Code · el del fabricante27,5 %
• Goose · el mejor35,5 %

Con modelos frontera, la diferencia entre el mejor y el peor arnés pasa de 18 puntos, y con un modelo pequeño como Haiku el mejor arnés saca más del doble que el peor. Además, el arnés del propio fabricante no siempre gana: con Opus 4.6, Claude Code queda último de diez. El mejor de esa lista, Meta-Harness, es un arnés que optimiza automáticamente otro agente.

LangChain hizo el experimento en limpio. Dejó fijo el modelo (gpt-5.2-codex), tocó solo el system prompt, las herramientas y el middleware de su agente, y pasó del 52,8 % al 66,5 % en el mismo benchmark.

Pero conviene no exagerar. Un estudio de Berkeley, Agents’ Last Exam, concluye que, entre sistemas bien hechos, elegir el modelo explica unas tres veces más diferencia que elegir el arnés. Y otro de LMArena con Claude Code, Codex CLI y Pi, HarnessTax, vio que el acierto apenas cambiaba entre los tres mientras el coste variaba hasta cinco veces.

La conclusión que saco es que el arnés importa mucho con modelos menos potentes, y con un modelo frontera puede ser puro coste. Naresh Jain lo midió en octubre con el mismo arnés y dos modelos de OpenAI:

Ejecuciones aceptadas, de 10

• GPT-6 Luna · sin arnés3
• GPT-6 Luna · con arnés10
• GPT-6 Sol · sin arnés10
• GPT-6 Sol · con arnés10

Coste estimado por ejecución

• GPT-6 Luna · sin arnés0,09 $
• GPT-6 Luna · con arnés0,27 $
• GPT-6 Sol · sin arnés0,41 $
• GPT-6 Sol · con arnés2,68 $

Hay otro motivo, más práctico. El modelo cambia cada pocos meses y la herramienta de moda, cada pocas semanas, pero el arnés se queda: si mañana cambias Codex por Claude Code, tu AGENTS.md, tus specs, tus skills y tu gate siguen funcionando, porque son ficheros de tu repositorio. El agente puede ir cambiando, pero el arnés es tuyo.

Las seis piezas de un arnés

Cada fuente divide el arnés a su manera. Yo lo explico con tres familias: lo que el agente sabe (contexto), lo que puede hacer (capacidades) y lo que lo frena (control). Dentro hay seis piezas, y cada una actúa en un momento distinto de la sesión.

01

Al arrancar

• El mapaAGENTS.md: qué es el proyecto y dónde mirar
• La memoriaDónde lo dejamos: progreso, estado y git
• El encargoUna feature, su spec y su Definition of Done

02

Mientras trabaja

decide → usa una herramienta → mira el resultado ↺

• Las capacidadesSkills, CLI del proyecto y MCP
• Los límitesPermisos, hooks, entorno aislado, roles

03

Antes de darlo por hecho

• El gateLint, tipos, tests y build, ejecutados con código
• La validaciónOtra sesión revisa contra la spec

ContextoCapacidadesControlla sesión deja la memoria al día para la siguiente ↺

1. El mapa: un AGENTS.md corto que apunta a lo demás

AGENTS.md es lo primero que lee el agente al empezar. Funciona mejor como mapa que como enciclopedia: qué es el proyecto, cómo se arranca, cuál es la siguiente tarea y cómo se comprueba. El detalle va en otros documentos que el agente lee solo cuando le hacen falta.

Esto es lo que me funciona:

• Empieza corto: entre 30 y 50 líneas al principio. Hacia las 150 empieza a ser demasiado grande. A partir de ahí, mueve secciones a otros ficheros y deja el enlace.
• Si el agente falla dos veces en lo mismo, entra una línea: si nunca ha fallado en algo, esa línea sobra.
• Escribe reglas que se puedan comprobar: “Código limpio” no le dice nada. “Funciones de 40 líneas como máximo”, sí.
• Un solo fichero para todas las herramientas: Codex y OpenCode leen AGENTS.md. Claude Code solo lo usa como plan B si no hay un CLAUDE.md, así que yo lo resuelvo con un enlace simbólico. Aquí lo probé fichero a fichero.

Estas cifras no son al azar. OpenAI cuenta que su AGENTS.md ronda las 100 líneas y funciona como índice de una carpeta docs/ bien ordenada. El fichero gigante con el que empezaron fracasó: desplazaba la tarea del contexto, se quedaba viejo enseguida y, con tantas instrucciones, el agente no sabía cuáles importaban. Y un estudio de ETH Zúrich encontró que los que genera un LLM no mejoran el resultado, que los escritos a mano les sacan ventaja y que cualquiera de los dos encarece cada sesión entre un 20 y un 23 %. Así que no lo generes con un comando y te olvides. Escríbelo tú y quita las líneas que no aporten.

Así empieza el AGENTS.md de un ejemplo público, una web de reservas de pádel:

# Instrucciones para agentes

Este repositorio contiene una web de reservas de pistas de pádel para un club.

## Leer primero
- `CONTEXT.md`: glosario del dominio (usar "franja", nunca "turno").
- `docs/build-brief.md`: problema, objetivos y MVP.
- `docs/domain-model.md`: entidades y reglas de reserva.

## Flujo de arranque
1. Leer `PROGRESS.md` y `feature_list.json`.
2. Elegir la primera feature cuyas dependencias estén en `accepted`.
3. Ejecutar `./init.sh`. Si falla, arreglar la base antes de nada.

## Reglas de trabajo
- Una feature cada vez.
- No marcar una feature como terminada solo porque haya código.
- Las reglas de negocio se hacen cumplir en el servidor, no solo en la interfaz.

El propio código también es parte del mapa. En un proyecto ordenado, el agente encuentra antes lo relevante, duplica menos y mantiene la coherencia. Eso no significa exigir código perfecto desde el primer día: en PostFlow dejé que la IA escribiera código desordenado a propósito y lo ordené después, con tests que me decían cuándo había terminado.

2. El encargo: features pequeñas, una spec y una definición de terminado

El agente necesita saber qué construir y cuándo ha terminado. Si no se lo dices, lo decide él.

Features del tamaño de una sesión. El trabajo se corta en una lista de features, cada una con su estado, sus dependencias y cómo se comprueba. Una regla que uso mucho: si no puedes verificar una feature con un escenario concreto, está mal cortada. En un MVP que no sea trivial suelen salir entre 12 y 30. Si te salen cinco, son demasiado grandes.

{
  "id": "member-book-slot",
  "title": "El socio reserva una franja libre",
  "depends_on": ["member-week-availability"],
  "status": "not_started",
  "verification": [
    "Test: reservar una franja libre crea una Reserva confirmada.",
    "Test: reservar una franja ya ocupada devuelve error."
  ],
  "evidence": []
}

Una spec por feature. Es el contrato entre quien la planifica, quien la implementa y quien la valida: el objetivo, lo que queda fuera, los escenarios de aceptación, cómo se va a verificar y qué evidencias hay que guardar. Debería ocupar entre 100 y 250 líneas. Si crece más, la feature es demasiado grande. Herramientas como Spec Kit u OpenSpec formalizan este enfoque (el spec-driven development), pero yo prefiero una versión ligera: una spec gigante que nadie lee es otra forma de cascada.

Una definición de terminado. Una feature está terminada cuando el comportamiento está implementado, la verificación se ha ejecutado de verdad, la evidencia está registrada, el repositorio sigue arrancando y la documentación está al día. La tarea no termina cuando el código está escrito.

3. La memoria: lo que sobrevive a la sesión

Cada sesión empieza con el contexto vacío. Lo que no esté escrito en el repositorio no existe para la siguiente. Por eso el arnés guarda la memoria en ficheros:

• PROGRESS.md, con el estado verificado actual y el siguiente paso arriba, y un registro breve de sesiones debajo.
• La lista de features como única fuente de verdad del estado.
• Git, con commits pequeños que expliquen el porqué.
• init.sh como puerta de entrada: cada sesión empieza ejecutándolo y sabiendo si la base está sana.

Anthropic describió este patrón en su artículo sobre agentes de larga duración. Un agente inicializador prepara el entorno: un init.sh, un fichero de progreso, la lista de features en JSON y un primer commit. Después, cada sesión arranca igual: mira dónde está, lee el historial de git y el progreso, elige la siguiente feature, ejecuta init.sh y lanza una prueba básica antes de tocar nada. Usaron JSON para la lista porque el modelo la reescribía de forma indebida menos que si era Markdown.

Para comprobar que esta pieza funciona, abre una sesión nueva, sin el chat de ayer, y mira si el agente sabe continuar.

4. Las capacidades: skills, herramientas y MCP

Una skill es una carpeta con un SKILL.md (qué hace y cuándo usarla) y, si hace falta, referencias y scripts. El agente solo ve su descripción hasta que la necesita, así que puedes tener muchas sin llenar el contexto. El formato es abierto (Agent Skills) y funciona en Claude Code, Codex y OpenCode.

Las mejores skills que tengo nacieron de un tropiezo. Cuando veo que el agente falla varias veces en el mismo paso, lo convierto en una skill, sobre todo si necesita referencias o código. Si basta con una frase, va al contexto del proyecto.

Las otras capacidades son las herramientas: los scripts y la CLI del propio proyecto, y servidores MCP cuando aportan algo que no tienes de otra forma, como abrir un navegador para comprobar una pantalla.

Un aviso: una skill de terceros es código que el agente ejecuta con tus permisos. Léela antes de instalarla, igual que harías con una dependencia. Lo conté más a fondo en este artículo sobre skills.

5. Los límites: permisos, hooks, entornos aislados y roles

Si escribes “no toques el .env” en el AGENTS.md, el agente puede saltárselo. Si deniegas la lectura de ese fichero en los permisos, no puede. Por eso los límites importantes van en la configuración:

• Permisos: qué comandos puede ejecutar sin preguntar, cuáles tiene que consultarte y cuáles tiene prohibidos.
• Hooks: acciones que se ejecutan siempre en un evento del agente: antes de lanzar un comando, después de editar un fichero, al terminar. Sirven para bloquear lo peligroso o pasar el linter sin que nadie se acuerde.
• Entornos aislados: un worktree o un contenedor por tarea, para que dos agentes no se pisen. Ojo: un worktree aísla los ficheros, no el entorno. Puertos, .env y base de datos siguen siendo compartidos si no los separas.
• Roles: un subagente con una tarea concreta y permisos acotados. Este validador, parecido al que enseñé en una charla sobre subagentes, puede ejecutar los checks, pero no editar código ni lanzar otros agentes.

---
description: Valida una feature contra su spec.
mode: subagent
permission:
  edit: deny
  bash: allow
  skill: { "*": deny, feature-validator: allow }
  task: deny
---
Eres el subagente validador. Usa la skill feature-validator.

Un hook, en Claude Code, se declara en .claude/settings.json y apunta a un script. Si el script termina con código 2, la acción se bloquea:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": ".claude/hooks/bloquear-destructivos.sh" }]
      }
    ]
  }
}

La documentación de Claude Code lo plantea así: lo que no admite excepciones va a un hook o a una regla de denegación. Y avisa del extremo contrario: si tienes cuarenta hooks, casi todos son preferencias.

Con los subagentes conviene no pasarse. Compensan para investigar en paralelo cosas independientes, para aislar un contexto muy pesado o para revisar con criterios concretos. Una cadena fija de especialistas que se pasan el trabajo suele salir cara: cada uno empieza de cero, los traspasos fallan y se revisan unos a otros sin fiarse.

1. Lo pidesUna línea en AGENTS.md"Usa pnpm, nunca npm"Depende de que el modelo lo lea y lo recuerde.
2. Lo empaquetasUna skillEl procedimiento de release, con sus pasos y referenciasSe carga cuando toca, pero sigue siendo texto.
3. Lo vigilasUn hookBloquear rm -rf o pasar el linter tras cada ediciónSe ejecuta siempre, en un evento del agente.
4. Lo compruebasEl gate y la CILint, tipos, tests y build antes de aceptar nadaSi no pasa, no está hecho, diga lo que diga el agente.
5. Lo decide tu códigoEl orquestadorSolo hace commit si el validador devuelve acceptEl modelo no se lo puede saltar.

garantía→

6. Las comprobaciones: el gate y la validación independiente

Para mí es la pieza que más cambia el resultado, y la que menos veo montada.

El gate es un script que comprueba lo que se puede comprobar con código: instalación, linters, tipos, tests, build y algún smoke test. Tiene que ejecutarse de verdad. Un init.sh que solo imprime los comandos da una falsa sensación de seguridad. Y el mismo gate corre en la CI, en cada PR.

#!/usr/bin/env bash
set -euo pipefail
cd "$(dirname "$0")"

pnpm install --frozen-lockfile
pnpm lint
pnpm typecheck
pnpm test
pnpm build

La validación independiente la hace alguien que no escribió el código: otra sesión, otro agente o tú. Recibe la spec, el diff y las evidencias, no un resumen de lo bien que ha ido, y devuelve un veredicto. Anthropic lo vio al montar arneses para aplicaciones largas: el modelo que evalúa su propio trabajo tiende a darlo por bueno, así que separaron al que genera del que evalúa.

Böckeler lo ordena en dos tipos de control: guías, que orientan al agente antes de actuar, y sensores, que le avisan después. Los dos pueden ser deterministas o pasar por un LLM. Los deterministas son los más baratos y fiables y, según ella, los menos aprovechados.

1. specEl contratoAlcance, escenarios y Definition of Done→
2. implementerImplementaPasa el gate y deja la feature en passing→
3. validatorValida en otra sesiónLee la spec, el diff y las evidencias, sin fiarse del autor

veredicto del validator

• acceptqueda accepted: commit o PR
• revisevuelve al implementer con lo que falta (con un límite de vueltas)
• blockse para y te lo cuenta: falta una decisión

not_started → in_progress → passing → accepted

Esta separación es la que más me ha enseñado. Cuando monté un sistema de desarrollo autónomo, la lección más importante fue que quien detecta los problemas no debe ser quien los arregla. El primer día, un agente independiente que cada cuatro horas compilaba y pasaba los tests pilló siete regresiones que el propio executor había introducido al hacer cambios en paralelo.

Así se ve en un repositorio

Con las seis piezas juntas, un arnés son unos pocos ficheros de texto, unos scripts y algo de configuración, sin nada que dependa de una herramienta concreta.

tree -a tu-proyecto

• tu-proyecto/
• AGENTS.md# el mapa: qué es, cómo se arranca, dónde mirar
• CONTEXT.md# el glosario del dominio
• PROGRESS.md# dónde lo dejó la última sesión
• feature_list.json# qué construir y en qué estado está
• init.sh# el gate: instala, lint, tipos, tests y build
• docs/
• build-brief.md# qué es, para quién y qué queda fuera
• specs/<feature>.md# el contrato de cada feature
• .agents/skills/# procedimientos que se cargan cuando tocan
• .claude/skills → ../.agents/skills# las mismas skills para Claude Code
• .opencode/agents/validator.md# un rol con permisos acotados
• .github/workflows/gate.yml# el mismo gate en cada PR

El mismo encargo, con y sin arnés

Esta es la misma petición, con y sin arnés:

chat — sin arnés

hazme el login con Google

✓ ¡Hecho! Login implementado.

✗ 4 tests failing

✗ el signup ha dejado de funcionar

arréglalo...

agente — con tu arnés

hazme el login con Google

→ leyendo AGENTS.md y contexto

→ spec: alcance + criterios de aceptación

→ implementando (solo archivos del alcance)

✓ tests 12/12 · lint ok

✓ PR listo para tu revisión

Indicador	sin arnés	con arnés
tests	✗ 4 fallando	✓ 12/12
alcance	reescribe media app	solo lo que dice la spec
tu papel	arreglar lo que rompe	revisar el PR

Sin arnés, el agente no sabe qué está dentro del alcance, así que toca lo que le parece. Dice que ha terminado porque ha escrito código, y te enteras de que el registro se ha roto cuando lo pruebas tú. Tu papel pasa a ser arreglar lo que rompe.

Con arnés, el mismo modelo lee el mapa, trabaja contra una spec con criterios de aceptación, toca solo los ficheros de esa feature y no da nada por hecho hasta que el gate pasa y la validación lo acepta. Tu papel pasa a ser revisar una PR.

Cuando el arnés funciona, llega el bucle

Con las comprobaciones en su sitio, puedes dejar que el agente trabaje en bucle: spec, implementación, validación y decisión, una y otra vez, con un presupuesto de tiempo, de gasto y de reintentos. Es lo que se ha llamado loop engineering, y te lo enseñé con Codex en este artículo.

Luego viene el paralelismo: varias features a la vez, cada una en su worktree, con el mismo gate en cada PR. Y aparecen problemas nuevos, como dos PR en verde que chocan al integrarse.

Por eso conviene ir en orden: primero la validación, después la autonomía y al final el paralelismo. Si paralelizas sin validar, solo multiplicas los errores.

El último paso es sacar el flujo del texto y llevarlo al código. Una skill puede pedir que no se haga commit sin el visto bueno del validador, pero el modelo puede saltárselo. Un orquestador escrito por ti lo garantiza, porque el siguiente paso ya no lo decide el modelo.

Cuándo una capa sobra

Un arnés no mejora por tener más piezas.

Parte del harness engineering es una solución temporal a las limitaciones de los modelos. Con cada generación hay capas que dejan de hacer falta, y algunas empiezan a estorbar: más tokens, más tiempo y un modelo que trabaja peor porque le estás atando las manos. Lo conté en este vídeo:

Robert C. Martin (Uncle Bob) contó que había probado a quitar por completo su sistema de agentes, que tenía hasta seis niveles, y que con la misma tarea obtuvo un resultado mejor en menos tiempo. A mí me pasó algo parecido con un auditor que validaba las specs: tardaba mucho más, se comía la cuota y el resultado no era mejor.

Y no es cosa de dos. Anthropic explica que cada pieza de un arnés codifica una suposición sobre lo que el modelo no sabe hacer solo, y con Opus 4.5 y 4.6 quitó piezas que antes eran imprescindibles. Vercel quitó el 80 % de las herramientas de uno de sus agentes y, en su prueba, acertó más, en menos tiempo y con menos tokens.

Por eso hoy mi arnés mínimo tiene cuatro piezas:

1. 1AGENTS.md como mapaInstrucciones de entrada claras que apuntan a la documentación que solo se carga cuando hace falta.
2. 2Una buena arquitecturaCódigo limpio y bien organizado: el agente encuentra antes lo relevante, duplica menos y mantiene la coherencia.
3. 3Skills que nacen de un tropiezoCuando el agente falla varias veces en el mismo paso, ese paso se convierte en una skill o en una línea de contexto.
4. 4Gates deterministasCompilar, tests, linters, tipos y smoke tests con scripts. Lo que puede hacer un script no gasta tokens.

Y antes de añadir cualquier otra cosa, me hago cinco preguntas:

1. 01¿Qué fallo concreto resuelve?Y en qué tareas aparece. Si no hay un fallo concreto, la capa sobra.
2. 02¿Se arregla con algo más simple?Aclarar el contexto, mejorar una herramienta o añadir una comprobación automática suele bastar.
3. 03¿Qué mejora esperas?Decídelo antes, para poder medirla cuando la capa esté montada.
4. 04¿Compensa lo que cuesta?Tiempo, tokens, mantenimiento y las revisiones que tocarán con cada modelo.
5. 05¿Sigue aportando con el siguiente modelo?O empieza a estorbar. Lo que hoy ayuda puede frenar al modelo de mañana.

si sigue ayudando → se queda ·si el modelo nuevo ya no la necesita → se quita

Esto incluye lo que te cuento en este artículo. Si una pieza no resuelve un fallo que tengas, no la montes.

Por dónde empezar

No hace falta montarlo todo de golpe. Este es el orden que recomiendo:

1. 1 · El primer díaUn gate y una lista de featuresinit.sh que compila y pasa los tests, AGENTS.md como mapa y features del tamaño de una sesión.
2. 2 · La primera semanaUn bucle con validaciónSpec por feature, implementación y una validación en otra sesión que decide si queda aceptada.
3. 3 · DespuésParalelismo y CIVarias features a la vez en entornos aislados, el mismo gate en cada PR y tú revisando.

1. Escribe el mapa: un AGENTS.md de 30 a 50 líneas que diga qué es el proyecto, cómo se arranca, dónde está cada cosa y cómo se comprueba.
2. Monta el gate: un init.sh que ejecute de verdad la instalación, el linter, los tipos, los tests y el build.
3. Corta el trabajo: una lista de features del tamaño de una sesión, con su estado y su forma de verificarlas.
4. Escribe una spec antes de cada feature y decide qué evidencias quieres ver.
5. Valida en otra sesión: que no se acepte nada que no haya revisado alguien que no lo escribió.
6. Convierte los tropiezos en piezas: lo que falla dos veces va al contexto, a una skill o, mejor aún, a una comprobación.

Errores que veo a menudo

• Un AGENTS.md enciclopedia: quinientas líneas que el agente lee en cada sesión y que nadie mantiene. Mejor un mapa corto y documentos que se cargan cuando hacen falta.
• Las reglas importantes, solo en texto: si una regla rota cuesta dinero o datos, tiene que vivir en un permiso, un hook o un test.
• Validar en la misma sesión que implementa: el agente que escribió el código tiende a darlo por bueno. La validación tiene que empezar con un contexto limpio.
• Features gigantes: si no caben en una sesión, el contexto se llena a mitad y el agente pierde el hilo.
• Paralelizar antes de validar: cuatro agentes sin comprobaciones son cuatro fuentes de errores.
• Copiar el arnés de otro: el de un equipo de OpenAI o el mío resuelven fallos que quizá tú no tienes.
• No revisar el arnés con cada modelo nuevo: lo que hace tres meses arreglaba un fallo hoy puede estar frenando al agente.

Preguntas frecuentes

¿Harness engineering y context engineering son lo mismo?

No. El context engineering decide qué tiene delante el modelo en cada paso. El harness engineering incluye eso y además lo que pasa fuera de la ventana de contexto: los permisos, los hooks, los gates, la validación y la memoria entre sesiones.

¿Necesito Claude Code, o vale con Codex, OpenCode o Cursor?

Vale con cualquiera. El arnés son ficheros de tu repositorio: AGENTS.md, specs, skills en .agents/skills, scripts y configuración. Cambia cómo se declara cada permiso o cada hook, pero las piezas son las mismas.

¿Cuánto se tarda en montar un arnés mínimo?

Un mapa, un gate y una lista de features se montan en una tarde. Lo que lleva tiempo es ajustarlo: ver dónde falla el agente y convertir cada fallo en una pieza.

¿Sirve en un proyecto que ya existe?

Sí. Es donde más falta hace, aunque también donde más cuesta montarlo. Empieza por el gate y por un AGENTS.md que explique cómo arranca el proyecto y qué no se toca. El código existente ya es contexto. Tu trabajo es ayudar al agente a encontrar lo que importa.

¿Los modelos nuevos harán innecesario el arnés?

Una parte, sí. Hay capas que hoy compensan limitaciones de los modelos y que irán sobrando. Otras no: un modelo mejor sigue sin saber qué quieres construir, qué reglas tiene tu negocio o cómo se comprueba que no ha roto nada.

¿Tengo que usar subagentes?

No. Compensan para investigar en paralelo, aislar un contexto pesado o validar con criterios concretos. Como cadena fija de especialistas, casi nunca.

¿Dónde puedo aprender harness engineering en español?

Para empezar, el Harness Starter es gratuito: una guía y cuatro skills para montar la base. Si quieres montar el arnés completo, con roles, bucle, paralelismo y tu propio orquestador, sobre tu proyecto y con acompañamiento, eso es AI Expert.

Fuentes y lecturas

Si quieres ir a las fuentes, estas son las que más me han servido:

• OpenAI (Ryan Lopopolo), Harness engineering: leveraging Codex in an agent-first world, febrero de 2026.
• Mitchell Hashimoto, My AI Adoption Journey, febrero de 2026.
• Anthropic, Effective harnesses for long-running agents, noviembre de 2025, y Harness design for long-running application development, marzo de 2026.
• Anthropic, Effective context engineering for AI agents, septiembre de 2025.
• Birgitta Böckeler, Harness engineering for coding agent users, abril de 2026.
• LangChain, Improving Deep Agents with harness engineering, febrero de 2026, y The Anatomy of an Agent Harness, marzo de 2026.
• HumanLayer, Skill Issue: Harness Engineering for Coding Agents, marzo de 2026.
• Naresh Jain, Are Harnesses Worth the Cost?, octubre de 2026.
• Agents’ Last Exam (Berkeley) y HarnessTax (LMArena), los dos estudios que matizan cuánto pesa el arnés frente al modelo.
• La guía de buenas prácticas de Claude Code, en español.
• Learn Harness Engineering, un curso abierto traducido al español, centrado en tareas largas.