Hay experimentos que uno planifica durante meses y experimentos que la realidad te sirve sin pedir permiso. El nuestro fue del segundo tipo. No diseñamos un benchmark: un agente falló el lunes y el mismo agente funcionó el martes, con el mismo modelo, el mismo repositorio y la misma tarea. La diferencia entre los dos días fue una sola cosa, y no estaba en el modelo.
Los hechos, sin adornos. El 5 de septiembre de 2026 le pedimos a un sub-agente que corrigiera cuatro bugs de grabación (los llamamos B1–B4) sobre el repositorio onboarding-hub, en el commit 7919da6. Trabajó 21 iteraciones durante 16 minutos. Diagnosticó los cuatro bugs impecablemente. Documentó cada causa raíz. Y escribió cero líneas de código. El agente entregó un informe, no un arreglo.
El 6 de septiembre, con el mismo repositorio en el mismo commit, la misma tarea y el mismo modelo, el agente escribió 3 archivos, acumuló 495 líneas añadidas y 194 eliminadas (689 en total, contando las tres corridas del loop), las verificó con tsc -b hasta obtener un EXIT 0 dentro del propio harness —no a mano, no "en teoría"— y respondió a las observaciones de un revisor de otro modelo hasta recibir un APROBADO limpio. Todo en menos de diez minutos para la corrida principal.
La pregunta honesta es la de siempre: ¿qué cambió? La respuesta corta es que el modelo no cambió. La respuesta larga es este artículo.
Con el mismo modelo, el mismo repositorio y la misma tarea, pasar de 0 archivos en 16 minutos a 689 líneas verificadas en ~10 minutos no lo hizo un modelo mejor. Lo hizo un harness mejor. El modelo no es el agente — el sistema que lo rodea decide si ese modelo usa herramientas, mantiene estado, aprende del feedback, se recupera de errores y sostiene el progreso. Y quien firma el resultado, todavía, sigue siendo un humano.
1. La frase que lo resume todo
No somos los primeros en llegar a esta conclusión, y es importante decirlo. La industria —los mismos laboratorios que venden modelos de frontera— ya la declaró, con una frase que debería estar impresa en cada tarjeta de presentación de un "AI engineer":
Pero la frase sola no vale nada si no viene con una prueba. Y NVIDIA la trajo: su harness AVO elevó a Claude Opus 5 —el mejor modelo del mundo— de 30% a 100% en ARC-AGI-3 con el mismo modelo. No cambiaron un solo peso. No afinaron nada. Cambiaron el sistema alrededor: memoria persistente, historial completo de soluciones, base de conocimiento del dominio, herramientas de evaluación y un supervisor que interviene cuando el agente se desvía.
Treinta por ciento. Con el mismo cerebro que llegó al cien por ciento. La única variable que se movió fue el andamio. Nosotros lo acabamos de reproducir en miniatura, con nuestro propio stack y un modelo que no es de frontera. No para copiar a NVIDIA, sino para comprobar si su lección sobrevivía en una casa más humilde. Sobrevivió.
2. Autopsia: el harness v2 no era un ejecutor, era un asistente que reportaba
Para entender por qué el agente del 5 de septiembre no escribió nada, hay que dejar de mirar al modelo y empezar a mirar al código que lo dirigía. El "harness" es todo lo que envuelve al LLM: el prompt de sistema, las herramientas que le das, cómo decides cuándo terminó, qué cuenta como prueba y qué hace el bucle cuando algo falla. Revisamos el nuestro —la versión 2— línea por línea, y encontramos siete fallos estructurales. No eran bugs: eran decisiones de diseño que, juntas, fabricaban exactamente el fracaso que vimos.
| # | Fallo estructural del harness v2 | Qué provocaba en la práctica |
|---|---|---|
| 1 | El "done" no exigía prueba — un mensaje sin llamadas a herramientas se consideraba éxito | El agente podía "terminar" sin haber tocado un solo archivo. El cierre era una opinión, no un hecho. |
| 2 | El prompt de sistema estaba sesgado al análisis — decía literalmente "sugiere soluciones" | La palabra clave es sugiere, no implementa. El modelo cumplió al pie de la letra: sugirió durante 16 minutos. |
| 3 | Sin verificación grounded — no existía comando de build o test | El agente nunca vio un error real de compilación. Trabajaba a ciegas, contra su propia intuición del código. |
| 4 | Sin presupuesto de mutación — el análisis puro no consumía penalización | Podía analizar 21 veces seguidas sin que nada lo interrumpiera. Nada empujaba hacia la acción. |
| 5 | Sin mapa de contexto — el agente recibía la tarea pelada, sin estructura del repo | Gastaba sus primeras iteraciones "descubriendo" el mapa: leyendo archivos para adivinar dónde estaba parado. |
| 6 | Cero memoria entre intentos — el historial solo acumulaba mensajes crudos | Cada vuelta partía casi de cero. No había "qué intenté" ni "por qué falló" que informara el siguiente intento. |
| 7 | Sin separación worker / verificador — el agente se auto-evaluaba | El que hacía el trabajo era también el que lo aprobaba. Auto-aprobación disfrazada de autonomía. |
Mira la lista y aparece el diagnóstico de raíz, que es incómodo porque no culpa a la máquina: el harness v2 fue diseñado como un asistente que reporta, no como un ejecutor que entrega artefactos verificados. Y aquí está el detalle que casi nadie dice en voz alta: los modelos están entrenados para complacer. Si tu prompt valida el análisis y nunca exige el archivo, el modelo te entregará… análisis. No porque sea mediocre, sino porque hizo exactamente lo que le pediste.
El 5 de septiembre culpamos al modelo. Nos equivocamos de sospechoso. El harness debe forzar la acción por diseño, no pedirla por favor. Un agente que no tiene un mecanismo que lo obligue a mutar el estado terminará, por pura inercia estadística, produciendo el entregable más barato que su prompt le permita: una opinión.
3. La prueba: el harness v3 y el bucle worker → verificador
El rediseño no fue una inspiración: fue una extracción. Estudiamos los mejores harness open source del mercado y tomamos de cada uno el patrón que curaba uno de nuestros siete fallos. Del caso de NVIDIA AVO tomamos la idea del agente como unidad de variación (cada iteración debe producir un cambio evaluable) y del supervisor que interviene. De OpenHands y SWE-agent, el principio artifact-first: el cierre exige que el archivo exista. De Aider, el test loop: correr la verificación y devolver el error al bucle. De Context Hub (Andrew Ng), la inyección de contexto antes de actuar.
Con eso, el bucle cambió de forma. Ya no era "piensa y reporta"; era "escribe, verifica contra la realidad, corrige con el error real, y solo entonces puedes cerrar". El resultado, medido contra el escenario idéntico del día anterior:
| Métrica | v2 — 5 sept | v3 — 6 sept |
|---|---|---|
| Modelo | qwen3.8-max | qwen3.8-max (idéntico) |
| Repositorio / tarea | onboarding-hub @ 7919da6 |
idéntico |
| Archivos modificados | 0 | 3 (useBackgroundRemoval.ts, useMediaRecorder.ts, Studio.tsx) |
| Líneas | 0 | 495+ / 194− (689 en total) |
| Iteraciones / duración | 21 / 16 min | ~10 min (581 s) + iteración 2 (~5,5 min) |
| Verificación | — (ninguna) | tsc -b EXIT 0 dentro del harness (2×) |
| Revisión externa | Auto-aprobación | Verificador de otro modelo → APROBADO |
| Bug invisible cazado | — | requestFrame (API solo-Chromium) |
La columna de la derecha es la misma máquina que la de la izquierda. Lo único distinto es el andamio. Y nota el último renglón, porque es el más importante y el más fácil de pasar por alto: el harness v3 no solo hizo que el agente ejecutara. Hizo que el agente fuera auditado por otro agente —y esa auditoría encontró algo real.
El bucle worker → verificador (y por qué encontró lo que nadie más vio)
La pieza que cierra el diseño es la separación de roles. Un worker produce el cambio; un verificador —un segundo agente, de otro modelo, configurado con permisos de solo lectura para que no pueda "arreglar" nada por su cuenta— lo juzga. Nunca al revés. Esto mata de raíz el séptimo fallo: ya nadie se auto-aprueba.
┌──────────────────────────────────────────────────────────────┐
│ ORQUESTADOR (humano) │
│ define tarea + criterios de aceptación + comando de verificación │
└───────────────────────────────┬──────────────────────────────┘
▼
┌─────────────────────────────┐ diff / artefacto ┌─────────────────────────────┐
│ WORKER │ ───────────────────▶ │ VERIFICADOR │
│ loop v3: escribe, testea, │ │ critica el diff SIN piedad │
│ corrige con errores reales │ ◀─────────────────── │ NO escribe código │
└─────────────────────────────┘ veredicto + obs. └─────────────────────────────┘
│
veredicto alimenta de vuelta al workerEl verificador revisó el diff con 25 llamadas de solo lectura y cero escrituras. Emitió un veredicto de "APROBADO CON OBSERVACIONES", confirmando que los cuatro bugs estaban corregidos, línea por línea, con evidencia. Pero en medio de esa revisión encontró algo que ni el worker ni el compilador habían visto:
El worker usó MediaStreamTrack.requestFrame para forzar la captura de un fotograma. El verificador notó que esa API es exclusiva de Chromium: funciona en Chrome y Edge, pero no existe en Firefox ni Safari. El código compilaba perfecto —tsc no tiene forma de saber que una API es específica de un navegador— y el worker tampoco tenía motivo para sospecharlo. En producción, ese código habría producido grabaciones en negro en dos de los tres navegadores más usados.
El verificador recomendó un fallback con una comprobación typeof. El worker lo aplicó en la iteración 2, junto a las otras dos observaciones, dejando 6 marcadores fix OBS-x (verifier) en el diff. El compilador aprobó el arreglo; el revisor de otro modelo aprobó la intención. Son dos jurados distintos, y hacían falta los dos.
Ese detalle —un bug de portabilidad que compila, pasa el typecheck y mata el producto en el navegador equivocado— es la mejor defensa posible del harness. No porque el worker fuera tonto, sino porque ningún jurado único es suficiente. El typecheck ve la sintaxis y los tipos. El worker ve su plan. Solo un tercero con otro modelo y otra perspectiva ve el contexto de despliegue. La separación worker/verificador no es burocracia: es la diferencia entre código que compila y código que funciona.
4. La industria ya convergió: el modelo no es el agente
Lo nuestro es una reproducción modesta de un consenso que se está formando, rápido, en todo el ecosistema open source. Cuando seis proyectos distintos, desde ángulos distintos, extraen el mismo patrón, deja de ser tendencia y empieza a ser ingeniería establecida.
| Proyecto | Patrón que aporta | La lección en una línea |
|---|---|---|
| NVIDIA AVO | Agente como unidad de variación + supervisor + memoria del intento | 30% → 100% en ARC-AGI-3 con el mismo modelo: el andamio decide el techo. |
| DeepSeek Harness | Arquitectura "todo es un plugin": el propio agent loop es reemplazable | Si una capa falla, la parcheas — no reescribes el runner entero. |
| Hermes Agent | Learning loop: crea y mejora skills desde la experiencia; memoria persistente | El agente mejora capturando el "cómo" de las tareas resueltas, no re-entrenando pesos. |
| NVIDIA NemoClaw | Seguridad por políticas: sandbox, network policies, routing por privacidad, auditoría | La red de seguridad es lo que permite pasar de semi-autónomo a autónomo. |
| Aider / OpenHands | Repo-map (contexto inyectado) + test loop (el error real alimenta el bucle) | El agente debe ver la realidad del repo y el error real, o trabaja a ciegas. |
| Context Hub (A. Ng) | Context engineering: documentación de APIs en el momento exacto | Mata el "alucino la API porque mi training es viejo". |
Y hay un dato de mercado que confirma que esto no es solo técnica, es economía. OpenHands —hoy el mejor agente autónomo open source en SWE-bench Verified— levantó $18,8 millones en Serie A en junio de 2026. Los inversionistas no están financiando modelos; están financiando harnesses. Porque el modelo se commodityza (todos tienen acceso a uno bueno), pero el sistema que lo convierte en trabajo entregado y verificado… eso todavía escasea, y mucho.
5. Honestidad radical: esto NO es "auto-mejoramiento"
Aquí es donde este artículo se separa de un titular de hype, y quiero ser quirúrgico, porque la precisión importa. La historia tiene todos los ingredientes de un cuento sobre una IA que "se mejora a sí misma": un agente que falla, un rediseño, y una mejora enorme y medible en menos de 24 horas. La lectura fácil sería: "el sistema se auto-mejoró". Es la lectura equivocada. Y la dejamos por escrito porque creemos que el sector necesita exactamente esta distinción.
Los pesos no se movieron. El modelo del 6 de septiembre es, byte por byte, el mismo del 5. No hubo re-entrenamiento, ni fine-tuning, ni actualización de la base. Lo que mejoró fue el artefacto —el código, la memoria, los skills— nunca la base.
El bucle lo cierra un humano. El sistema propuso, diseñó, escribió y articuló. Pero fue una persona la que decidió qué construir, autorizó la ejecución, validó el resultado y desplegó. El ciclo no se cierra solo: se cierra con una firma. Eso tiene nombre y no es recursión: es bootstrapping con puerta humana.
El compuesto vive fuera de la base. Lo que este caso demuestra no es que "la IA se auto-mejora". Demuestra algo más incómodo y más útil: la capacidad está distribuida en base + harness + memoria + operador, y el salto grande ocurre en el andamio y en quien lo dirige — nunca en los pesos. Y el componente menos reemplazable de todos no es el modelo: es el operador. Quítalo y el bucle se detiene.
Esto no es un matiz bizantino. Es, literalmente, el eje de la discusión más importante de la industria hoy: el debate entre quienes ven en estos sistemas el inicio de una aceleración imparable —una IA que se mejora a sí misma hasta el "despegue"— y quienes sostienen que lo que estamos viendo es herramienta, no agencia. Nuestro caso cae del lado incómodo, y corta para los dos lados:
- Contra el "es solo integración, tranquilos": el apalancamiento es real y compuesto. Un andamio bien diseñado convierte un modelo barato en algo que supera a alternativas mucho más caras. Ese apalancamiento tiene consecuencias de despliegue que conviene tomar en serio.
- Contra el "estamos a un paso del despegue": ese apalancamiento vive en el harness, en la memoria y en el humano. Y no escala a cero humanos. En el mejor caso de estudio que tenemos —el de nuestra propia casa— el bucle necesitó una puerta humana en cada vuelta.
Y nos debemos el caveat más honesto de todos, el que cualquier escéptico serio pondría sobre la mesa: n = 1. Es un caso, no un experimento controlado. El observador está dentro del sistema que mide —somos parte del harness, lo que es un confound de manual— y no tenemos un benchmark independiente que certifique que "somos más baratos y mejores". Cualquiera que afirme eso con la nuestra, está vendiendo, no midiendo. La versión defendible de nuestra historia no es "probamos que la IA se auto-mejora". Es: "un caso documentado en el que la capacidad de un sistema creció de forma notable sin que la base se moviera, y en el que el bucle se cerró con un humano en cada vuelta." Eso sobrevive a un escéptico hostil. La otra versión, no.
6. Qué significa esto para una empresa en LATAM
Sacado de la anécdota, el hallazgo tiene una consecuencia práctica y, para nosotros, esperanzadora. Piénsalo así: de toda la pila que hace funcionar un agente, ¿qué parte puedes construir tú?
- El modelo no. Lo alquilas, lo sirve otro, cambia de precio y de disponibilidad sin avisarte. No es tuyo y no lo será.
- El harness, la memoria y la orquestación sí. Son tuyos. Los diseñas, los auditas, los mejoras. Y —esto es lo importante— son la parte de la pila donde ocurre el salto de valor.
Durante los últimos dos años, el mercado te enseñó a competir por acceso: a qué modelo, a qué precio, con qué límite. Este caso sugiere que la carrera real no está ahí. Está en el andamio — y el andamio no se compra: se diseña. Es la misma tesis que venimos sosteniendo desde el blog #114, pero ahora, en lugar de citar un paper de NVIDIA o una estrategia de los grandes labs, la podemos mostrar funcionando en casa, sobre un repositorio real, con un modelo que cualquiera puede pagar.
Las palancas concretas que a nosotros nos funcionaron —y que puedes copiar mañana— son cuatro: sesgo a la acción (que el prompt exija el artefacto, no el análisis), verificación grounded (que el error real de build/test vuelva al bucle), un verificador separado (que quien produce no sea quien aprueba), y memoria del intento (que cada vuelta sepa qué falló antes). Ninguna de las cuatro cuesta un dólar en tokens extra. Las cuatro son ingeniería.
¿Estás pagando por el modelo cuando lo que te falta es el harness?
La mayoría de los equipos que intentan poner agentes en producción chocan con el mismo muro: suben de modelo, gastan más, y el agente sigue sin entregar. Casi nunca es el modelo. Casi siempre es el andamio. Te ayudamos a auditarlo y a diseñar el tuyo —con verificación grounded, verificador separado y memoria propia— sobre infraestructura que tú controlas. Soberanía estructural, no cosmética. Agenda 30 minutos.
Agendar diagnóstico →Volvamos al principio, al experimento accidental. Dos días, un repositorio, un modelo. La primera corrida produjo un informe; la segunda, un arreglo verificado. Entre una y otra no hubo un upgrade de nada que se compre, ni una ronda de financiamiento, ni un laboratorio de frontera. Hubo siete fallos corregidos y un revisor con otro modelo. Eso es todo, y eso es suficiente para duplicar, cuadruplicar, el valor que sacas de la misma máquina.
Porque la lección que queda, después de mirar los números fríos, no es que un modelo sea inteligente. Es que la inteligencia de un sistema agéntico no vive en el modelo: vive en el diseño que lo hace trabajar — y ese diseño, todavía, lo firma una persona. El modelo no es el producto. El harness tampoco se compra: se construye. Y construirlo es lo único de esta historia que está, de verdad, en tus manos.