¿Qué es harness engineering?

¿Qué es?

Un harness es todo lo que rodea a un modelo de lenguaje para convertirlo en un colaborador confiable dentro de un proceso real: las reglas que siempre tiene presentes, los procedimientos reutilizables que puede activar, la memoria que persiste entre sesiones, y las decisiones sobre cuándo delegar una tarea a otro agente. Harness engineering es la disciplina de diseñar y ajustar ese entorno.

La distinción importa porque un modelo más capaz no resuelve por sí solo la falta de consistencia: dos sesiones distintas con el mismo modelo pueden comportarse distinto si no comparten las mismas reglas, la misma memoria o los mismos procedimientos. El harness es lo que hace que el comportamiento del agente sea reproducible en vez de depender del humor de cada conversación.

Modelo mental

Piensa en el modelo como un empleado nuevo muy talentoso, y el harness como el manual de la empresa, los procesos documentados y el acceso a los sistemas internos. Un empleado brillante sin ningún manual va a improvisar cada vez que le falte contexto; el mismo empleado con procesos claros produce resultados consistentes, aunque cambie de turno o de proyecto.

¿Cómo se usa?

Un harness típico combina varias piezas, cada una resolviendo un problema distinto:

• Reglas (por ejemplo, un archivo CLAUDE.md): contexto que se carga completo en cada sesión, sin que el agente decida si lo necesita.
• Skills: procedimientos que el agente activa bajo demanda, cuando la tarea calza con su descripción — no se cargan por completo hasta que se gatillan.
• Memoria persistente: decisiones, patrones y descubrimientos que sobreviven entre sesiones y compactaciones de contexto, en vez de perderse cuando la conversación termina.
• Orquestación: reglas explícitas sobre cuándo el agente debe delegar una tarea a un sub-agente en vez de resolverla él mismo, para no saturar su propio contexto.

Un ejemplo mínimo de la primera pieza (reglas) en la práctica:

# CLAUDE.md
 
## Comandos
- `npm test` — corre la suite de tests
 
## Convenciones
- Componentes en PascalCase, hooks en camelCase con prefijo `use`
 
## Arquitectura
- La lógica de negocio vive en `src/domain/`, nunca en componentes de UI

Este archivo se carga completo en cada sesión — es la pieza más simple del harness, y casi siempre la que conviene armar primero.

Ninguna pieza sola resuelve el problema completo — un harness bien diseñado combina las que su proceso realmente necesita, sin agregar las que no.

¿Cuándo usarlo / cuándo no?

Conviene invertir en un harness cuando:

• El mismo agente va a repetir un tipo de tarea muchas veces (por ejemplo, generar documentos técnicos o revisar código).
• Varias personas o sesiones necesitan que el agente se comporte de forma predecible.
• El proyecto es lo bastante largo como para que la memoria entre sesiones importe.

Es exceso cuando:

• Es una tarea única, sin repetición esperada.
• El proyecto es tan chico que documentar reglas cuesta más que simplemente explicarlas cada vez.
• Todavía estás explorando qué proceso seguir — un harness rígido demasiado pronto trabaja en contra tuyo.