Harness Engineering

Un martes a las 3 a. m.

Las 3 a. m. de un martes. Al ingeniero on-call de un equipo lo despierta sobresaltado una alerta de PagerDuty.

Los costos de API se dispararon. Revisa el panel: más de $400 gastados en la última hora. Al investigar, encuentra que un agente de IA implementado el día anterior estuvo machacando una API inestable con reintentos. Cada error lo manda de vuelta al ciclo de “déjame intentar otra vez”, y siguió así hasta la mañana.

El agente no era el problema. El modelo estaba bien. El prompt estaba escrito con cuidado. Lo que faltaba era un harness. Le dijeron al agente “ejecuta”, pero nunca le dieron frenos ni volante.

Esta historia no es rara. Hay una frase que circula en el sector:

“The model is commodity. The harness is moat.”

Cuando un agente que funcionaba perfecto en una demo se rompe en producción, casi siempre es un problema de harness.

En febrero de 2026, OpenAI publicó una publicación en su blog: “Harness engineering: leveraging Codex in an agent-first world”.

Esto fue lo que decía: durante cinco meses, un equipo de ingeniería no escribió una sola línea de código a mano. Construyeron una aplicación en producción de más de un millón de líneas usando solo agentes Codex. Tiempo de construcción: una décima parte de hacerlo a mano.

“Humans steer. Agents execute.”

Los ingenieros no perdieron su trabajo. La definición del trabajo cambió.

Esa publicación encendió la mecha. Después vino el reporte de la “tormenta de reintentos de $47.000” de un fin de semana de febrero de 2026. Un agente de enriquecimiento de datos malinterpretó un código de error de API como “reintenta con parámetros diferentes” e hizo 2,3 millones de llamadas a la API. El lunes por la mañana, los ingenieros volvieron a una factura de $47.000. Está bien que el agente haya trabajado el fin de semana, pero no tanto cuando el entregable es cero y la factura llega igual. Unos días después, Anthropic publicó dos guías de diseño de harness. LangChain definió “Agent = Model + Harness”. Martin Fowler escribió un comentario. Un artículo académico apareció en arXiv.

2024 fue el año de la Ingeniería de Prompt. La era de pulir “qué preguntarle a la IA”.

2025 fue el año de la Ingeniería de Contexto. Andrej Karpathy dijo “The hottest new programming language is English”, y el trabajo se movió a diseñar “qué mostrarle a la IA”.

En 2026, el alcance se amplía a Harness Engineering. “¿Cómo diseñas todo el entorno en el que opera el agente?”

Pero el término se interpreta un poco distinto según quién lo escriba. OpenAI y Anthropic enfatizan cosas distintas. LangChain y Martin Fowler lo abordan desde ángulos distintos. Los artículos académicos vienen desde otra dirección.

Este libro da una visión estructurada de Harness Engineering.

• La relación entre las tres prácticas de ingeniería (Prompt / Contexto / Harness)
• Cómo los actores principales (OpenAI / Anthropic / LangChain / Martin Fowler / académicos) lo interpretan distinto
• La anatomía de los seis componentes
• Cómo se sitúa junto a ideas relacionadas (Vibe Coding / Spec Coding / Agent Frameworks)
• Estudios de caso prácticos de la comunidad de habla japonesa
• Hacia dónde va todo esto

Es a la vez un libro de organización conceptual y una guía práctica que puedes usar mañana. Mi objetivo es simple: cuando alguien pregunte “ok, pero ¿qué es un harness?”, puedas darle este libro como una respuesta clara.

Para quién es este libro

• Ingenieros que empezaron a usar agentes de IA (Claude Code, GitHub Copilot, Cursor, etc.)
• Personas que escribieron un AGENTS.md o CLAUDE.md y no están seguras de haberlo hecho bien
• Personas que conocen la Ingeniería de Prompt y escuchan “Harness Engineering” por primera vez
• Líderes técnicos y gerentes que quieren llevar agentes de IA a su equipo

El único prerrequisito es lo básico de Ingeniería de Prompt. Haber oído hablar de Few-shot y Chain-of-Thought es suficiente.

Cómo leer este libro

Puedes leerlo de tapa a tapa, o saltar a los capítulos que te interesen. Aun así, hay tres capítulos que vale la pena leer pase lo que pase:

• Capítulo 1: entender cómo se relacionan las tres prácticas de ingeniería (el mapa del territorio)
• Capítulo 8: aprender los seis componentes (el esqueleto de la práctica)
• Capítulo 11: aprender a escribir AGENTS.md (algo que puedes usar mañana)

Por qué falla el 40 %

En 2026, el 40 % de los proyectos de agentes de IA fracasa (encuesta Company of Agents).

¿Qué hay detrás de los fracasos? ¿Modelo equivocado? ¿Prompts malos?

Ninguno. “La diferencia entre el éxito y el fracaso no es el modelo.” Ese es el consenso del campo.

Una encuesta en Y Combinator DevTool Day (marzo de 2026) entrevistó a CTOs y CPOs y encontró un factor común en los proyectos fallidos: falta de harness. Nunca diseñaron el entorno en el que opera el agente.

El 75 % de las empresas corporativas de YC ya tiene agentes de programación implementados. Sin embargo, muchas chocan contra la misma pared: “funciona en la demo, colapsa en producción”.

En marzo de 2026, Linear declaró que “el seguimiento de incidencias está muerto”. El razonamiento: alimenta el contexto del issue directamente a un agente de programación y los humanos ya no necesitan gestionar tickets. Los flujos de trabajo corporativos se están rediseñando con agentes como supuesto por defecto.

Llevar agentes a producción en este punto de inflexión sin entender el harness es como manejar en la autopista sin cinturón de seguridad. Puedes ir rápido, pero saldrás disparado en la primera curva.

Línea de tiempo

Qué distingue a las tres

Ingeniería de Prompt

Sujeto: un prompt único (texto de entrada)

Optimizar “qué preguntarle a la IA y cómo”. Few-shot, Chain-of-Thought, ReAct. El arte de maximizar la precisión en un solo intercambio.

Ingeniería de Contexto

Sujeto: todo lo que le proporcionas a la IA (system prompt + RAG + definiciones de herramientas + memoria)

En palabras de Andrej Karpathy, “it is a lot more than just the prompt itself”. A medida que los enfoques de un solo prompt se volvieron insuficientes en más casos, los equipos tuvieron que diseñar toda la ventana de contexto construida dinámicamente.

Philip Schmidt (anteriormente en Hugging Face, Google DeepMind) sostiene que “la nueva habilidad para usar IA no es prompting. Es ingeniería de contexto”.

Harness Engineering

Sujeto: todo el entorno operativo (contexto + restricciones + herramientas + ciclo de vida + retroalimentación + monitoreo)

La definición de Louis Bouchard es la más concisa:

La Ingeniería de Contexto es “lo que envías al modelo”. Harness Engineering es “cómo funciona todo el sistema”.

No el prompt, no el contexto. El entorno alrededor del modelo. Si la analogía es la cocina, el prompt es la receta, el contexto son los ingredientes y el harness es la cocina misma.

Una estructura anidada

Estos tres no son conceptos en competencia. Se anidan uno dentro del otro.

El artículo de SmartScope lo expresa con claridad:

Harness ⊇ Context ⊇ Prompt

El artículo en japonés de Elephancube usa una metáfora acertada:

Cuando construyes una casa, las paredes necesitan cimientos y el techo necesita paredes. Los buenos prompts hacen que el diseño de contexto funcione, y un buen diseño de contexto permite que el harness funcione.

¿“Sustituido” o “estratificado”?

Aquí es donde divergen las interpretaciones.

El campo de la “sustitución”:

Data Science Dojo tituló un artículo “Why Harness Engineering Is Replacing Prompt Engineering”. Su argumento: los agentes de 2025-2026 operan en entornos para los que los prompts y el contexto nunca fueron diseñados.

El campo de la “estratificación”:

AnyTech (Medium) escribe: “No hay diferencia esencial entre los tres; la terminología está cambiando porque los LLM y los agentes abarcan ahora un alcance más amplio de trabajo”. Un planteo tranquilizador. No tienes que descartar todo lo que sabías cada vez que aparece una nueva palabra de moda.

La postura de este libro: el campo de la estratificación. La Ingeniería de Prompt sigue siendo importante. Solo que ya no alcanza por sí sola en un número creciente de casos. Harness Engineering engloba el prompt y el contexto, y luego agrega una capa externa de restricciones, gestión del ciclo de vida y ciclos de retroalimentación.

¿Por qué ahora?

Una pieza de WonderLab en DEV.to lo dice bien:

El momento no es casualidad. En 2025, los agentes de IA pasaron de “demos divertidas” a “herramientas reales de productividad”.

Una vez que los agentes se ejecutan de forma autónoma durante tramos largos, optimizar un solo prompt no puede mantenerlos bajo control. El diseño de contexto por sí solo también es insuficiente. Hay que diseñar todo el entorno.

Esa urgencia es lo que dio origen a Harness Engineering.

Lo que realmente significa “funciona en la demo, se rompe en producción”

harnessengineering.academy lo plantea así:

No despliegues agentes de IA sin un harness, igual que no ejecutarías software directamente sobre una CPU sin un sistema operativo.

Una CPU puede computar. Pero sin un sistema operativo, no puedes gestionar memoria, planificar procesos ni controlar I/O. Lo mismo con los modelos: un modelo puede generar texto. Pero sin un harness, no puedes gestionar contexto, controlar herramientas ni manejar fallas.

Nueve de cada diez agentes que “funcionan en la demo y se rompen en producción” son problema de harness. Para ser específicos:

• Demo: un entorno controlado. Las preguntas llegan en el flujo esperado. Las APIs funcionan. El contexto es corto.
• Producción: caos. Entradas inesperadas. APIs caídas. El contexto se infla. Condiciones de carrera por ejecución paralela.

Un harness es el amortiguador que absorbe el caos de producción. La demo es la sala de exhibición; la producción, la carretera abierta. Si un auto que corre perfecto en la sala de exhibición sobrevive en la carretera es otra pregunta.

De dónde viene la palabra “harness”

NxCode explica la etimología:

El término viene del equipamiento ecuestre. Un caballo es poderoso y rápido, pero sin riendas, silla de montar y freno, va a donde quiere. El modelo de IA es el caballo. El harness es todo lo que canaliza esa fuerza hacia trabajo productivo.

Una publicación de kazu_t en Note usa una analogía entre SO y código de aplicación:

Si el prompt es código de aplicación, el harness es el sistema operativo.

Aakash Gupta (Medium) lo dice aún más simple:

El modelo es el motor. El harness es el auto. El mejor motor del mundo no va a ningún lado sin volante y frenos.

Distinguirlo del “test harness”

Parallel.ai hace una advertencia importante:

No lo confundas con un test harness (un término viejo de la ingeniería de software). Un test harness es un marco que recibe entradas y verifica salidas automáticamente. Un agent harness es todo el entorno operativo de una IA.

Si buscas el término te aparecerán resultados sobre cableado eléctrico y la plataforma de CI/CD Harness.io. El harness de este libro se refiere al entorno de control para agentes de IA.

Comparando las definiciones

Aquí van las definiciones lado a lado.

OpenAI

“Humans steer. Agents execute. By deliberately imposing this constraint, we built what was needed to lift engineering speed by orders of magnitude.”

Harness = el entorno en el que los agentes escriben código de forma confiable.

Anthropic

“Multi-context-window support, environment setup in the initial context, context management, sub-agent composition.”

Harness = un sistema de control estable para agentes de larga duración.

LangChain

“Agent = Model + Harness. El modelo tiene la inteligencia; el harness hace útil esa inteligencia.”

Harness = la envoltura externa que convierte la inteligencia del modelo en trabajo útil.

Martin Fowler

“Los lenguajes fuertemente tipados convierten las verificaciones de tipo en sensores. Los límites entre módulos imponen restricciones de arquitectura. Marcos como Spring abstraen detalles en los que el agente no necesita pensar, elevando implícitamente la tasa de éxito del agente.”

Harness = el conjunto total de restricciones implícitas y explícitas integradas en la base de código.

Louis Bouchard

“Deja de decir ‘el modelo es tonto’. Di en cambio: ‘mi sistema toleró este modo de falla’.”

Harness = diseño de entorno que no tolera modos de falla.

En qué están todos de acuerdo

Las palabras difieren, pero todos coinciden en algunos puntos.

1. El harness está fuera del modelo: no se trata de ajustar parámetros del modelo
2. Las restricciones se aplican, no se piden: el sistema no avanza si no se cumplen
3. Los ciclos de retroalimentación son obligatorios: evaluar salidas, seguir mejorando el entorno
4. El rol del humano cambia: de escribir código a diseñar el entorno

La definición operativa que usa este libro

Combinando las definiciones de arriba, este libro usa:

Harness Engineering es la disciplina de diseñar todo el entorno en el que los agentes de IA operan de forma autónoma durante largos períodos. Incluye gestión de contexto, aplicación de restricciones, gestión del ciclo de vida, ciclos de retroalimentación, monitoreo y fronteras de seguridad.

Qué sale mal sin un harness

El valor de un harness se vuelve claro cuando miras qué falla sin él.

Un harness convierte “peticiones” en “mecanismos”. Decir “por favor escribe pruebas” 100 veces es menos confiable que construir el sistema una vez para que los commits sin pruebas no puedan ocurrir. Igual que entrenar miembros junior del equipo.

La diferencia decisiva con la Ingeniería de Prompt

La Ingeniería de Prompt optimiza “un intercambio”. Harness Engineering optimiza “100 intercambios”.

Para un solo intercambio, un buen prompt alcanza. Pero cuando un agente programa todo el día, el efecto del primer prompt se desvaneció para el intercambio número 50. El contexto se infla, las instrucciones originales se hunden en el pasado lejano, y el agente empieza a comportarse distinto a como lo hacía al inicio.

Un harness resuelve eso. Si un prompt es “el primer empujón”, un harness es “la gravedad que jala todo el tiempo”.

Desde el próximo capítulo, examinamos las interpretaciones de cada actor una por una.