Tres pruebas de que el harness pesa tanto como el modelo

En mayo de 2026, mientras decidías si Opus 4.7 todavía vale el premium frente a Kimi K2.6, Mozilla anunció que sus agentes encontraron 423 bugs de seguridad en Firefox en un solo mes. En 2025, esa cifra estaba entre 20 y 30. Trece veces más, sin cambiar de proveedor de modelo.

Eso no es un dato suelto. Ese mismo mes se publicaron otros dos resultados que apuntan a lo mismo: el harness — el andamiaje alrededor del modelo: prompts, tools, loops de verificación, gestión de contexto — pesa tanto como el modelo. Y a veces más. Si te dedicas a llevar agentes a producción, esto te debería cambiar la asignación de tiempo del próximo trimestre.

Firefox: 13x más bugs sin cambiar de modelo

Mozilla pasó de 20-30 fixes mensuales en 2025 a 423 en abril 2026. Cuando Simon Willison desgrana cómo lo consiguieron, no atribuye el salto a un nuevo modelo de Anthropic. Lo dice explícito: “el éxito dependió en igual medida de técnicas dramáticamente mejoradas para domar a estos modelos — dirigirlos, escalarlos y apilarlos”.

El detalle importa. Si la mejora viniera del modelo, otros equipos con acceso al mismo modelo verían la misma curva. No la ven. La diferencia está en lo que Mozilla construyó alrededor: cómo orientan al agente, cómo filtran su salida, cómo encadenan invocaciones. Es el harness, no Mythos.

Hay un dato secundario que merece subrayar: muchos intentos del agente fueron bloqueados por las defensas existentes de Firefox. Eso significa que los 423 fixes no son falsos positivos amplificados — son vulnerabilidades reales que pasaron el filtro de un sistema diseñado para rechazar slop. La métrica es honesta. (fuente)

Zenith: 5 de 8 tareas a 43% del coste

Zenith, un harness de orquestación de agentes, ganó 5 de 8 tareas a un 43% del coste base, según el briefing semanal de Latent Space. Mismo modelo subyacente. Distinta arquitectura agéntica.

Léelo otra vez. El mismo modelo, mejor harness, te baja coste y sube win-rate al mismo tiempo. Eso es exactamente el tipo de mejora que un swap de modelo casi nunca consigue: cambiar de Opus a Kimi te ahorra 5x el coste, sí, pero típicamente con caída de calidad. Aquí no hay tradeoff — porque la palanca no es el modelo. (fuente)

La implicación es más fuerte de lo que parece. El consenso del último año decía: “elige el modelo más capaz que puedas pagar y luego pule el prompt”. Lo que muestra Zenith — y lo que muestran Mozilla con steering/scaling/stacking — es que esa secuencia se invirtió. Hoy la palanca está en la orquestación. El modelo es la pieza intercambiable.

Eugene Yan: el workflow como infraestructura

Eugene Yan publicó cómo trabaja él con Claude, y no es un benchmark: es un practitioner enseñando su sistema. Leído con cuidado, es un manual de cómo construir tu propio harness personal.

El sistema tiene piezas concretas, no abstractas:

• Directorios ~/src y ~/vault con INDEX.md anotado en cada uno. Tratar a cada sesión nueva como onboardear a alguien. La memoria del agente no existe por defecto; la fabricas tú.
• Jerarquía de CLAUDE.md con tres scopes: global (~/.claude/), por repo, y por proyecto. Cada nivel codifica un contrato de comportamiento. Lo que en 2025 era un prompt repetido cada sesión, ahora es configuración versionada.
• Shift verification left. Linters y hooks deterministas baratos antes que evals caros. El propio modelo ejecuta su loop de verificación cuando tiene cómo verificar.
• Sesiones paralelas en lugar de pair-programming. Yan ejecuta 3-6 a la vez. La unidad de trabajo deja de ser “una tarea con el agente” y pasa a ser “una cola de tareas”.
• Minería de transcripts. Ha analizado ~2.500 turnos pasados en busca de patrones de corrección recurrentes — “can you also…”, “still wrong” — y los convierte en reglas nuevas de CLAUDE.md.

Ninguna de esas inversiones depende del modelo subyacente. Todo es harness. Y todo compone: un CLAUDE.md afinado vale más mañana que hoy, mientras que el modelo que elijas hoy probablemente no será el de mañana. (fuente)

Generar era barato, verificar era caro: la asimetría se invirtió

Simon Willison, analizando el caso de Firefox, deja una frase sobre la economía de los outputs de un LLM que merece sección propia:

“What was previously cheap-to-generate but expensive-to-verify has been rebalanced through better model control and signal-filtering approaches.”

Durante 2024 y casi todo 2025, esa asimetría definió el techo de los agentes en producción. Generar mil sugerencias era trivial; auditarlas para encontrar las dos buenas costaba más que el problema original. Por eso muchos pilotos de agentes se quedaron en pilotos.

Lo importante de la frase es el verbo: has been rebalanced. Se equilibró. Pero no automáticamente. Se equilibró porque alguien construyó better model control y signal-filtering. Si tu harness sigue siendo el de 2025 — un prompt suelto, revisión manual de cada output, sin filtros automáticos — tu economía sigue siendo la de 2025. El modelo no te saca de ahí. Te saca tu arquitectura.

Cuánto tiempo en el modelo, cuánto en el harness

Si trabajas llevando agentes a producción, hazte la cuenta honesta: en el último trimestre, ¿cuántas horas pasaste comparando modelos, leyendo benchmarks de Kimi vs Opus, midiendo latencias? ¿Y cuántas pasaste refinando tu CLAUDE.md, escribiendo tools nuevas, instrumentando el loop con observabilidad?

La próxima ronda de mejoras competitivas — la que separe a los equipos que envían agentes en producción de los que se quedaron en demo — no la va a definir quién ejecuta el modelo más nuevo. La va a definir quién tiene el harness más maduro alrededor.

¿Qué pieza de tu harness te lleva más tiempo del que debería?