El problema de fondo: mejorar sin romper nada
Un agente de IA que reescribe su propio código se parece a un desarrollador que edita el archivo equivocado a las tres de la mañana. Cada cambio que promete una mejora puede introducir un fallo que antes no existía, y demostrar que la modificación funciona es un trabajo distinto de proponerla.
Un equipo de investigadores de la Universidad de Virginia, Microsoft Research y la Universidad de Tsinghua propone una solución a ese cuello de botella: darle al agente una oportunidad extra antes de poner a prueba sus cambios. La idea, presentada en un estudio disponible como prepublicación en arXiv, es que un componente intente predecir si una modificación empeorará los resultados y, cuando detecta ese riesgo, habilite una revisión adicional.
No se trata de reentrenar el modelo. Se trata de mejorar los programas y las instrucciones con los que trabaja. El objetivo no es eliminar todos los errores, sino orientar mejor los intentos de mejora.
Leíste lo que hace la IA. ¿Y en tu negocio?
En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.
👥 Probar 7 díasQué es HyperAgents y cómo se automejora
El punto de partida es HyperAgents, un sistema con dos agentes que trabajan en tándem. El primero resuelve tareas; el segundo busca maneras de mejorar el funcionamiento de ambos, modificando el código y las instrucciones que los dos utilizan. Ese segundo agente también puede editar su propio software, y el sistema guarda los resultados de versiones anteriores para orientar las modificaciones futuras.
El trabajo base, Hyperagents, está disponible en arXiv y describe agentes autorreferenciales que integran un agente de tarea y un agente meta dentro de un único programa editable. Según el resumen publicado en arXiv, el procedimiento de modificación meta es a su vez editable, lo que permite lo que los autores llaman automejora metacognitiva: no solo cambia el comportamiento al resolver tareas, sino también el mecanismo que genera las mejoras futuras.
No es el primer intento de conseguir algo parecido. En 2025, Sakana AI presentó Darwin Gödel Machine, un proyecto que ya exploraba cómo un agente podía mejorar mediante cambios en su propio código.
Cómo funciona el Improvement Dynamics Model (IDM)
Para decidir cuándo conviene revisar una modificación, los investigadores incorporaron el Improvement Dynamics Model (IDM). Este componente analiza el cambio propuesto y usa la experiencia acumulada para estimar sus posibles consecuencias.
La distinción clave es que el IDM no se limita a decir «mejor» o «peor». Puede diferenciar entre una tarea que terminaría con una respuesta incorrecta y otra que ni siquiera llegaría a completarse. Si prevé un empeoramiento, permite una revisión adicional antes de evaluar la versión resultante.
Un ejemplo concreto ilustra el mecanismo: durante una prueba, unas instrucciones quedaron fuera de las comillas correspondientes y provocaron un error de sintaxis. El agente había detectado el problema, pero agotó sus llamadas a herramientas antes de repararlo. El predictor anticipó que las tareas probablemente quedarían incompletas y motivó otra revisión. Tras corregir el código, la nueva versión consiguió resolver 11 tareas. El sistema realiza la evaluación final aunque la última predicción sea desfavorable.
Los números: del 16% a casi el 30%
Los investigadores no se quedaron en el ejemplo de las comillas. Pusieron a prueba los agentes con 166 tareas de programación que no habían utilizado durante el proceso de mejora ni para seleccionar las versiones. Para dar una tarea por resuelta, el sistema debía proponer una modificación de código que superara las pruebas correspondientes.
Los resultados, obtenidos a partir de cinco ejecuciones por configuración:
- El agente inicial alcanzó una tasa de éxito de aproximadamente el 16%.
- Las versiones seleccionadas de HyperAgents, sin el nuevo predictor, lograron una mediana cercana al 22%.
- Con el método de predicción, esa cifra llegó a casi el 30%.
Hay una segunda capacidad que merece atención: el sistema encargado de anticipar los resultados también puede perfeccionarse. Cada cinco rondas, el agente responsable de las modificaciones propone cambios en su funcionamiento, que solo se incorporan si superan una comprobación posterior.
Los investigadores también quisieron saber si esa experiencia podía aprovecharse en tareas diferentes. Tras perfeccionar el predictor con trabajos de predicción de aceptación de artículos científicos y diseño de recompensas para robots simulados, lo utilizaron para orientar la mejora de nuevos agentes encargados de calificar soluciones matemáticas. En 100 ejercicios reservados para la evaluación final, estos agentes coincidieron exactamente con las calificaciones de expertos en una mediana del 55% de los casos, frente al 51% con un predictor inicial y el 47% de HyperAgents.
El coste oculto: 170 millones de tokens frente a 49 millones
Mejor rendimiento no significa menor coste, y este es el dato que más debería interesar a quien paga la factura de cómputo.
En las pruebas de programación, el nuevo método necesitó una media estimada de 170 millones de tokens para completar 40 rondas, mientras que HyperAgents consumió unos 49 millones. Hablamos de las unidades de texto que procesan o generan los modelos de IA.
La diferencia es considerable, aunque no cuenta toda la historia. Cuando los investigadores igualaron el presupuesto de tokens de ambos sistemas, el método con predicciones siguió obteniendo mejores resultados a lo largo del proceso, con una ventaja del 10,9% en una medida del rendimiento acumulado. El estudio, eso sí, no ofrece una comparación completa del coste computacional total.
Vale la pena mirar el contexto del sector. Según Crypto Briefing, el framework SIFT de MIT y Sakana AI alcanzó un 35,1% en el benchmark Polyglot tras 30 pasos de expansión, frente al 30,7% que logró el Darwin Gödel Machine tras 80 nodos. Una configuración basada en Qwen3-Coder-30B completó toda su búsqueda en 224 horas de CPU con aproximadamente US$34 en costes de API, cerca de una décima parte de los recursos que consumió DGM, según ese mismo medio. La carrera por abaratar la automejora ya está en marcha.
¿Qué significa esto para tu startup?
Si estás construyendo producto con agentes de IA, este paper no te pide que implementes automejora mañana. Te da tres señales útiles.
Primero: el coste de la mejora es el nuevo campo de batalla. Un salto del 16% al 30% en tasa de éxito suena excelente hasta que ves que multiplica por más de tres el consumo de tokens. Antes de adoptar cualquier bucle de automejora, mide el coste por tarea resuelta, no solo la tasa de éxito. Un agente que acierta más pero cuesta 3,5 veces más puede ser peor negocio que uno que acierta menos.
Segundo: los agentes que se revisan a sí mismos son más fiables que los que solo se prueban. La lección transferible es simple y no requiere investigación propia: añade una capa de verificación previa a la ejecución. Si tu pipeline de agentes puede estimar si un cambio va a fallar antes de gastar la llamada al modelo, ahorras tanto errores como dinero. Empieza por el caso más barato de detectar: instrucciones mal formadas, JSON inválido, parámetros fuera de rango.
Tercero: la transferencia entre dominios es real, pero limitada. El paper muestra que un predictor entrenado en un dominio puede orientar la mejora en otro. Eso sugiere que invertir en infraestructura de evaluación —no solo en el agente— tiene retorno acumulable. Si tu equipo guarda histórico de versiones, resultados y errores, ya tiene la materia prima para construir ese predictor.
Lo que todavía queda por demostrar
Una cosa es superar pruebas de programación y otra muy distinta confiar a un sistema las modificaciones de un software que se usa a diario. Los experimentos de esta investigación, disponible como prepublicación, no permiten asegurar que el método funcione igual en proyectos reales ni que elimine la necesidad de supervisión humana. Tampoco demuestran que estos agentes puedan sustituir a los profesionales encargados de desarrollar o evaluar programas.
Lo que sí muestran es que anticipar los posibles resultados ayuda a orientar las modificaciones. Volvemos así al dilema inicial desde otra perspectiva: para mejorar su propio funcionamiento, estos agentes necesitan algo más que la capacidad de cambiar instrucciones y código. Necesitan saber cuándo no deberían hacerlo.
Para un founder, la lectura práctica es prudente: la automejora de agentes avanza rápido en el laboratorio, pero el despliegue en producción sigue exigiendo revisión humana, métricas de coste por resultado y una capa de verificación que atrape el error antes de que llegue al usuario. Ese es, hoy, el trabajo que sí puedes hacer.
Fuentes
- Xataka: Los agentes de IA están aprendiendo a mejorar su propio software
- arXiv: Hyperagents (2603.19461)
- Crypto Briefing: MIT and Sakana AI’s SIFT framework cuts the cost of judging self-improving coding agents
Leíste lo que hace la IA. ¿Y en tu negocio?
En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.
👥 Probar 7 días
