El término "harness" designa todo lo que rodea a un modelo de IA dentro de un agente. Birgitta Böckeler propone un marco conceptual específico para los usuarios de agentes de codificación, distinguiendo el harness interno (construido por el creador del agente) del harness externo (que los usuarios construyen para su propio contexto).
El modelo se organiza en torno a dos mecanismos complementarios. Las guías (controles feedforward) anticipan el comportamiento del agente y lo orientan antes de que actúe: convenciones de codificación, especificaciones, skills, servidores MCP. Los sensores (controles de feedback) observan después de la acción y permiten que el agente se autocorrija: linters, tests, análisis estático, revisiones de código con IA. Cada mecanismo puede ser computacional (determinista, rápido, fiable) o inferencial (semántico, más costoso, no determinista). Ambos son necesarios: sin feedback, el agente repite sus errores; sin feedforward, codifica reglas sin saber si funcionan.
El artículo aplica el principio del shift left: distribuir los controles lo más temprano posible en el ciclo de desarrollo. Los controles rápidos (linters, tests unitarios) se ejecutan antes del commit, mientras que los más costosos (mutation testing, revisión arquitectónica) se ejecutan en el pipeline de integración. Los sensores continuos supervisan la deriva del código y las métricas de producción.
Se identifican tres categorías de regulación. El harness de mantenibilidad es el más maduro, apoyándose en herramientas ya existentes (linters, analizadores de complejidad, cobertura de tests). El harness de fitness arquitectónico reutiliza el concepto de fitness functions para características no funcionales. El harness de comportamiento sigue siendo el reto principal: ¿cómo verificar que la aplicación hace lo que se supone que debe hacer? Los conjuntos de tests generados por IA aún no son suficientemente fiables.
El concepto de harnessability subraya que no todas las bases de código se prestan por igual al harnessing. Los lenguajes tipados, los frameworks abstractos y las arquitecturas modulares ofrecen más asidero. La ley de la cibernética de Ashby justifica las harness templates: al reducir la variedad de topologías posibles (dashboard, CRUD, procesador de eventos), un harness completo resulta más alcanzable.
La autora concluye que la experiencia humana sigue siendo un "harness implícito" insustituible. El objetivo no es eliminar al humano, sino dirigir su atención hacia lo que más importa. El harness engineering es una práctica de ingeniería continua, no una configuración puntual, y quedan muchas preguntas abiertas en cuanto a la coherencia, evaluación y orquestación del harness.