Code as Agent Harness — un survey de 102 páginas que ve el código como la base de ejecución de los agentes

UIUC × Meta × Stanford colaboraron en esto. Es un paper de survey subido a arXiv en mayo, y la perspectiva es bastante interesante.

Argumento central

"El código ya no es solo un resultado generado por un LLM. Es el operational substrate (base de ejecución) donde el agente razona, actúa, guarda estado y valida retroalimentación."

Es decir, el código no es simplemente un archivo .py, sino el propio mundo en el que vive el agente. A esto lo llaman code as agent harness.

Estructura de 3 capas

El paper analiza los sistemas de agentes dividiéndolos en 3 capas:

① Harness Interface — la forma en que el código conecta al agente con el entorno

• Como en Program-of-Thoughts, externalizar el razonamiento en código para ejecutarlo/verificarlo
• En control de GUI/robots, el programa generado funciona como política
• El codebase, los traces y los simuladores representan el entorno mismo

② Harness Mechanisms — el sistema de control que sostiene la ejecución a largo plazo

• Planning: está evolucionando más allá de la simple decomposition hacia planificación persistente basada en sistema de archivos, con archivos como PLAN.md. Meta-Harness toma el propio diseño del harness como espacio de búsqueda
• Memory: lo analiza dividiéndolo en working/semantic/experiential/long-term/multi-agent + context compaction. La idea clave es que "la memoria no es una sola vector DB, sino una capa integrada de gestión de estado"
• PEV Loop: redefine el ciclo Plan → Execute → Verify como un cybernetic governor. La ejecución sigue un modelo de permisos de 3 etapas: read-only → sandbox-edit → full-access(HITL)
• AHE: una meta-capa que mide y optimiza el propio harness

③ Scaling the Harness — cómo colaboran múltiples agentes sobre el código como medio compartido

• Hallazgo interesante: "la complejidad topológica es un impuesto creado por la inmadurez de la representación de estado compartido" — los sistemas con un buen diseño de estado funcionan bien incluso con estructuras simples, mientras que los que dependen de estado implícito compensan esa carencia con topologías complejas

Puntos llamativos

• Context Compaction + State Offloading: no metas todo en la ventana de contexto; deja en el contexto activo solo el resumen necesario para decidir, y descarga los datos completos mediante protocolos estilo MCP — esto es un tip totalmente práctico
• La verificación como sensor determinista: feedback determinista como linters, type checkers, tests y fuzzers ofrece señales de control más confiables que la crítica de un LLM
• La causa del fallo no está en el modelo, sino en el harness: "la mayoría de las fallas de agentes vienen de contexto insuficiente del repositorio, interfaces de herramientas frágiles, verificadores débiles, costos excesivos de tokens y políticas de reintento equivocadas"

Open Problems

Entre los 7 problemas abiertos que deja el paper:

• Evaluación más allá del éxito final: también los traces intermedios, los intentos de recuperación y los checks de seguridad deben ser métricas de primer nivel
• Mejoras del harness sin regresiones: cómo aprender de los fallos sin romper el comportamiento existente
• Estado compartido transaccional entre múltiples agentes: resolver conflictos cuando varios agentes modifican código al mismo tiempo

Referencia

• Paper: https://arxiv.org/abs/2605.18747
• Sitio con resumen claro: https://code-as-harness.github.io/code-as-harness-webpage/
• Colección de papers relacionados: https://github.com/YennNing/Awesome-Code-as-Agent-Harness-Papers