Harness Engineering: por qué el modelo dejó de ser lo que importa

En marzo de 2026, por un error de empaquetado en npm, se filtró el código fuente de Claude Code. Eran unas 512.000 líneas de TypeScript. La pregunta obvia que se hizo todo el mundo fue: ¿cuánto de eso es "la inteligencia del modelo"?

La respuesta incomoda: alrededor del 1,6%. El otro 98,4% es infraestructura. Loops, herramientas, gestión de contexto, permisos, manejo de errores, verificación. Código aburrido y determinista que rodea al modelo.

Esa proporción es la mejor introducción posible a un término que se volvió central en los últimos meses: harness engineering. Si vienes escuchándolo por todos lados y no terminas de entender qué es, este artículo es para ti.

Qué es un harness, en una frase

Un agent harness (arnés de agente) es todo el código que rodea a un modelo de lenguaje para convertirlo en un agente que funciona. Todo lo que no es el modelo.

La fórmula que popularizó LangChain lo resume bien:

Agente = Modelo + Harness

La metáfora viene de la equitación. El caballo es potente pero no tiene dirección. El arnés es el conjunto de correas, riendas y monturas que canaliza esa fuerza hacia un objetivo. El modelo es el caballo. El harness es todo lo demás.

Un LLM por sí solo no es un agente. Responde a un prompt y se apaga. Se convierte en agente solo cuando algo a su alrededor le da estado, le deja ejecutar herramientas, le devuelve los resultados y le pone límites. Ese "algo" es el harness.

Vivek Trivedy, de LangChain, lo dijo de la forma más directa que he visto: "If you're not the model, you're the harness." Si no eres el modelo, eres el harness. No hay tercera opción.

De dónde salió el término

El uso moderno del término se le atribuye a Mitchell Hashimoto —cofundador de HashiCorp, creador de Terraform y del terminal Ghostty— en un post del 5 de febrero de 2026 titulado "My AI Adoption Journey". Ahí, en el paso 5 de su método ("Engineer the Harness"), dejó la definición que se volvió canónica:

"Cada vez que un agente comete un error, te tomas el tiempo de diseñar una solución para que el agente nunca vuelva a cometer ese error."

Seis días después, el 11 de febrero, Ryan Lopopolo de OpenAI publicó "Harness engineering: leveraging Codex in an agent-first world" y le dio forma institucional. Anthropic lo formalizó el 24 de marzo con su post sobre diseño de harnesses para aplicaciones de larga duración.

En cuestión de semanas, tres de los actores más serios del ecosistema convergieron en el mismo concepto. Eso no pasa por casualidad: pasa cuando un término captura algo que la gente ya estaba haciendo sin nombre.

La progresión que casi nadie distingue

Harness engineering no salió de la nada. Es la tercera capa de una evolución bastante clara:

El recorrido tiene autores concretos. Context engineering lo propuso Tobi Lütke, CEO de Shopify, y lo amplificó Andrej Karpathy en junio de 2025, cuando escribió que en cualquier aplicación seria con LLMs lo importante es "el arte y la ciencia de llenar la ventana de contexto con la información justa para el siguiente paso". Anthropic lo describió como "la progresión natural del prompt engineering". Hashimoto cerró la trilogía.

La idea de fondo: cada capa es más grande que la anterior. El prompt vive en un turno. El contexto vive en una conversación. El harness vive a lo largo de cientos o miles de turnos autónomos, a veces durante horas, sin que un humano mire.

Las siete piezas de un harness

Cuando abres cualquier harness de producción —Claude Code, Codex CLI, OpenHands— encuentras más o menos los mismos siete componentes:

1. El bucle agéntico. Es un while sorprendentemente simple: el modelo recibe el prompt y las herramientas, genera texto o llamadas a herramientas, el harness las ejecuta y devuelve el resultado, y se repite hasta terminar. Una tarea típica de Claude Code corre entre 5 y 50 vueltas de este loop. El loop en sí es trivial; toda la complejidad está en lo que lo rodea.

2. Las herramientas. Lo que convierte un chat en un agente capaz de actuar. La recomendación de Anthropic va contra la intuición: pocas herramientas de alto impacto, no una por cada endpoint de tu API. De hecho, sostienen que la herramienta más poderosa de Claude Code es bash, porque en vez de programar 50 herramientas especializadas le das al agente una computadora y lo dejas decidir.

3. Gestión del contexto. Las ventanas se llenan y aparece el context rot: el modelo empieza a recordar peor a medida que el contexto crece. La solución son técnicas como la compactación (comprimir el historial en un resumen), el borrado de resultados de herramientas viejas y la memoria externa (el agente escribe a disco lo que necesita recordar). Claude Code llega a ejecutar hasta cinco capas de compactación antes de cada llamada al modelo.

4. System prompts y scaffolding de prompts. El system prompt de Claude Code tiene del orden de 40 secciones y 50 definiciones de herramientas. OpenAI, por su parte, predica el progressive disclosure: dale al agente un mapa, no una enciclopedia. Su AGENTS.md de producción tiene apenas unas 100 líneas y funciona como tabla de contenidos.

5. Memoria. En tres niveles: la ventana activa (corto plazo), la persistencia de sesión en disco que permite hacer rewind o resume, y la memoria de largo plazo entre sesiones (archivos tipo CLAUDE.md, vector stores, scratchpads).

6. Manejo de errores y recuperación. El insight clave: los errores son feedback. Cuando una herramienta falla o se deniega, el agente no crashea; recibe el error como un resultado más y adapta su estrategia. La falla se vuelve parte del razonamiento.

7. Estado, sub-agentes y verificación. Los harnesses modernos lanzan sub-agentes con su propio contexto para tareas acotadas. El dato más fuerte aquí: según el system card de Claude Opus 4.5, parear Opus con sub-agentes Haiku da 87,0% frente al 74,8% de Opus trabajando solo. Y la verificación —tests, linters, type checks— es donde el harness muestra su mayor palanca: sin verificación mecánica, el agente "escribe la solución, relee su propio código, decide que se ve bien, y para. Sin testear nada. Por puro vibe", como lo describió LangChain.

La prueba: el mismo modelo, resultados radicalmente distintos

Hasta acá suena a teoría. Los números la aterrizan.

LangChain, febrero de 2026. Su agente subió del puesto 30+ al puesto 5 en Terminal-Bench 2.0. ¿Cambiaron el modelo? No. Siguió siendo GPT-5.2-Codex. Solo tocaron tres cosas: el system prompt, las herramientas y el middleware. El salto fue de 52,8% a 66,5% sin tocar un solo peso del modelo.

SWE-bench Pro. El mismo modelo puede oscilar hasta 22 puntos según el scaffold que lo rodee.

El caso que mejor lo resume. El Confucius Code Agent, corriendo Claude Sonnet 4.5 con un scaffold custom, obtuvo 52,7% en SWE-bench Pro. ¿El número a vencer? Claude Opus 4.5 —un modelo más potente— corriendo en el scaffold oficial de Anthropic: 52,0%. Un modelo más débil con mejor harness le ganó al modelo más fuerte con harness mediocre.

El origen académico. Nada de esto es nuevo del todo. En mayo de 2024, el equipo de SWE-agent de Princeton demostró que GPT-4 Turbo pasaba de 16% a 33,2% en SWE-bench solo cambiando lo que ellos llamaron la Agent-Computer Interface — que es, en esencia, el harness para tareas de software.

La consecuencia práctica es incómoda para quien cree que la solución siempre es el modelo siguiente: en SWE-bench Verified, los seis mejores modelos del mundo están separados por menos de un punto. La diferencia de rendimiento real ya no vive en el modelo. Vive en el sistema que lo rodea.

El cambio de mentalidad que de verdad importa

Si te quedas con una sola idea de todo esto, que sea la regla de Hashimoto.

Cuando tu agente comete un error, la reacción instintiva es reintentar o cambiar a un modelo mejor. La reacción correcta es otra: pregúntate "¿qué capacidad le falta, y cómo la hago legible y aplicable para el agente?". Y luego diseña el entorno para que ese error sea estructuralmente imposible.

Hashimoto da dos formas concretas de hacerlo. La primera es un archivo AGENTS.md donde cada línea nace de un mal comportamiento observado del agente — "casi me resolvió todos los problemas", cuenta. La segunda son herramientas programadas de verdad: scripts que toman capturas de pantalla, tests, linters, validadores, que el agente puede invocar.

OpenAI lo llevó al extremo. Un equipo que empezó con tres ingenieros construyó un sistema interno de un millón de líneas de código, con unos 1.500 PRs mergeados, todos generados por Codex y revisados por agentes. Cinco meses sin que un humano escribiera código a mano. Su lema lo dice todo: "Humans steer. Agents execute." Los humanos dirigen. Los agentes ejecutan.

Thin vs thick: la discusión abierta

No todo está resuelto. El debate más interesante es entre harnesses delgados y harnesses gruesos.

Anthropic y OpenAI empujan hacia lo delgado: pocas herramientas potentes, deja que el modelo conduzca, sube la complejidad solo cuando una evaluación demuestre que vale la pena. "Encuentra la solución más simple posible, y aumenta la complejidad solo cuando sea necesario", dice Anthropic en Building Effective Agents.

El otro extremo —orquestaciones multi-agente complejas— promete más control pero, según reportan varios equipos en producción, las swarms autónomas resultan "frágiles, prohibitivamente caras y casi imposibles de debuggear". El punto de equilibrio que está ganando en la empresa es intermedio: un supervisor, fases con compuertas claras y un humano supervisando el loop.

Y queda la pregunta de fondo, la "lección amarga" de Rich Sutton: ¿el harness se volverá obsoleto cuando los modelos absorban más capacidades? La respuesta empírica de 2026 es matizada. El scaffolding específico sí envejece —Anthropic deshabilitó un mecanismo de "context reset" que había diseñado para Sonnet 4.5 porque con Opus 4.5 se volvió peso muerto—. Pero el harness como categoría no desaparece. Solo sube de nivel de abstracción. Como dijo LangChain: cuando se filtró Claude Code eran 512.000 líneas de código, y ese código es el harness. No se va a ningún lado.

Por dónde empezar

Si esto te dejó con ganas de construir, tres pasos concretos:

Primero, lee las fuentes originales antes de escribir una línea de código. Los cuatro posts canónicos —Building Effective Agents y Effective Context Engineering de Anthropic, My AI Adoption Journey de Hashimoto y el de harness engineering de OpenAI— se leen en menos de dos horas en total y te ahorran semanas.

Segundo, no reinventes el agent loop. Empieza con un harness probado: Claude Code, Cursor o Cline para uso individual; el Claude Agent SDK u OpenHands si necesitas algo programático. Aprende del que ya funciona antes de hacer el tuyo.

Tercero, escribe tus evaluaciones antes que el agente. Define 20 o 30 tareas representativas de tu caso real, con criterios de éxito mecánicos, y mide. Si tu agente completa menos del 50% de ellas, el problema casi nunca es el modelo. Es el harness. Y eso, ahora ya lo sabes, es exactamente donde tienes el control.

El término "harness engineering" tiene apenas unos meses de vida al momento de escribir esto. Las mejores prácticas están cristalizando, no cristalizadas. Pero la idea de fondo —que el sistema alrededor del modelo importa tanto o más que el modelo— ya no está en discusión.

Más Recursos

https://ai.gopubby.com/harness-engineering-what-every-ai-engineer-needs-to-know-in-2026-0ab649e5686a