Un agente que predice sus propios cambios mejora más, pero gasta 3,4 veces más tokens: el precio de la autoevolución

Por NeoTeo · 17 de octubre de 2026.

El preprint «Predict Before You Modify: Learning Improvement Dynamics for Self-Evolving Agents» presenta el Improvement Dynamics Model (IDM). Es un programa editable que predice, tarea por tarea, qué efecto tendrá un cambio propuesto en el código de un agente de IA, antes de dar el cambio por bueno. Según los datos del propio estudio, en programación mejora a su base de comparación, pero consume bastantes más tokens.

El IDM parte de HyperAgents, un esquema en el que un agente ejecuta tareas y un metaagente modifica el programa de ese agente y también el suyo propio. Para predecir, el IDM usa el historial de pruebas, el agente de base, sus resultados y el cambio de código propuesto (el «diff», la diferencia entre versiones). Invoca un modelo de lenguaje congelado: lo que evoluciona es el programa del agente, no se reentrena el modelo.

La predicción no actúa como barrera. Si el pronóstico agregado aconseja revisar una propuesta, el sistema puede pedir como máximo una revisión adicional. Después vuelve a predecir y evalúa el agente resultante aunque el pronóstico siga siendo desfavorable. El propio IDM también puede mutar: cada cinco generaciones el metaagente puede proponer cambios al predictor, que solo se adoptan si reducen la pérdida de predicción por tarea sin elevar el error cuadrático medio centrado.

Los experimentos cubren cuatro ámbitos: programación multilingüe (Polyglot), revisión de artículos, diseño de recompensas para robótica simulada y calificación de problemas matemáticos de nivel olímpico. Cada método hizo cinco ejecuciones de 40 generaciones, con agentes iniciales, modelos y protocolos compartidos.

En programación, la AUBC (área bajo la curva de presupuesto, que resume el rendimiento a lo largo de las generaciones) tuvo una mediana de 0,306 con Selective IDM, frente a 0,210 con HyperAgents. En 166 tareas reservadas para la prueba, la ganancia mediana en tasa de resolución sobre el agente inicial (que partía del 16,27%) fue de 13,25 puntos porcentuales con Selective IDM y de 5,42 con HyperAgents.

El coste: en las ejecuciones completas de programación, Selective IDM usó una media de 170,22 millones de tokens, frente a 49,45 millones de HyperAgents. Esa cifra incluye la evolución de los agentes, la evaluación, las predicciones, las actualizaciones del IDM y su validación. Con un presupuesto igualado de 44,21 millones de tokens, el preprint informa de una AUBC mediana un 10,9% mayor para Selective IDM. La ventaja existe, pero es mucho más modesta que en la comparación sin límites.

Fuera de programación los resultados son más contenidos. En revisión de artículos, la AUBC mediana fue un 5,9% mayor, y un 3,9% mayor en el objetivo conjunto con robótica. Un IDM desarrollado en esos dos ámbitos y trasladado a calificación matemática logró una precisión mediana 4 puntos mayor que Selective IDM y 8 puntos mayor que HyperAgents. El IDM final redujo entre un 8,7% y un 24,4% la pérdida de predicción por tarea frente al predictor inicial.

Nuestra lectura. La idea de fondo es sensata: si cada cambio en un agente se evalúa ejecutándolo, y eso es caro, aprender a anticipar cuáles valen la pena es un camino natural. Pero el resultado más honesto del preprint es el que menos titulares dará: predecir no sale gratis. El 3,4 por uno en tokens indica que la autoevolución sigue limitada por presupuesto de cómputo, y que la mejora real, medida con presupuesto igualado, es de un 10,9%, no de un 45%. Conviene fijarse en esa comparación, no en la AUBC bruta.

Hay además un matiz de método. Las pruebas se hicieron con tareas de referencia, incluida robótica simulada. Los propios autores advierten de que esto no basta para justificar sustituir el juicio humano ni desplegar el sistema sin salvaguardas. Y el recuento de tokens no equivale al coste total de computación, ni a la energía, ni al dinero. En general, los agentes que se reescriben a sí mismos plantean una pregunta de gobernanza que el rendimiento no responde: si el código que se ejecuta cambia solo, quién verifica qué cambió y por qué.

Aun así, la dirección importa para el largo plazo. Si los agentes aprenden a mejorarse con menos ensayo y error, el coste de conseguir software y automatización competentes bajará, y eso alimenta la abundancia que defendemos. A corto plazo, sin embargo, la ventaja es de quien pueda pagar 170 millones de tokens por ejecución. Y en cualquier mejora autónoma, lo escaso seguirá siendo la verificación.