Harness vs context engineering: en qué se diferencia el harness engineering del prompt y del context engineering

En resumen: tres niveles de una misma tarea

El prompt engineering responde a la pregunta «cómo pedir», el context engineering a «qué debe saber el modelo ahora mismo», y el harness engineering a «en qué entorno trabaja el agente y cómo se entera de que se ha equivocado». No son tres enfoques que compitan, sino niveles anidados: un buen prompt forma parte de un buen contexto, y un contexto bien pensado es uno de los subsistemas del harness.

La confusión surge porque los tres cambian el comportamiento del modelo, pero con palancas distintas. Si el agente no puede ejecutar las pruebas, ninguna redacción del prompt lo arreglará. Si el agente olvida las decisiones de ayer, el problema no está en las palabras de la petición, sino en dónde se guarda el estado. Entender la diferencia entre harness y context engineering ahorra semanas: deja de reescribir instrucciones donde lo que está roto es el entorno.

Prompt engineering: la redacción de una petición

El prompt engineering consiste en trabajar el texto de la petición: rol, tarea, formato de respuesta, ejemplos (few-shot), restricciones, orden de los pasos. La unidad de trabajo es una llamada al modelo. El resultado se juzga por la respuesta: ¿es correcta, tiene el formato adecuado, se mantuvo el modelo en el tema?

Técnicas típicas:

• describir explícitamente el formato de salida (esquema JSON, tabla, lista);
• dar 2 o 3 ejemplos de «entrada → salida correcta»;
• pedir un razonamiento paso a paso antes de la respuesta;
• separar instrucciones y datos con delimitadores claros;
• enumerar lo que no debe hacerse.

El prompt engineering funciona bien en tareas de «una entrada — una salida»: clasificación, extracción de datos, traducción, generación de texto según una plantilla. Su techo aparece cuando el modelo empieza a actuar: llamar a herramientas, modificar archivos, encadenar decenas de pasos. Ahí la calidad ya no depende de una frase, sino de todo lo que rodea al modelo.

Context engineering: qué entra en la ventana del modelo

El context engineering consiste en gestionar el contenido de la ventana de contexto en cada paso. La ventana es limitada, y el agente acumula, en una sesión larga, salidas de comandos, contenido de archivos e historial de la conversación. El objetivo es tener en cada momento lo necesario y nada superfluo.

Incluye:

• selección: qué archivos, documentos y fragmentos de código cargar para la tarea (búsqueda, RAG, lectura bajo demanda);
• compresión: resumir un historial largo, recortar las salidas de los comandos, compactar la sesión;
• estructura: un archivo de instrucciones de entrada que funciona como índice, con los detalles en documentos aparte que el agente abre cuando los necesita;
• aislamiento: delegar una subtarea en un subagente con su propio contexto limpio, para que la sesión principal no se sature.

La métrica del context engineering es si el agente encontró la regla o el dato correcto en el momento oportuno, y si no se ahogó en el ruido. Un síntoma típico: la regla está escrita en CLAUDE.md, pero el agente la incumple, porque el archivo tiene cinco páginas y la regla se perdió entre el tono de voz y las manías del responsable del equipo.

Harness engineering: todo lo que rodea al modelo

El harness («el arnés») es el entorno en el que trabaja el agente. El modelo es solo un componente dentro de él, que entra en el circuito una vez. Todo lo demás —instrucciones, herramientas, entorno, estado y retroalimentación— lo diseña un ingeniero. El harness engineering se ocupa de que el agente no solo pueda escribir código, sino también ejecutarlo, comprobarlo, enterarse de un error y continuar en la sesión siguiente desde el mismo punto.

Conviene desglosar el harness en cinco subsistemas:

En este esquema, el context engineering vive dentro de los dos primeros subsistemas: decide cómo las instrucciones y las salidas de las herramientas llegan a la ventana. El harness añade lo que no se puede meter en el contexto: una comprobación que funciona, un entorno reproducible, un archivo de estado que sobrevive a un reinicio.

Tabla comparativa

Por qué un prompt y un contexto no bastan

Historia clásica: el equipo ve que el agente se equivoca y dedica una semana a escribir un AGENTS.md de cinco páginas. El agente sigue sin ejecutar el linter antes del commit. La causa no está en el texto: al agente simplemente no le llega un shell con los permisos adecuados, y el linter no está instalado en la imagen. Es un problema de herramientas y de entorno, y se estaba tratando con instrucciones.

Segunda historia: el agente corrige por tercera sesión seguida el mismo error, porque tras cada reinicio no recuerda lo que ya probó. El context engineering dentro de una sesión no ayuda aquí: la ventana se vacía. Hace falta el subsistema de estado: un archivo donde el agente registre intentos y decisiones, y una regla que le obligue a leerlo al empezar.

La tercera historia es la más costosa: el agente escribe «listo», las pruebas unitarias están en verde, pero la funcionalidad no funciona. Ni un prompt del tipo «comprueba con cuidado» ni más documentos en el contexto le darán al agente una verificación independiente. Solo la da la retroalimentación de una máquina: una prueba de extremo a extremo, un script de verificación, un evaluador aparte sin acceso al razonamiento del ejecutor.

Conclusión general: el prompt y el contexto influyen en lo que el modelo piensa. El harness influye en lo que el modelo puede hacer y en lo que averigua después de actuar.

Por qué cambiar de modelo no ayuda

Una reacción habitual ante un agente inestable es elegir un modelo más potente. Normalmente no cura nada: el mismo modelo funciona como un senior seguro de sí mismo en un repositorio bien organizado, pero se pierde en uno sin comandos de comprobación ni descripción de la pila tecnológica. Un modelo más potente no adivinará las convenciones de su equipo, no obtendrá acceso a una base de datos a la que no se le dio permiso y no se enterará de que una migración está rota si nadie la ejecutó.

El harness, por su parte, no queda obsoleto al salir modelos nuevos. Las instrucciones, un entorno reproducible y las comprobaciones son necesarios para cualquier modelo. Lo que cambia es cuánto micromanagement manual se puede eliminar: a un modelo fuerte le bastan los invariantes («los datos se validan en el límite del dominio»), no las instrucciones paso a paso.

Cómo saber qué nivel corregir

El diagnóstico por síntomas es más rápido que cualquier experimento:

Por dónde empezar con el harness

Si se construye desde cero, el orden práctico es: retroalimentación → instrucciones → estado → entorno → herramientas. La retroalimentación va primero porque, sin ella, no se puede medir el efecto de los demás cambios. Mientras no haya un comando que responda honestamente «funciona o no», cualquier mejora de las instrucciones se juzga a ojo.

Un arranque mínimo se ve así:

# AGENTS.md (fragmento)
## Cómo comprobar
- make check   # lint, tipos, pruebas unitarias
- make e2e     # escenarios de extremo a extremo
Una funcionalidad está lista solo si ambos comandos terminan con código 0.

## Reglas
- MUST: todas las consultas SQL están parametrizadas
- MUST: ejecutar make check antes de cada commit
- Detalles de pagos: docs/payments.md (leer si la tarea afecta a pagos)

Fíjese en la última línea: eso es context engineering dentro del harness. El archivo de entrada es un mapa, no un manual; los detalles se cargan bajo la condición «cuando».

Cómo medir la contribución de cada parte

El harness tiene una métrica que no tiene un prompt: la proporción de tareas que el agente declaró listas y que una verificación independiente no confirmó. Se llama brecha de verificación (verification gap). Tome 10 tareas seguidas y anote en cada una si el agente dijo «listo» y si la comprobación pasó: obtendrá una cifra con la que comparar los cambios.

Para ver qué subsistema tiene efecto se usa la ablación: se fijan el modelo y el conjunto de tareas, se desactiva por turnos una parte del harness y se observa la caída. Hay dos cosas que tener en cuenta. Es mejor no empezar por la ablación, sino por un registro de fallos: etiquetar en qué capa se rompieron las cosas muestra el cuello de botella más rápido. Y una caída nula no demuestra que un componente sea inútil: puede que las tareas elegidas no lo hayan necesitado.

Errores frecuentes

• Tomar un archivo de prompt por el harness. Las instrucciones son uno de cinco subsistemas. Un estante de recetas todavía no es una cocina.
• Corregir la falta de herramientas con texto. «Ejecuta siempre las pruebas» no sirve de nada si las pruebas no se pueden ejecutar en el entorno del agente.
• Inflar las instrucciones. Cuanto más largo es el archivo de entrada, más probable es que una regla importante no se lea. Es mejor convertir las reglas importantes en comprobaciones ejecutables.
• Confiar en la autoevaluación del agente. Un modelo que evalúa su propio trabajo tiende a sobrestimarlo. La verificación debe hacerla un script o un agente aparte con contexto limpio.
• Configurar el harness una sola vez. Envejece como el código: las reglas se separan de la realidad y los comandos cambian. Debe revisarse con regularidad.

Resumen

El prompt engineering mejora la redacción, el context engineering selecciona lo que entra en la ventana del modelo, y el harness engineering diseña todo el entorno del agente, incluidas las herramientas, el entorno, el estado y las comprobaciones. Cuando un agente trabaja mucho tiempo y modifica el código por sí mismo, el harness se convierte en lo principal: transforma «el agente dijo listo» en «el sistema comprobó que funciona». Así que la elección en el debate harness vs context engineering no es excluyente: el contexto forma parte del harness, y hay que corregir el subsistema al que apuntan los síntomas. Este tema se trabaja en la práctica en el curso de harness engineering, sobre un proyecto de backend de pagos.