Sesión 07 · 15 de julio de 2026 · Sergio Monsalve

Harness Engineering

Todo agente de IA funciona hasta que no. Bajo condiciones controladas escriben código, navegan y operan software de forma autónoma. En producción fallan de forma impredecible: no hay memoria entre sesiones, no se sabe cuándo se detienen ni cómo validan su propio trabajo.

El harness engineering es la disciplina de diseñar los sistemas, restricciones y ciclos de retroalimentación que envuelven a un agente para hacerlo confiable en producción. El harness no es el agente: es la infraestructura que gobierna cómo opera, qué herramientas puede invocar, dónde obtiene información, cómo valida decisiones y cómo se detiene.

La metáfora: el modelo es el caballo, el arnés son las riendas y la silla, y el jinete da la dirección. Un buen arnés no previene los errores — hace al agente más capaz dándole contexto, herramientas y las restricciones correctas en el momento correcto. Cada error se convierte en una regla nueva del arnés.

Origen: en febrero de 2026 Mitchell Hashimoto —cocreador de Terraform, fundador de HashiCorp— publica sobre engineering the harness. Semanas después Anthropic y OpenAI publican artículos propios. Martin Fowler lo define como las herramientas y prácticas para mantener a los agentes bajo control.

Convergencia clave: la guía empírica de desarrollo de Jorge Johnson y el marco formal de harness engineering llegan a lo mismo por caminos distintos. Jorge desde el proceso, el harness desde la infraestructura. Specs como fuente de verdad ↔ context delivery. Puerta de plan antes de tocar código ↔ approval gates. Criterios de aceptación binarios ↔ ciclos de verificación. Reglas del proyecto en documentos ↔ configuración del harness.

La tesis más profunda: la fuerza de voluntad no basta. La voluntad no frena el sesgo de automatización; lo que funciona es la fricción productiva, puertas de diseño que obligan a un acto deliberado.

Los mejores arneses se diseñan sabiendo que serán innecesarios a medida que los modelos mejoren.

Conceptos

Prompt engineering

Un turno.

Context engineering

Una sesión.

Harness engineering

Trabajo continuo: horas y cientos de decisiones, con herramientas, validación y restricciones arquitectónicas.

Patrón de Hashimoto

Cada error del agente se convierte en un arreglo permanente del entorno. El sistema se realimenta y mejora a sí mismo.

Cinco primitivas

Sistema de archivos, ejecución de código, sandbox controlado, memoria persistente y gestión de contexto.

Decisiones

  • Se adopta el glosario vivo de 40 términos clave en cuatro categorías: fundamentos, contexto y memoria, seguridad y control, operación y evaluación.
  • Se comparte un repositorio de aprendizaje con cinco módulos y dos proyectos prácticos.
  • Jorge Johnson asume formalmente el rol de moderador.