En los dos artículos anteriores quedó una idea encima de la mesa. Primero, que un agente es un modelo más un harness, y que el harness —el bucle, las herramientas, la gestión de contexto y los límites— pesa más en el resultado que el propio modelo. Después, que el harness de una herramienta real como Claude Code está escrito a mano: alguien decidió cada pieza. Si juntas las dos, sale una pregunta que la investigación de 2026 está intentando responder: si el harness es lo que importa y se escribe a mano, ¿se puede hacer que se escriba solo?
Eso es lo que se llama harness auto-evolutivo, y es la frontera actual del tema. No es producto todavía; es un campo de papers recientes, varios de ellos de los últimos dos meses. Aquí cuento qué es, qué resultados está dando y, sobre todo, cuál es el límite que la mayoría de la cobertura se salta. Si llegas a este artículo sin contexto, empieza por la base: Qué es un harness en IA y Cómo funciona Claude Code por dentro.
Aviso: esto es investigación, no producción
Todo lo que sigue viene de preprints publicados en arXiv entre marzo y junio de 2026. Son resultados de laboratorio sobre benchmarks concretos, con código en estados tempranos. No es algo que vayas a conectar a un proyecto de cliente mañana. Lo cuento porque el patrón de fondo sí es aplicable hoy, y porque marca por dónde va a ir la herramienta que usas. Pero conviene leerlo como lo que es: la frontera, no la práctica asentada.
Qué significa "auto-evolutivo" exactamente
Un agente tiene dos capas que se pueden modificar. Una son los pesos del modelo, que se cambian con entrenamiento por gradiente: generaliza bien, pero es caro y arrastra riesgos como el olvido catastrófico y la regresión de capacidades. La otra es el harness: la lógica de orquestación, el control de flujo, el runtime de herramientas, los bucles de recuperación de errores. Esta capa se puede cambiar sin tocar un solo peso del modelo, reescribiendo sus piezas.
El harness auto-evolutivo trabaja en esa segunda capa. La definición que usan los papers es precisa: el modelo se mantiene congelado, y el harness se revisa de forma automática a partir de la evidencia de ejecución. Es decir, el agente corre tareas, falla en algunas, y de esos fallos —las trazas, los resultados, los errores— se deducen cambios en el propio harness que se aplican y se reutilizan en las tareas siguientes. La inteligencia que propone los cambios es otro agente; el modelo base no se reentrena.
La razón de atacar esta capa y no los pesos es práctica. Es más barato, no requiere reentrenar nada, y el resultado es portable: un harness mejorado se puede mover a otro modelo. Eso último es la propiedad que hace el campo interesante, y a la que vuelvo más adelante.
AHE: el caso que mejor lo enseña
El trabajo de referencia es Agentic Harness Engineering (AHE), un preprint de finales de abril de 2026 (arXiv:2604.25850). Plantea el problema de manera clara: automatizar la ingeniería del harness es difícil porque el espacio de cambios es heterogéneo, la señal de evaluación es escasa y ruidosa, las trazas ocupan millones de tokens, y es complicado atribuir el efecto de un cambio al resultado de la siguiente ronda. Su propuesta es instrumentar las tres etapas de cualquier bucle de ingeniería con tres tipos de observabilidad.
La primera, observabilidad de componentes: cada pieza editable del harness tiene una representación a nivel de fichero, de modo que el espacio de cambios es explícito y reversible. En su implementación, el harness se descompone en siete componentes ortogonales —prompts de sistema, descripciones de herramientas, implementaciones de herramientas, middleware, skills, subagentes y memoria a largo plazo—, cada uno bajo control de versiones para que todo cambio sea auditable y se pueda revertir.
La segunda, observabilidad de experiencia: las trazas crudas, que pueden sumar diez millones de tokens, se destilan en un corpus de evidencia por capas que el agente que evoluciona el harness puede consumir de verdad, en lugar de ahogarse en ellas.
La tercera, y la más interesante, observabilidad de decisión: cada cambio se acompaña de una predicción autodeclarada. Antes de aplicarlo, el agente registra qué evidencia de fallo lo motiva, qué causa raíz infiere, qué arregla y qué tareas podría romper. En la ronda siguiente, el sistema cruza esa predicción con los resultados reales y emite un veredicto por cambio: lo que funcionó se queda, lo que no, se revierte a nivel de fichero. La idea, simplificada, es que cada edición es un contrato falsable en vez de una justificación:
edit:
failure_evidence: "timeout en tareas con tests largos"
root_cause: "el harness no paginaba la salida de los tests"
fix: "añadir paginación en el tool de ejecución"
predicted_fixes: [task_14, task_22]
predicted_regress: [task_07]Si en la siguiente ronda task_14 y task_22 pasan y task_07 no se rompe, el cambio se confirma. Si la predicción falla, se descarta. Eso evita que el bucle colapse en prueba y error.
Los números que da son concretos. Diez iteraciones de AHE suben el pass@1 en Terminal-Bench 2 del 69,7% al 77,0%, por encima del harness diseñado por humanos Codex-CLI (71,9%) y de los métodos auto-evolutivos previos. En la configuración con un modelo más fuerte, el proyecto reporta hasta un 84,7% en ese mismo benchmark. Y el dato que sostiene la promesa de portabilidad: el harness ya evolucionado, congelado y movido sin reentrenar a otro benchmark (SWE-bench Verified) mantiene su ventaja gastando un 12% menos de tokens que el de partida, y aplicado a tres familias de modelos distintas aporta mejoras de entre 5,1 y 10,1 puntos. Eso sugiere que lo que el harness aprende no es a aprobar un examen concreto, sino algo más general sobre cómo trabajar.
Una parte que conviene destacar es cómo evitan que el sistema haga trampas. Un agente que puede modificar su propio harness tiene un atajo evidente: desactivar el verificador, cambiar el modelo por uno mejor o subir el presupuesto de razonamiento, y atribuirse la mejora. AHE lo bloquea por diseño: el agente que evoluciona solo puede escribir dentro del espacio del harness; el verificador, el trazador y la configuración del modelo son de solo lectura, y el prompt de sistema de partida no se puede borrar. Así, toda mejora medida es atribuible a cambios reales del harness y no a haber aflojado la prueba.
El límite que casi nadie cuenta
Hasta aquí, la versión que cuenta todo el mundo. Pero el propio paper trae un resultado que mucha cobertura se salta, y es el que de verdad importa entender.
El sistema predice razonablemente bien qué va a arreglar cada cambio, pero predice fatal qué va a romper. Medido a lo largo de nueve rondas, la precisión al anticipar arreglos fue del 33,7%; la precisión al anticipar regresiones, del 11,8%. Dicho de otro modo: el agente sabe argumentar hacia delante —"esto debería ayudar"—, pero es malo argumentando en defensa —"esto podría romper aquello". Es el mismo punto ciego que se ve en las revisiones de código con LLMs y en los bucles de autocrítica: optimismo asimétrico. Mientras un agente no sepa razonar en contra de su propio cambio, cualquier bucle de auto-mejora va a pagar un impuesto de regresiones silenciosas.
Hay un segundo hallazgo en la misma línea. Cuando aislaron qué componente aportaba la mejora, el prompt de sistema evolucionado, metido por su cuenta, empeoraba el resultado. Las ganancias venían de las herramientas, el middleware y la memoria. La conclusión práctica va en contra de una intuición muy extendida: el prompt de sistema, que es donde casi todos invertimos el esfuerzo, es la parte menos portable del harness y la que regresiona sola.
La lectura que debemos hacer no es "los harnesses ya se arreglan solos". Es: se pueden mejorar solos si construyes la maquinaria de reversión asumiendo que una fracción de cada ronda son regresiones que el sistema no vio venir. La auto-mejora funciona porque se apoya en evidencia y en rollback, no porque el agente acierte sus predicciones.
No es un paper suelto
AHE no está solo, y eso es lo que lo convierte en una corriente y no en una curiosidad. En junio de 2026 apareció HarnessX (arXiv:2606.14249), del equipo Darwin Agent, que va un paso más allá: trata el harness como un objeto tipado que se puede componer y evolucionar, y cierra el bucle entre harness y modelo, convirtiendo las trazas a la vez en mejoras del harness y en señal de entrenamiento del modelo. Sobre cinco benchmarks (ALFWorld, GAIA, WebShop, τ³-Bench y SWE-bench Verified) reporta una mejora media del 14,5%, con un pico llamativo: en ALFWorld, con un modelo de 9.000 millones de parámetros, la tasa de éxito pasó del 53,0% al 97,0% sin tocar el modelo. Las mayores ganancias aparecen donde el punto de partida es más bajo.
Alrededor hay más trabajo en la misma dirección, con matices distintos. Algunos separan dos cosas que se confunden: que el harness se actualice no garantiza que la actualización beneficie, y resulta que el beneficio no es uniforme —los modelos de gama media son los que más ganan, mientras que en los muy capaces el margen se estrecha—. Otros insisten en que la auto-mejora solo es segura si los cambios son registrados, comprobables y reversibles, y advierten de que aceptar un cambio solo porque no empeora el pass-rate es una vara demasiado baja para cambios de mayor riesgo. El linaje viene de antes, de los métodos que evolucionaban solo el contexto del agente; lo nuevo es haber abierto la edición a todo el harness.
Qué te llevas como dev
No vas a montar un bucle de auto-evolución la semana que viene. Pero hay tres ideas de aquí que se aplican hoy, con o sin agente que las ejecute.
La primera es el patrón del contrato falsable. Cuando cambies —tú, o un agente por ti— un CLAUDE.md, una herramienta o una skill, no te quedes en "esto debería ir mejor". Escribe qué esperas que arregle y qué temes que rompa, y compruébalo después contra casos reales. Es disciplina de ingeniería básica, pero el resultado de AHE le pone un número: la justificación hacia delante es barata y poco fiable; la verificación es lo que sostiene la mejora.
La segunda es dónde poner el esfuerzo. Si el componente que más regresiona por su cuenta es el prompt de sistema, y los que cargan la mejora son las herramientas, el middleware y la memoria, quizá conviene dejar de tratar el prompt como la palanca principal y mirar más a la calidad de tus herramientas y a cómo gestionas el contexto. Esa parte, además, es la que viaja bien entre modelos.
La tercera es de criterio. Un cambio en el harness es un cambio de producto: una mala decisión por defecto afecta a todo lo que cuelga de ese harness. Si algún día delegas parte de esa edición en un agente, trátalo con lo que pedirías a cualquier despliegue: tests de regresión, control de despliegue progresivo y trazabilidad. El campo entero está convergiendo en la misma conclusión: la auto-mejora tiene que apoyarse en evidencia de comportamiento, no en que el cambio suene razonable.
El hilo que conecta los tres artículos es el mismo. El modelo marca el techo; el harness decide cuánto aprovechas de ese techo; y la frontera de 2026 es que ese harness empiece a moverse solo, con cuidado, dentro de raíles que impiden que se engañe a sí mismo. Si te falta la base, está en Qué es un harness en IA; el caso concreto, en Cómo funciona Claude Code por dentro.
Rutas de aprendizaje
