Un agente de programación no es solo el modelo: es el modelo más todo el andamiaje que se construye a su alrededor. La ingeniería del harness, término acuñado por Viv Trivedy, trata ese andamiaje —prompts, herramientas, políticas de contexto, hooks, sandboxes, subagentes, bucles de retroalimentación y rutas de recuperación— como un artefacto de ingeniería que se corrige y endurece cada vez que el agente falla. La idea central es que un modelo mediocre con un gran harness supera a un gran modelo con un harness deficiente: en Terminal Bench 2.0, Claude Opus 4.6 obtiene resultados muy distintos según el harness en el que se ejecute, y un equipo pasó su agente del Top 30 al Top 5 modificando solo el harness.
El artículo repasa los componentes prácticos de un harness: sistema de archivos y Git como estado persistente, bash y ejecución de código como herramienta generalista, herramientas enfocadas, subagentes para planificar y ejecutar, y hooks que aplican restricciones deterministas. Frente a la tentación de esperar al próximo modelo, la ingeniería del harness propone trabajar hacia atrás desde el comportamiento deseado y convertir cada fallo en una regla permanente: añadir convenciones a AGENTS.md, bloquear comandos destructivos, dividir tareas largas o inyectar señales de back-pressure como un typecheck. Cada línea de un buen AGENTS.md debe poder rastrearse hasta un error real. Por eso el harness no se descarga: se moldea con la historia de fallos de cada codebase.