El modelo no es el sistema: qué aprendimos al adoptar un harness

Durante mucho tiempo pensamos que la pregunta importante era qué modelo usar para programar. El modelo más nuevo. El que razona mejor. El que promete escribir más código con menos errores.

Esta semana hemos cambiado de opinión.

La pregunta importante no es qué modelo tienes. Es qué sistema lo rodea: qué contexto recibe, qué puede tocar, cuándo cambia de modelo, cómo se verifica lo que hace y quién decide si el resultado sale.

En Zero Ops llamamos a ese sistema harness. No es un prompt largo. Es la forma completa de trabajar con un agente.

No hemos construido este harness desde cero. Hemos adoptado patrones y herramientas existentes y los hemos adaptado a nuestro entorno de trabajo. La investigación está en entender qué merece quedarse, qué hay que cambiar y qué todavía no podemos dar por probado.

Este artículo reúne tres cosas distintas y las deja separadas: lo que hemos leído en fuentes públicas, lo que hemos probado en nuestro entorno y lo que todavía es una hipótesis.

La factura está en la lectura

Can Bölük (@_can1357) publicó un análisis de aproximadamente 1,81B tokens repartidos en unos 2 millones de tool-calls. En esos datos, solo el 9% de los tokens correspondía a edits y writes; el 91% restante era lectura, búsquedas y contexto.

Es una observación del propio autor, no una ley universal de todos los agentes. Pero cambia la forma de mirar el coste. El agente no pasa la mayor parte del tiempo escribiendo. Pasa la mayor parte del tiempo intentando entender dónde está.

Si un patrón obliga a dos modelos a leer el mismo código, has duplicado la parte cara antes de llegar al primer cambio.

El plan es una postal

El patrón habitual parece razonable:

1. el modelo caro lee el repositorio y prepara un plan;
2. el modelo barato recibe el plan;
3. el modelo barato ejecuta.

El problema es que el plan es una postal de 2.000 tokens. El entendimiento real estaba en el viaje: archivos leídos, hipótesis descartadas, errores encontrados y decisiones tomadas al tocar el código.

El ejecutor recibe la postal, no el viaje. Por eso vuelve a leer.

En el benchmark de Stencil, Opus 4.8 solo costó 2,78 dólares por tarea y consiguió un 85% de pass rate. Opus con /plan y Flash ejecutando costó 3,18 dólares, con un 84,6% de pass rate. El supuesto ahorro salió un 14% más caro.

No significa que planificar sea inútil. Significa que separar planificación y ejecución con un documento no garantiza que estés transfiriendo comprensión.

Prewalk: pasar la trayectoria

La alternativa que nos parece más interesante se llama prewalk.

El flujo es este:

1. el modelo frontier explora el problema;
2. convierte lo que ha entendido en una lista corta de tareas con verificación;
3. hace el primer edit;
4. en ese momento, el harness conmuta al modelo barato dentro de la misma sesión;
5. el modelo barato continúa con la trayectoria, el TODO y un primer movimiento válido como ejemplo.

No se cambia de modelo porque hayan pasado cuatro turnos. Se cambia cuando se cumplen dos señales: existe una lista ejecutable y el modelo ya ha tocado el código con un primer movimiento válido.

En el brazo de Opus de Stencil, /prewalk bajó el coste a 1,46 dólares y el tiempo a 6,7 minutos, con un 78% de pass rate. Es peor en calidad que Opus solo y mejor en coste. Ese intercambio es el dato; decidir si compensa depende del trabajo.

El mismo artículo mide además cuántas ejecuciones buscan la solución publicada del bug en Internet. En Opus, el porcentaje pasó del 44% en la ejecución directa al 72% con /plan y al 13% con /prewalk. Es un resultado específico de SWE-Bench Pro, no una afirmación general sobre la intención de los modelos.

Mi resumen es sencillo: no le pases al modelo barato el resumen. Pásale la sesión.

Cinco fases, cinco preguntas

La otra idea que nos llevamos es separar los papeles. Un agente que explora, planifica, ejecuta y se califica con el mismo objetivo acaba mezclando tareas.

Lo ordenamos así:

• Explorer: ¿cuál es el problema de verdad?
• Planner: ¿qué depende de qué y dónde hace falta una decisión humana?
• Worker: ¿qué tarea concreta toca ahora?
• Critic: ¿qué podría estar mal o ser más simple?
• Promoter: ¿qué se ha hecho, con qué evidencia y qué queda abierto?

No es una ley del sector. Es un arco de trabajo que hace visibles los cambios de contexto y permite elegir el nivel de modelo y verificación en cada fase.

El worker no necesita volver a filosofar sobre toda la arquitectura en cada paso. El critic no debe limitarse a decir que todo parece bien. El promoter evita que una tarea técnicamente terminada desaparezca sin comunicación ni registro.

Qué hay dentro de un harness

Un harness útil tiene piezas muy poco glamourosas:

1. Reglas de entrada: un AGENTS.md que define alcance, carpetas, estilo y condiciones de parada.
2. Skills reutilizables: una fuente única que varios agentes puedan leer sin copiar instrucciones a mano.
3. Herramientas con contrato: argumentos válidos, errores claros y permisos acotados.
4. Contexto controlado: memoria de trabajo y decisiones relevantes, no todo el historial acumulado sin criterio.
5. Verificación fuera del generador: compilación, tests, existencia del entregable, diff y después revisión de criterio.
6. Rastreo: qué se pidió, qué cambió, qué comprobación se ejecutó y qué no se pudo probar.
7. Un punto humano: el agente puede proponer y ejecutar dentro de su alcance; la publicación y los cambios de riesgo necesitan decisión.

La conclusión de Scott Fryxell va en la misma dirección: si Cursor, Claude, Pi o Codex leen las mismas skills y reglas, la experiencia se vuelve intercambiable. La ventaja no está en la marca de la interfaz, sino en el sistema de trabajo que todas comparten.

Lo que hemos adoptado y adaptado en nuestro entorno

Esta parte es experiencia propia, fechada el 28 de agosto de 2026.

Ya está funcionando

• uso una carpeta de skills compartida para que Codex y Claude Code no aprendan reglas distintas;
• separo exploración, planificación, ejecución y revisión cuando la tarea tiene varias piezas;
• hago comprobaciones baratas antes de pedir una crítica larga: build, tests, salida y diff;
• trato el contexto y la evidencia como parte del trabajo, no como documentación que se añade al final.

Todavía no lo damos por probado

• el relevo automático de prewalk en tareas reales de nuestro repositorio;
• qué modelo barato mantiene mejor la calidad como worker en cada tipo de cambio;
• si el arco de cinco fases reduce de forma medible mis ciclos de revisión;
• si un modelo nuevo mantiene el mismo comportamiento en tools y JSON, no solo en chat y visión.

Esta separación importa. Adoptar un patrón no demuestra que funcione en producción. Tener una conversación convincente tampoco.

Las objeciones son parte del diseño

Hay tres objeciones que no queremos esconder.

La primera: para algunos equipos, el plan separado sí protege el contexto principal y hace más cómodo coordinar subagentes. Puede ser la decisión correcta.

La segunda: si una persona revisa cada línea, ahorrar un dólar de modelo y pagar otra ronda de revisión es mal negocio. El tiempo humano también tiene precio.

La tercera: un cambio de alto riesgo no se vuelve seguro porque el worker sea barato. Si el coste de equivocarse es alto, usar el modelo frontier durante todo el flujo puede ser la opción más barata en términos reales.

La decisión no es “caro contra barato”. Es:

• ¿cuánto cuesta volver a leer?
• ¿cuánto cuesta revisar?
• ¿qué daño hace un error?
• ¿qué pruebas automáticas existen?
• ¿qué parte del trabajo ya tiene un patrón conocido?

Una prueba de 30 minutos

Para saber si tu propio harness está ayudando, elige una tarea pequeña y registra cinco cosas:

1. cuántos turnos pasan antes del primer edit;
2. qué archivos tuvo que leer el agente más de una vez;
3. qué parte del plan se perdió al cambiar de modelo;
4. qué comprobaciones detectaron errores sin usar otro modelo;
5. qué decisión humana quedó explícita al cerrar.

No necesitas montar una plataforma. Necesitas una comparación. Haz una ejecución directa y otra con un relevo controlado. Mide tiempo, lecturas, errores y revisión humana. Si solo mides tokens, te falta la mitad del coste.

La conclusión

Los modelos seguirán cambiando. Un nombre sustituirá a otro y el catálogo volverá a llenarse de promesas.

Lo que permanece es el sistema alrededor:

• qué contexto entra;
• qué trabajo se considera listo;
• cuándo se cambia de modelo;
• quién verifica;
• qué evidencia queda;
• y quién tiene permiso para continuar.

El modelo puede ser una pieza intercambiable. El harness es la operación.

Del experimento a la capacidad

En Zero Ops ayudamos a nuestros clientes a implementar este tipo de soluciones en su operación: entender dónde generan valor, adaptarlas a sus procesos y dejar reglas, verificaciones y responsables claros.

El objetivo no es convertirnos en otra dependencia para cada ajuste. Es que el equipo pueda operar, revisar y mejorar el sistema por sí mismo, reduciendo la necesidad de servicios profesionales recurrentes. Si el sistema solo funciona mientras estamos dentro, no hemos transferido capacidad: hemos creado otra caja negra.

Si vuestra empresa está intentando llevar agentes o automatizaciones a producción, el diagnóstico operativo de 2 semanas es la primera puerta. Salimos con el flujo mapeado, el valor medido y un plan que vuestro equipo puede seguir ejecutando.

Fuentes, autores y proyectos

• Scott Fryxell — The Harness Is the Thing, GitHub @scott-fryxell y brayness. Tesis, experiencia personal y harness público.
• Can Bölük — You only need the frontier model for one single edit, X @_can1357. Distribución de tokens, benchmark de SWE-Bench Pro y prewalk.
• Fred Hohman, Matthew Conlen, Jeffrey Heer y Duen Horng Chau, Communicating with Interactive Articles. Principios de artículos interactivos y límites de scroll/animación.
• Bruno Gonçalves — Building an Advanced Agentic Harness, X @bgoncalves y repositorio DataForScience/LLMs. Primitivas de roles, herramientas, planes y verificación.
• Debate en Hacker News. Contrapuntos de la comunidad.

Los datos de benchmark son de sus autores. Las observaciones sobre nuestro entorno son propias y están fechadas. Las conclusiones generales son una interpretación, no una promesa de rendimiento.