Un modelo potente recibe la tarea “corrige el checkout”. Edita el archivo correcto, anuncia la victoria y se marcha sin ejecutar una prueba. El checkout sigue roto, pero ahora tiene autoestima.
Es tentador concluir que al modelo le falta inteligencia. A veces es así. Sin embargo, muchas veces le falta el entorno que convierte capacidad en trabajo confiable: herramientas adecuadas, criterios de finalización, límites, estado persistente, pruebas y feedback.
Ese conjunto es el harness. Harness Engineering es la disciplina de diseñarlo.
¿Qué es un harness?
En inglés, harness puede referirse a un arnés, un mazo de cables o una estructura de soporte. Para los agentes, la metáfora útil es un sistema que conecta y controla la energía disponible.
El modelo decide y genera. El harness organiza todo lo que lo rodea:
- qué herramientas puede utilizar y con qué permisos;
- cómo descubre el repositorio e inicia el entorno;
- qué contexto entra en cada etapa;
- cómo el progreso y las decisiones sobreviven a otra sesión;
- qué pruebas demuestran que la tarea terminó;
- cuándo repetir, detenerse o pedir criterio humano;
- qué logs, métricas y trazas permiten investigar fallos.
No es simplemente un prompt más grande. De hecho, un manual gigantesco suele ser un harness deficiente disfrazado de documentación.
La misma inteligencia, dos resultados
Considera dos agentes con el mismo modelo.
El primero recibe acceso irrestricto al terminal y la frase “haz que funcione”. El segundo entra en un worktree aislado, lee instrucciones breves por dominio, recibe la reproducción del error, utiliza herramientas con alcance limitado, ejecuta pruebas enfocadas y solo termina cuando el criterio de aceptación es verificable.
El segundo no ganó neuronas. Ganó rieles e instrumentos.
Esa es la principal conclusión del estudio de caso de OpenAI, Harness engineering: leveraging Codex in an agent-first world. Un equipo informa haber creado un producto interno con aproximadamente un millón de líneas generadas por agentes, alrededor de 1.500 pull requests y un tiempo estimado equivalente a una décima parte del desarrollo manual.
Son cifras impresionantes, pero necesitan la etiqueta correcta: provienen de OpenAI, en un producto específico y con infraestructura diseñada para Codex. No constituyen un benchmark independiente ni una promesa universal de productividad. El valor del caso está, sobre todo, en lo que fue necesario construir alrededor del modelo.
Legibilidad antes que autonomía
Un agente no observa el sistema como un equipo que trabaja en él desde hace cinco años. Si la arquitectura solo vive en la cabeza de alguien, recibe un rompecabezas sin la imagen de la caja.
El equipo de OpenAI hizo que la aplicación fuera legible mediante entornos aislados, acceso al navegador, logs consultables, métricas, trazas, linters estructurales y reglas arquitectónicas verificadas mecánicamente. En lugar de escribir “mantén limpia la arquitectura”, codificó direcciones de dependencias permitidas e invariantes de calidad.
Una orientación pide buen comportamiento. Una restricción verificable hace observable ese comportamiento.
La documentación sigue siendo importante, pero debe funcionar como mapa. Las instrucciones globales indican dónde encontrar reglas específicas; los archivos locales describen solamente el dominio relevante. Cuando todo tiene prioridad máxima, el agente hace lo mismo que nosotros: elige algo y cruza los dedos.
El harness también transporta memoria
Las tareas largas superan una ventana de contexto. Anthropic estudió el problema en Effective harnesses for long-running agents. El experimento separó un agente inicializador, responsable de preparar el entorno y los requisitos, de sesiones posteriores que avanzaban una función por vez.
El estado sobrevivía en artefactos simples: una lista estructurada de funciones, un archivo de progreso y el historial de Git. Cada sesión comenzaba revisando el entorno y terminaba dejando código y notas en condiciones limpias para la siguiente.
Sin ese soporte aparecían dos fallos recurrentes: intentar hacerlo todo a la vez hasta agotar el contexto y, en el extremo opuesto, mirar un proyecto parcialmente listo y declararlo terminado. Cualquier parecido con una reforma doméstica es mera coincidencia.
La lección no es crear progress.txt en cada proyecto. Es volver el estado externo, verificable y retomable. Según el riesgo, puede ser una máquina de estados, una base de ejecuciones, commits, checkpoints o eventos inmutables.
Seis capas de un harness útil
| Capa | Pregunta que debe responder |
|---|---|
| entorno | ¿dónde trabaja el agente sin afectar lo que no debe? |
| contexto | ¿cómo encuentra la información correcta sin cargar el planeta? |
| herramientas | ¿qué acciones existen, con esquemas y errores comprensibles? |
| control | ¿qué permisos, límites, confirmaciones y condiciones de parada aplican? |
| verificación | ¿qué evidencia demuestra éxito o fallo? |
| observabilidad | ¿cómo reconstruimos lo ocurrido y cuánto costó? |
El modelo atraviesa estas capas en un ciclo: observar, decidir, actuar, recibir feedback y actualizar el estado. Cuando algo falla, el harness debe devolver evidencia útil — no solo error: something went wrong, el equivalente digital de gritar “salió mal” y colgar el teléfono.
Ciclos de feedback sin ruleta infinita
Los agentes mejoran cuando pueden probar sus acciones. Un compilador, una prueba unitaria o una captura de pantalla ofrece una señal más concreta que “parece correcto”. Pero los ciclos necesitan presupuesto y salida.
Define el máximo de intentos, el progreso exigido entre ellos, los fallos que admiten corrección automática, las acciones que requieren aprobación humana, las condiciones terminales y la evidencia que debe conservarse. De lo contrario, “reflexiona e inténtalo de nuevo” puede convertirse en una máquina sofisticada que repite el mismo error con palabras diferentes.
Los permisos también deben ser proporcionales. Leer archivos, editar una rama y publicar en producción no pertenecen al mismo nivel de autoridad. El harness puede comenzar restringido, ampliar solo cuando sea necesario y registrar cada efecto externo. La autonomía es una escalera, no un interruptor.
Un benchmark de modelo no mide todo el sistema
Los resultados dependen del modelo, las herramientas, el prompt, el entorno y el evaluador. METR mide horizontes de finalización con más de cien problemas, principalmente de software, ML y seguridad. La propia organización advierte que el desempeño varía con la configuración exacta del agente y que las tareas bien especificadas y evaluables automáticamente son más limpias que buena parte del trabajo económico real.
Elegir al líder de un ranking no termina la arquitectura. Mide el producto: tareas completadas con evidencia, regresiones introducidas, costo y tiempo por resultado aceptado, intervenciones humanas, fallos de permisos, efectos inesperados y recuperación después del error.
Compara también versiones del harness con el mismo modelo. A veces una herramienta mejor descrita o una prueba de aceptación clara produce más ganancia que cambiar a un modelo caro. Sin un experimento controlado, el mérito se lo lleva quien tenga el logotipo más brillante.
La idea principal
Harness Engineering cambia la pregunta de “¿qué modelo escribe mejor?” a “¿qué sistema permite que el modelo trabaje bien, de forma segura y con pruebas?”. Es un cambio de ingeniería, no de vocabulario.
El modelo sigue siendo el motor. Pero los motores no eligen la ruta, no instalan frenos, no revisan el tablero ni deciden quién recibe la llave. Un buen harness lleva esa potencia al destino — preferiblemente sin el checkout roto en el asiento trasero.
Referencias
- OpenAI. Harness engineering: leveraging Codex in an agent-first world, 2026.
- Anthropic. Effective harnesses for long-running agents, 2025.
- Anthropic. Building a C compiler with a team of parallel Claudes, 2026.
- METR. Task-Completion Time Horizons of Frontier AI Models, actualización de mayo de 2026.