¿Qué es la ingeniería de arnés (Harness Engineering)? Diseñar la capa que rodea al LLM en la era de los agentes de IA

La ingeniería de arnés (harness engineering) es un término que se extendió en febrero de 2026. El 5 de febrero de 2026, Mitchell Hashimoto (creador del terminal Ghostty y cofundador de HashiCorp) lo usó para describir un hábito: cada vez que un agente se equivoca, construyes una solución para que no vuelva a cometer ese error. Seis días después, OpenAI lo puso en el título de un informe de su equipo de Codex. Anthropic ya venía publicando diseños de la maquinaria que rodea a los agentes de larga duración con el nombre de «arnés». Si en 2025 se dijo que después de los prompts venía la ingeniería de contexto, la ingeniería de arnés se ocupa de la capa que queda aún más afuera.

Este artículo explica qué es realmente la ingeniería de arnés, en qué se diferencia de la ingeniería de prompts y de contexto, los seis componentes que conforman un arnés, arneses reales que OpenAI y Anthropic han publicado, una lista de verificación práctica y una comparación de las herramientas líderes: la base que necesitas si te tomas en serio el uso o la construcción de agentes de IA.

1. ¿Qué es la ingeniería de arnés (Harness Engineering)?

"Harness" se refiere originalmente al equipo y arreos usados sobre un caballo: el aparejo que canaliza la fuerza del animal en la dirección que quieres. El término en IA funciona exactamente con la misma metáfora: el conjunto completo de equipamiento que pone a trabajar de forma productiva a un LLM potente pero indómito.

Concretamente, eso incluye:

• Herramientas (tools): operaciones de archivos, búsqueda web, ejecución de código — los medios por los cuales el LLM puede actuar.
• Gestión de contexto: la estrategia sobre qué entra en el prompt y qué se comprime o se descarta.
• Sistemas de memoria: conocimiento persistente y preferencias del usuario que sobreviven entre sesiones.
• Bucle del agente: el ciclo percibir → razonar → actuar → observar.
• Guardarraíles (guardrails): permisos, sandbox, Hooks, flujos de aprobación.
• Formato de salida: markdown, JSON, citas, streaming.

Diseñar todo eso en conjunto es lo que llamamos ingeniería de arnés. En lugar de entrenar o mejorar el LLM en sí, es el oficio de elevar la utilidad real diseñando todo lo que rodea al LLM. Claude Code, Cursor, Devin, Codex CLI: todos funcionan con modelos más o menos iguales y, sin embargo, su comportamiento y rendimiento divergen marcadamente debido a la diferencia de sus arneses.

Para saber dónde empieza y dónde termina la palabra «arnés», lo resume bien Birgitta Böckeler, de Thoughtworks, en martinfowler.com (2 de abril de 2026): el arnés es todo lo que hay en un agente excepto el modelo, o sea, Agent = Model + Harness. Anthropic usa la misma palabra para su propio servicio en la nube: describe Claude Managed Agents como un arnés de agente configurable.

2. Ingeniería de arnés vs. ingeniería de prompts

La ingeniería de prompts no ha desaparecido, pero el alcance es fundamentalmente distinto.

Si la ingeniería de prompts es el oficio de "qué decirle al LLM", la ingeniería de arnés es el oficio de "qué darle al LLM y cómo operarlo". Las dos no compiten: están en capas. El prompt es solo un componente dentro del arnés.

El otro término que se confunde es la ingeniería de contexto. En una publicación del 29 de septiembre de 2025, Anthropic la presentó como la evolución natural de la ingeniería de prompts. Böckeler describe la construcción del arnés de un agente de programación como una forma concreta de ingeniería de contexto. Juntas forman capas: prompt (lo que dices) ⊂ contexto (lo que el modelo ve) ⊂ arnés (lo que se le da, cómo se revisa su trabajo y cómo se le detiene). Lo propio del arnés es la parte que comprueba los resultados de forma mecánica y le devuelve los fallos al agente, como los linters y los tests.

3. Los 6 componentes de un arnés

1. Uso de herramientas (Tool Use)

El medio del LLM para actuar en el mundo: leer y escribir archivos, ejecutar código, buscar en la web, llamar APIs. Si te equivocas con la interfaz de la herramienta — nombres, argumentos, valores de retorno —, el LLM no podrá usarla correctamente. Concretamente:

• Nombres basados en verbos, sin ambigüedad (p. ej. read_file).
• Argumentos obligatorios vs. opcionales explícitos, con valores por defecto.
• Mensajes de error estructurados ante fallos (decirle al modelo qué hacer a continuación).
• Advertencias explícitas en operaciones con efectos secundarios (destructivas).

2. Gestión de contexto

La atención del LLM es finita: lo que le muestras determina lo que dice. Concretamente:

• Filtrado por relevancia: extraer solo las partes relevantes para la tarea, no archivos enteros.
• Compactación: resumir conversaciones largas para conservarlas.
• Integración con RAG: traer lo necesario mediante búsqueda vectorial.
• Caché: recortar coste en system prompts repetidos usando herramientas como el prompt cache de Anthropic.

Relacionado: ¿Qué es RAG?

3. Sistema de memoria

Mantener conocimiento entre sesiones. CLAUDE.md de Claude Code, .cursor/rules de Cursor y AGENTS.md de Codex son todos ejemplos de memoria de proyecto. Más allá de eso:

• Memoria a corto plazo: historial reciente de conversación.
• Memoria a largo plazo: perfil del usuario, decisiones pasadas.
• Conocimiento factual: bases de conocimiento específicas del dominio.

4. Bucle del agente

El núcleo que hace que un "agente de IA" funcione realmente. La forma base es el ciclo percibir → razonar → actuar → observar:

1. Recibir el objetivo del usuario.
2. Analizar el estado actual (recopilar información con herramientas si es necesario).
3. Planificar la siguiente acción.
4. Actuar mediante una herramienta.
5. Observar el resultado; comprobar si se cumple el objetivo.
6. Iterar si no, terminar si sí.

Lo inteligente que llegue a ser tu agente depende de si incorporas replanificación, autocrítica y descomposición en subobjetivos.

5. Guardarraíles (Guardrails)

Los mecanismos que evitan comportamientos descontrolados. Como cubre Por qué la IA ignora tus reglas .md, imponer el comportamiento a través del entorno es mucho más fiable que pedirlo amablemente en prosa:

• Modo de aprobación: una persona confirma antes de que se ejecuten operaciones peligrosas (p. ej., los permisos de Claude Code o los modos de aprobación de Codex CLI).
• Sandbox: restringir el acceso al sistema de archivos y a la red.
• Hooks: comprobaciones arbitrarias antes y después de las llamadas a herramientas.
• Limitación de tasa: minimizar el daño si algo se descontrola.

6. UX de salida

Presentar los resultados de forma que el usuario pueda entender y verificar. Renderizado de markdown, citas de fuentes, bloques de código con resaltado de sintaxis, salida en streaming, razonamiento visible (thinking), salida estructurada (JSON), etc. Producir la "respuesta correcta" no basta: es trabajo del arnés entregarla en una forma en la que el usuario pueda confiar y verificar.

4. ¿Por qué la ingeniería de arnés y por qué ahora?

Tres fuerzas están impulsando el auge del interés en el trabajo de arnés.

1. Se ha demostrado que el mismo modelo da resultados muy distintos según lo que lo rodea. En un experimento que Anthropic publicó el 24 de marzo de 2026, se le pidió al mismo modelo Claude Opus, en una sola frase, crear un editor de videojuegos retro en 2D. Un agente solo terminó en 20 minutos por 9 $, pero el nivel que generó no se podía jugar. Un arnés dividido en planificador, generador y evaluador tardó 6 horas y costó 200 $, y produjo un juego en el que sí se podía mover al personaje (la física seguía siendo tosca). El coste fue más de 20 veces mayor, pero la diferencia de calidad también. Elegir entre calidad y coste es ya una decisión tanto del arnés como del modelo.

2. Los problemas que los prompts por sí solos no pueden resolver se acumulan. "Demasiadas herramientas, el modelo elige la equivocada". "El contexto está tan saturado que la señal importante queda enterrada". "En tareas largas, el agente pierde el hilo a mitad de camino". Estos no son problemas que se arreglen con una redacción más ingeniosa en un solo turno: son problemas de diseño.

3. El propio trabajo del ingeniero ha empezado a cambiar. El equipo de Codex de OpenAI contó que construyó un producto interno durante cinco meses sin una sola línea de código escrita a mano, hasta llegar a cerca de un millón de líneas y unas 1.500 pull requests (11 de febrero de 2026). Su conclusión: el trabajo principal pasó de escribir código a diseñar entornos, especificar la intención y construir bucles de retroalimentación. Claude Code, Codex, Cursor, Devin y los demás productos importantes compiten en el diseño que queda fuera del modelo.

5. Ejemplos publicados: tres arneses reales

La ingeniería de arnés tiende a quedarse en lo abstracto. Estos son tres ejemplos cuyos autores publicaron los detalles, contados al nivel de lo que hicieron de verdad.

1. El equipo de Codex de OpenAI: AGENTS.md como mapa y reglas impuestas con linters

• Mantuvieron AGENTS.md como un índice de unas 100 líneas y convirtieron un directorio docs/ del repositorio en la fuente de verdad para diseño, planes y notas de calidad. Un único archivo gigante desplazaba la tarea del contexto, se quedaba obsoleto enseguida y no se podía verificar de forma mecánica.
• Para que la documentación no envejezca, linters y CI comprueban los enlaces cruzados y la estructura, y un agente recurrente busca descripciones que ya no coinciden con el código y abre PR de corrección.
• La división en capas, la dirección de las dependencias, los logs estructurados, el tamaño máximo de archivo y más se imponen con linters propios y tests estructurales. Los mensajes de error explican cómo arreglar el problema, para que el agente los lea y corrija su propio trabajo.

2. Anthropic: diseñar el relevo de los agentes de larga duración

Cuando el desarrollo abarca muchas ventanas de contexto, los agentes intentaban construir demasiado de golpe o daban el trabajo por terminado a medias. Anthropic (26 de noviembre de 2025) lo resolvió así:

• Solo la primera sesión ejecuta un agente inicializador con su propio prompt. Prepara una lista de funcionalidades (feature_list.json), un registro de progreso (claude-progress.txt), un init.sh que arranca el servidor de desarrollo y un primer commit de git.
• Cada sesión posterior lee el registro de progreso y el git log para orientarse, implementa una sola funcionalidad y termina con un commit y una actualización del registro.
• La lista de funcionalidades está en JSON y no en Markdown, porque el modelo tendía menos a reescribirla indebidamente. Lo único que puede cambiar es el campo de aprobado/suspenso (passes).
• Una funcionalidad solo se marca como terminada después de probarla de principio a fin con automatización del navegador, como lo haría un usuario.

3. Mitchell Hashimoto: que el mismo error no se repita

Quien le puso el nombre trabaja a menor escala. Cuando el agente comete un error sencillo, añade una línea a AGENTS.md; en su proyecto del terminal Ghostty, cada línea de ese archivo corresponde a un mal comportamiento pasado, y así los resolvió casi todos. Cuando el texto no basta, construye scripts reales (para hacer capturas de pantalla o ejecutar tests filtrados) y se los da al agente.

Lo que comparten los tres es que el peso está en mecanismos que comprueban y devuelven el trabajo, más que en pedir las cosas por escrito. La lista de verificación siguiente ayuda a decidir cuánto convertir en mecanismo.

6. Una lista práctica para diseñar un arnés

7. Comparativa de los principales arneses

Cada uno de estos arneses funciona con más o menos los mismos LLMs (Claude / GPT / Gemini), y sin embargo sus fortalezas divergen marcadamente debido a filosofías de diseño de arnés diferentes. "¿Qué arnés?" importa más que "¿qué LLM?": ese es el verdadero campo de batalla de la era de los agentes.

8. Antipatrones

1. Añadir demasiadas herramientas

Cuantas más herramientas añades, más fácil es que el LLM elija la equivocada. La documentación de Anthropic indica que la precisión de Claude al elegir herramientas se degrada cuando hay más de 30–50 disponibles, y ofrece la búsqueda de herramientas para cargar solo las relevantes cuando hacen falta. Su guía para escribir herramientas también advierte que más herramientas no significan mejores resultados: en lugar de envolver cada endpoint de la API, agrupa las funciones parecidas.

2. Meterlo todo en el contexto

"Mejor enséñaselo todo, por si acaso" es contraproducente. Pásalo por un filtro de relevancia e incluye solo lo necesario. El contexto es un dispositivo para resaltar la señal importante, no un trastero.

3. Implementar la seguridad solo con prompts

"Por favor, no realices operaciones peligrosas" se ignora tarde o temprano, según la situación. La respuesta correcta es hacerlo físicamente imposible a nivel de entorno: sandbox, Hooks, límites de permisos.

4. No revisar nunca lo que añadiste

Cada pieza que añades hace el arnés más pesado, lento y caro. Tras el experimento anterior, Anthropic quitó los componentes uno a uno y comparó los resultados, y conservó solo lo que seguía aportando (el planificador y el evaluador). Su idea: cada componente de un arnés codifica una suposición sobre lo que el modelo no puede hacer solo, y esas suposiciones caducan rápido a medida que los modelos mejoran. Cuando cambies de modelo, comprueba uno por uno si cada verificación y cada división que añadiste siguen sirviendo.

Resumen

La ingeniería de arnés es el oficio de diseñar la capa "exterior" al LLM. La ingeniería de prompts es solo un componente dentro del arnés. Tratar los seis elementos con intención — definición de herramientas, gestión de contexto, memoria, bucle, guardarraíles, UX de salida — puede transformar el rendimiento real partiendo del mismo LLM subyacente.

A fecha de 2026, el principal campo de batalla para los agentes de IA en producción se ha trasladado claramente al arnés. Construir "arneses inteligentes" — y no solo escribir "prompts inteligentes" — será el factor diferencial para la próxima generación de ingenieros.

FAQ

P1. ¿Entonces ya no necesitamos la ingeniería de prompts?

Falso. Sigue siendo esencial, como un componente dentro del arnés. Las descripciones de herramientas, los system prompts, los mensajes de error: todas esas son superficies de diseño de prompts. Lo que está obsoleto es la mentalidad de "esto lo arreglo con un mejor prompt".

P2. ¿Cuál es el primer paso para aprender ingeniería de arnés?

Coge Claude Code o Cursor y no te limites a usarlo: cambia su comportamiento ajustando su configuración. Convertido en pasos, el método de Hashimoto queda así:

1. Anota cada fallo del agente (con qué instrucción y qué salió mal).
2. Para los fallos sencillos, añade una línea a CLAUDE.md / AGENTS.md / .cursor/rules.
3. Los fallos que se repiten, o los que harían daño, detenlos de forma mecánica con Hooks, linters o tests, y escribe la solución en el mensaje de error.
4. Pide al agente la misma tarea otra vez y confirma que el fallo ha desaparecido.

P3. ¿Los arneses son lo mismo que frameworks como LangChain?

Cercano, pero no es lo mismo. Un framework es un kit de implementación; un arnés es una disciplina de diseño y una mentalidad. LangChain, LlamaIndex, el Claude Agent SDK y similares son herramientas para construir arneses.

P4. ¿Construir mi propio arnés o usar uno existente?

Para la mayoría de casos, un arnés existente (Claude Code, Cursor, etc.) más personalización es suficiente. Construir uno desde cero solo tiene sentido para requisitos empresariales, dominios de nicho u optimización extrema de costes.

P5. ¿"Ingeniero de arnés" se convertirá en un puesto de trabajo real?

Todavía no hay un nombre de puesto asentado. El propio Hashimoto escribió que no sabía si existía un término aceptado en la industria. Pero el equipo de Codex de OpenAI cuenta que el trabajo principal del ingeniero ha pasado a diseñar entornos, especificar la intención y construir bucles de retroalimentación: el contenido del trabajo está cambiando antes que el nombre del puesto.