Harness Engineering (Ingeniería de Arneses)
Los modelos de IA ya pueden escribir un millón de líneas de código. El verdadero desafío ya no es hacer que escriban mejor, sinocómo hacer que trabajen de manera estable, confiable y sin perder el control. Esta metodología que construye restricciones, retroalimentación y sistemas de control alrededor de los agentes de IA es el nuevo paradigma que arrasó en el mundo de la ingeniería a principios de 2026:Harness Engineering (Ingeniería de Arneses)。
1. ¿Qué es Harness Engineering?
Harness Engineering (Ingeniería de Arneses)es diseñar y construir alrededor de los agentes de IAmecanismos de restricción, bucles de retroalimentación, control de flujo de trabajo y ciclos de mejora continuauna práctica de ingeniería de sistemas.
No optimiza el modelo en sí, sino el entorno en el que opera el modelo. La filosofía central en ocho palabras es:Humanos dirigen, agentes ejecutan (Human Steer, Agent Execute)。
El término Harness proviene del arreo de caballos: riendas, silla de montar, bocado. Es un equipo completo para guiar a animales poderosos pero impredecibles.La ingeniería de arneses no busca debilitar las capacidades de la IA, sino crearle una rienda de oro para que corra rápido y con estabilidad.
El concepto fue propuesto por primera vez por Mitchell Hashimoto, cofundador de HashiCorp, el 5 de febrero de 2026. Seis días después, OpenAI adoptó formalmente el término en su informe experimental de un millón de líneas de código. Posteriormente, Martin Fowler escribió un análisis profundo, y en un mes se convirtió en una palabra de moda en la comunidad de desarrolladores.
harness engineering is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent will not make that mistake again in the future.
—— Mitchell Hashimoto
El subtexto de esta frase es:Cada fallo de un agente es una señal de que el diseño del entorno es deficiente.La respuesta correcta no es cambiar a un modelo más potente, sino rediseñar el entorno en el que opera.
2. ¿Por qué se necesita la ingeniería de arneses? Los datos reales hablan
El caso de LangChain es particularmente convincente: no se tocó ni un solo parámetro del modelo subyacente,solo optimizando el entorno de arneses externo(estructura de documentación, bucles de validación, sistema de seguimiento), la puntuación del agente de codificación en Terminal Bench 2.0 se disparó de 52.8% a 66.5%, y su ranking global saltó del puesto 30 al 5.
Cinco equipos independientes llegaron a la misma conclusión:El cuello de botella no está en la inteligencia del modelo, sino en la infraestructura.
3. Tres saltos del paradigma de la ingeniería de IA
Para entender por qué la ingeniería de arneses es importante, primero hay que ver claramente cómo hemos llegado hasta aquí paso a paso.
| Paradigma | Problema central | Objeto de optimización | Modo de interacción |
|---|---|---|---|
| Ingeniería de prompts | Cómo expresarse con claridad | Redacción, formato y ejemplos del prompt | Pregunta y respuesta |
| Ingeniería de contexto | Cómo alimentar de información a la IA | Documentos, fragmentos de código, historial de conversaciones | Inyección de información → Generación |
| Ingeniería de arneses | Cómo lograr que los agentes trabajen de manera confiable | Restricciones, bucles de retroalimentación, sistemas de control | Humanos dirigen, agentes ejecutan |
Una analogía fácil de recordar:
- Prompt Engineering —— La técnica de gritarle al caballo
- Context Engineering —— El mapa que se le muestra al caballo
- Harness Engineering —— Construir una autopista para el caballo, con barreras de protección, señales de límite de velocidad y estaciones de servicio
4. Modos de fallo comunes de los agentes
Los ingenieros de Anthropic, tras ejecutar agentes durante largos períodos, resumieron tres formas típicas de fracaso, que son exactamente los puntos clave que la ingeniería de arneses debe resolver:
Modo de fallo 1: Intentar hacer todo de una vez (One-shotting)
El agente tiende a completar todas las funciones en una sola sesión. El resultado es que el contexto se agota, dejando un montón de código a medias sin documentar, y cuando se inicia la siguiente sesión hay que dedicar mucho tiempo a adivinar qué ocurrió antes.
Modo de fallo 2: Declarar la victoria prematuramente
En las etapas finales del proyecto, cuando algunas funciones ya están completas, el agente mira a su alrededor, ve avances y declara la tarea terminada, incluso aunque queden muchas funciones sin implementar.
Modo de fallo 3: Marcar funciones como completadas prematuramente
Sin instrucciones claras, el agente marca el código como completado después de escribirlo, sin realizar pruebas de extremo a extremo. Que las pruebas unitarias o los comandos curl pasen no significa que la función realmente funcione.
Además, los agentes tienen una característica peligrosa:son muy buenos replicando patrones. Cualquier patrón que exista en el repositorio de código lo replican y amplifican fielmente, incluidos los malos patrones y la deriva arquitectónica. Esto significa que un agente sin restricciones acumula deuda técnica a una velocidad alarmante.
5. Los cuatro pilares de la ingeniería de arneses
Combinando las prácticas de OpenAI, Anthropic, LangChain y Martin Fowler, Harness se puede resumir en cuatro componentes centrales, es decir, cuatro "pilares":
Pilar 1: Ingeniería de contexto (Context Engineering) — Manual para nuevos empleados
Es como darle a un nuevo empleado un manual de trabajo detallado,AGENTS.mdes la primera guía que ve un agente de IA al entrar en un repositorio de código. Pero no es un manual estático de 1000 páginas: el contexto es un recurso escaso, y demasiada guía desplaza el espacio para tareas, código y documentación relevante, convirtiéndose en un cementerio de reglas obsoletas.
La mejor práctica es ofrecer un punto de entrada estable y pequeño, y luego enseñar al agente a recuperar y extraer más contexto según la tarea actual. En el proyecto Ghostty de Mitchell Hashimoto, cada línea de AGENTS.md corresponde a un caso histórico de fallo del agente: el documento es un bucle de retroalimentación vivo, no un artefacto estático.
Pilar 2: Restricciones de arquitectura (Architecture Constraints) — La rienda
El equipo de OpenAI estableció un estricto modelo de dependencias jerárquicas:
Types → Config → Repo → Service → Runtime → UI
Las capas inferiores no pueden depender inversamente de las superiores. Todas las reglas de arquitectura se codifican comoreglas de Linter personalizadas, y cualquier violación bloquea la fusión en CI, sin importar si el código lo escribió una persona o la IA.
Hay un detalle clave: el mensaje de error del Linter también es ingeniería de contexto. No solo dice que violaste la regla X, sino que explica por qué existe esa regla y cuál es la forma correcta de hacerlo, para que el agente pueda entender y corregir el error por sí mismo, sin intervención humana.
Pilar 3: Bucle de retroalimentación (Feedback Loop) — Agentes que revisan agentes
En el desarrollo tradicional, los ingenieros humanos son responsables de la revisión de código (Code Review). En la ingeniería de Harness, este trabajo se convierte en un enfoque agente-a-agente: Codex revisa localmente sus propios cambios, solicita revisiones adicionales y repite el ciclo hasta que pasa.
Los hooks del bucle de retroalimentación pueden ejecutar suites de pruebas predefinidas y, en caso de fallo, volver al modelo con el mensaje de error, o pedir al modelo que evalúe su código de forma independiente. Si los casos de prueba escritos por la IA pasan con un código que tiene bugs, el Harness determina que la prueba es inválida y lo obliga a replantearse los límites de la prueba.
Pilar 4: Gestión de la entropía (Entropy Management) — Recolección de basura
Con el tiempo, los sistemas de software se vuelven gradualmente caóticos (aumento de entropía) y la deuda técnica se acumula. OpenAI adopta una estrategia de pequeños pagos continuos en lugar de esperar a que el problema sea grave para abordarlo de forma centralizada — describen este método de forma gráfica comorecolección de basura, y consideran que la deuda técnica es como un préstamo con intereses altos.
Medidas concretas: ejecutar periódicamente tareas de Codex en segundo plano para escanear desviaciones, actualizar los niveles de calidad y lanzar PR de refactorización específicos. Además, existe un agente jardinero de documentaciónDoc-gardening Agent(agente jardinero de documentación) dedicado, que escanea automáticamente en segundo plano las inconsistencias entre la documentación y el código, y cuando encuentra contenido obsoleto envía automáticamente un PR para corregirlo — los Agent mantienen la documentación para los Agent.
6. Seis consensos de la industria
Integrando múltiples fuentes de información independientes como OpenAI, Anthropic, LangChain, Stripe y HashiCorp, la industria ha formado un consenso claro en los siguientes seis aspectos:
| # | Consenso | Punto de vista central |
|---|---|---|
| 1 | El cuello de botella está en la infraestructura, no en la inteligencia del modelo | Cinco equipos independientes llegaron a la misma conclusión. Con solo cambiar el formato de la herramienta Harness, la puntuación del modelo saltó del 6,7% al 68,3%. |
| 2 | La documentación debe ser un bucle de retroalimentación vivo | La documentación estática es un cementerio; solo la documentación dinámica tiene valor. Deja que los Agent en segundo plano limpien periódicamente la documentación obsoleta y envíen PR. |
| 3 | Separación de pensamiento y ejecución | Las tareas complejas no pueden completarse en una sola ventana de contexto; se necesita una arquitectura jerárquica de Orchestrator + Worker, con el estado persistido en almacenamiento externo. |
| 4 | No es que cuanta más contexto, mejor | El contexto es un recurso escaso. Los archivos de instrucciones enormes desplazan el espacio de las tareas; la recuperación debe ser bajo demanda y la inyección dinámica. |
| 5 | Las restricciones deben estar automatizadas | La revisión humana es el cuello de botella. Las barreras deben codificarse como Linters, CI y sistemas de tipos, para que las ejecuten las máquinas, no las personas. |
| 6 | El rol del ingeniero está cambiando | De escribir código a ser arquitecto del entorno. El mayor desafío de ingeniería es diseñar sistemas de control que permitan a los Agent funcionar de manera fiable. |
7. Relación entre Harness y los marcos tradicionales
Harness no es un sustituto de SDK, scaffolds o frameworks de Agent, sinouna capa que se sitúa sobre ellos：
Los frameworks tradicionales resuelvencómo construir agentes de IA, mientras que la capa de Harness resuelve un problema completamente diferente:cómo hacer que los agentes se ejecuten de forma fiable。
Los modelos están absorbiendo gradualmente alrededor del 80% de las funciones de los frameworks (definición de agentes, enrutamiento de mensajes, ciclo de vida de tareas...), pero el 20% restante —persistencia, reproducción determinista, control de costes, observabilidad, recuperación de errores— es precisamente el valor de la capa de Harness.
Resumen
Harness Engineering no es un experimento de una sola empresa, sino un cambio de paradigma por el que está pasando toda la industria.
El resumen de Birgitta Böckeler es el más incisivo:
Para lograr una mayor autonomía de la IA, el runtime debe estar sujeto a restricciones más estrictas. Aumentar la confianza no requiere más libertad, sino más limitaciones.
Como los guardarraíles en una autopista — precisamente porque hay guardarraíles, te atreves a pisar los 120 km/h.
| Componentes principales | Problema que resuelve | Prácticas representativas |
|---|---|---|
| Ingeniería de contexto Context | El Agent no sabe qué mirar ni cómo encontrarlo | Documento vivo AGENTS.md, recuperación bajo demanda |
| Restricciones de arquitectura Constraints | El Agent copia y amplifica los malos patrones | Dependencias por capas, Linters personalizados, bloqueo forzado por CI |
| Bucle de retroalimentación Feedback | El Agent no sabe que ha hecho algo mal | Revisión agente-a-agente, suites de pruebas automatizadas |
| Gestión de entropía Entropy | Deuda técnica y corrupción de la documentación | Agente jardinero de documentación, recolección continua de basura |
El futuro del desarrollo de software quizás ya no trate sobre lo rápido y bien que podemos escribir código, sino sobrelo inteligentes y robustos que sean los sistemas que diseñemos para gobernar la enorme energía de los agentes de IA。
El valor del ingeniero está pasando de ejecutor a habilitador y pensador de sistemas — de construir productos a construir fábricas que puedan construir productos.