El 29 de abril, Elvis Saravia publicó en X un hilo de 128 mil vistas sobre “Agentic Harness Engineering”, paper de Fudan + Peking + Shanghai Qiji Zhifeng subido al arXiv un día antes. Toda la prensa se quedó con la cifra que sube: pass@1 en Terminal-Bench 2 trepa de 69.7% a 77.0% en diez iteraciones del loop, sin tocar el modelo base. El harness evolucionado vence al harness humano de Codex-CLI (71.9%).

Hay otra cifra. La que ningún hilo citó. Está dos páginas más adelante, en la Tabla 3.

Los siete archivos del harness

El paper formaliza una idea que llevaba dos años flotando como folclore. Un agente de código no es solo el modelo. Es el modelo más siete componentes editables que viven como archivos en un workspace: system prompt, descripción de herramientas, implementación de herramientas, middleware, skills, sub-agentes y memoria de largo plazo.

La contribución del paper no es nombrar los siete. Es tratar cada uno como archivo bajo control de versión, con diff línea por línea, rollback al instante y un manifiesto que predice qué tareas debería arreglar la edición y cuáles está en riesgo de romper. Cada cambio se vuelve un contrato falsificable: la siguiente ronda de evaluación lo confirma o lo revierte.

La Tabla 3 que ningún hilo citó

La Tabla 3 hace algo aburrido pero crucial: aísla el efecto de cada componente. Toma el harness baseline (NexAU₀, 69.7% pass@1) y le agrega un componente evolucionado a la vez:

• + memoria sola: +5.6 puntos
• + herramientas solas: +3.3 puntos
• + middleware solo: +2.2 puntos
• + system prompt solo: -2.3 puntos

El system prompt fue el único componente que retrocedió cuando se aisló del resto. Y la sorpresa adicional: en tareas Hard, la memoria sola supera al harness completo.

Los autores explican el motivo en una sola línea: “the system prompt encodes 79 lines of universal discipline whose executability depends on the other three” (el system prompt codifica 79 líneas de disciplina universal cuya ejecutabilidad depende de los otros tres). Disciplina sin maquinaria es ruido. El agente lee “verifica antes de publicar” pero no tiene un middleware que actúe esa verificación, y el resultado es más turnos gastados re-chequeando lo que ya estaba verificado.

Esa frase del paper se lee como descripción tardía de lo que Pawel Huryn ya había publicado en X el 25 de abril. Huryn bajó su factura mensual de Claude Code de $750 a $100 sin cambiar de modelo, limpiando cuatro palancas: cache hit rate, presupuesto de contexto, ruteo de modelos y formato de input. Las cuatro mapean exactamente sobre middleware, herramientas y descripciones de herramientas. Ninguna sobre prompt. Lo que Huryn hizo intuitivamente, el paper lo formaliza con números.

La transferencia entre modelos: el moat empírico

La parte que cierra la conversación con código-no-es-barato y runtime-commodity está en la sección 4.3. Los autores toman el harness evolucionado en GPT-5.4 high y, sin reentrenar, lo evalúan sobre cinco modelos base distintos. Las cinco corridas dan ganancia positiva entre +2.3 y +10.1 puntos, las más grandes en deepseek-v4-flash y qwen-3.6-plus.

Cruzando familias de modelos. Significa que los siete archivos del harness no codifican trucos específicos de Claude o de GPT; codifican patrones generales de cómo se hace el trabajo en agentes de código. Cuando Anthropic publique Claude Sonnet 4.7 el próximo trimestre y un equipo decida hacer el swap, el harness bien diseñado sobrevive al cambio. El prompt cuidadosamente afinado al modelo anterior, no.

El asterisco: ceguera a regresiones

El paper es honesto sobre lo que el loop no hace bien. Sección 4.4.2: la precisión del agente prediciendo qué tareas su edición va a arreglar es 33.7% (5x baseline aleatorio). La precisión prediciendo qué va a romper es solo 11.8% (~2x baseline). El loop es razonablemente bueno apuntando a qué arregla. Es ciego apuntando a qué rompe.

Rohan Paul publicó el 30 de abril el resumen del paper DELEGATE-52 de Microsoft con el mismo síntoma: incluso modelos frontera corrompen alrededor del 25% del contenido de un documento al delegarles ediciones largas, porque no se auto-atribuyen las regresiones. Por eso Howie Liu corre 30 instancias de Claude Code en paralelo en HyperAgent con revisión cruzada de PRs entre instancias. La revisión cruzada no es estética. Es la única estrategia que atrapa las regresiones que el loop autónomo no nombra.

El patrón que llevo viendo desde 1990

Llevo 36 años en esto. Empecé en 1990, a los 15, en una Commodore 64. He visto cinco veces el mismo ciclo: ensamblador → compilador, SQL crudo → ORM/índices, servidor manual → orquestación declarativa, primitivas de UI → framework integrado al dominio. Cada vez la capa que se volvió commodity no era el problema; el problema era la capa creciendo encima. Los equipos que sobre-invirtieron en la capa barata perdieron el ciclo. Los que aprendieron a ser dueños de la capa de arriba ganaron.

Quinto ciclo. El system prompt es la capa que la industria está afinando. Los siete archivos del harness son la capa creciendo encima. El equipo que invierta esta semana en plantillas de prompt está repitiendo el error de los DBAs que en 2003 seguían memorizando hints de Oracle.

Cinco preguntas antes del siguiente cheque de productividad de IA

Si el comité ejecutivo va a aprobar el siguiente cheque de IA, vale la pena correr este test antes de firmar:

1. Inventario. ¿Cuáles de los siete componentes existen como código bajo control de versión, con diff y rollback a nivel archivo? Si algún componente “vive en un canal de Slack”, está bajo folclore, no bajo ingeniería.
2. Falsificabilidad. ¿Cada cambio al harness lleva una predicción escrita de qué debería arreglar y qué pone en riesgo, verificada después? Si las ediciones no se miden contra resultados de tarea, lo que tienes es prompt-folclore con git encima.
3. Transferencia. ¿Has corrido tu harness en al menos un modelo distinto al que evolucionó? Si no, no sabes si sobrevive el siguiente Sonnet.
4. Regresión. Cuando un cambio rompe tareas que antes funcionaban, ¿hay revisión humana o cross-review entre instancias que lo atrape? “El loop se auto-revisa” tiene 11.8% de precisión. Tu equipo no quiere operar a esa altitud.
5. Dueño. ¿Quién es dueño con nombre y apellido de los siete archivos? Si la respuesta es “todo el equipo” o “el lead de IA”, la respuesta operativa es nadie.

Si tu equipo no contesta las cinco con claridad, la siguiente conversación útil dura dos horas. Mapeamos uno de tus harnesses, marcamos qué está bajo ingeniería y qué está bajo folclore, y dejamos por escrito qué requiere intervención. Sin cotización atada. El correo es el de siempre: info@iqsource.ai.

Qué hacemos en IQ Source con esta distinción

AI Maestro existe para que la auditoría de los siete archivos pase antes de que el harness se vuelva carga crítica del negocio. La mayoría de los comités ejecutivos descubren al hacer el ejercicio que cuatro o cinco de los siete componentes no existen como artefacto de ingeniería en su empresa.

Socio Tecnológico, la otra línea, aplica para empresas de software cuyo producto vive en zona crítica desde el día uno. Para ese tipo de empresa, el harness deja de ser herramienta de oficina y se vuelve parte del entregable. El cerebro de IQ Source que describí ayer es, leído desde el ángulo del paper, una implementación de uno de los siete archivos: la memoria de largo plazo, la única capa que el coro público de Karpathy estuvo discutiendo todo abril, mientras los otros seis seguían fuera del radar.

Tres años de prompt engineering optimizaron la capa equivocada. La buena noticia es que el paper publicó código abierto y las palancas reales son medibles. La mala es que el comité ejecutivo que no haga el ejercicio este trimestre va a despertar en el cuarto, igual que despertaron tarde los que no entendieron que el ORM era el moat sobre las queries baratas.