Recursive presenta un modelo de pesos abiertos con cerca de 40.000 millones de parámetros. Su desarrollo mediante Eureka Machine explora cómo automatizar la investigación en IA, pero no demuestra una mejora autónoma e ilimitada.
Una IA que ayuda a construir otra IA
Flint, presentado el 21 de octubre de 2026, es un modelo de Recursive orientado a tareas de programación. Su interés está tanto en sus capacidades como en el proceso utilizado para desarrollarlo.
Según NVIDIA, la compañía empleó Eureka Machine, un sistema de investigación automatizada que propone ideas, las implementa, ejecuta experimentos y utiliza los resultados para decidir qué probar después.
Esta distinción es fundamental: Flint es el modelo resultante; Eureka Machine es el sistema empleado para investigar mejoras durante su desarrollo.
Qué significa aquí la auto-mejora recursiva
La idea de la auto-mejora recursiva consiste en que las mejoras de un sistema aumenten, a su vez, su capacidad para producir nuevas mejoras.
La analogía del taller resulta útil: fabricar una herramienta mejor puede facilitar la construcción de la siguiente. Pero para demostrar ese proceso no basta con que una máquina produzca una herramienta una vez.
También habría que comprobar que las mejoras se acumulan, que funcionan fuera de las pruebas utilizadas para seleccionarlas y que el proceso puede repetirse de forma fiable.
Por eso, automatizar experimentos de investigación no equivale automáticamente a demostrar una inteligencia que se perfecciona sin límites.
Lo que cuenta Recursive y lo que todavía es un objetivo
En declaraciones recogidas por WIRED, Richard Socher, cofundador y director ejecutivo de Recursive, atribuye a la IA buena parte del trabajo de desarrollo de Flint.
El reportaje presenta la auto-mejora recursiva completa de Eureka Machine como una meta de la empresa, con supervisión humana. No demuestra que Flint modifique sus propios pesos y vuelva a entrenarse de forma autónoma mientras atiende peticiones.
Un modelo de pesos abiertos para agentes de programación
La ficha oficial describe Flint como un modelo de mezcla de expertos, o MoE, con 39.800 millones de parámetros totales y aproximadamente 2.500 millones activos por token.
Está diseñado para investigar bases de código, corregir errores, implementar funciones y escribir pruebas. Sus pesos se distribuyen bajo licencia Apache 2.0.
Hablar de pesos abiertos es más preciso que dar por hecho que todos los datos y procedimientos de entrenamiento están disponibles para reproducir el modelo.
Eficiencia: una mejora concreta, no una promesa universal
NVIDIA informa de que Eureka Machine produjo código especializado que aumentó un 55% la velocidad de generación de Flint en RTX Spark sin modificar los pesos del modelo.
Es un resultado referido a un equipo y una optimización concretos. No demuestra por sí solo una reducción equivalente del consumo energético ni del coste total de desarrollar software.
También ilustra que mejorar un sistema de IA puede consistir en optimizar el software que lo ejecuta, sin cambiar lo que el modelo ha aprendido.
Cómo interpretar sus resultados
Recursive publica puntuaciones en pruebas de programación, pero advierte de que las configuraciones de evaluación varían entre fuentes. Las comparaciones requieren revisar las condiciones de cada prueba.
La ficha también distingue entre la versión BF16 y variantes cuantizadas para diferentes entornos. Los requisitos y el rendimiento dependen de la versión y del sistema de ejecución.
Por tanto, tener cerca de 40.000 millones de parámetros no significa que pueda ejecutarse con las mismas prestaciones en cualquier ordenador o servidor.
Qué puede aportar a un equipo pequeño
La posibilidad de disponer de modelos para programación amplía las opciones de quienes quieren experimentar con asistentes adaptados a sus proyectos.
Para una pequeña empresa, una aplicación útil podría ser preparar cambios en una herramienta interna o generar pruebas para una función existente. El valor dependerá de cuánto trabajo correcto produzca y del tiempo necesario para revisarlo.
Generar más código no siempre significa terminar antes. Si los cambios introducen errores difíciles de detectar, parte del ahorro inicial puede desaparecer durante la revisión.
La seguridad no queda garantizada por las pruebas
La propia documentación de Flint advierte de que puede generar código defectuoso, contenido incorrecto y llamadas a herramientas inadecuadas. Recomienda revisar los cambios importantes y limitar los permisos de las aplicaciones que lo utilicen.
En un ciclo automatizado, la calidad de la evaluación resulta especialmente importante: una mejora aparente puede responder a una prueba incompleta.
Superar comprobaciones automáticas aporta evidencia sobre lo evaluado, pero no garantiza la ausencia de fallos en otras situaciones.
La lectura de SombraRadio
Flint ofrece un caso concreto para observar cómo la IA empieza a participar en más etapas de la construcción de otros modelos.
El interés está en comprobar cuánto acelera la investigación, qué mejoras produce y cuáles pueden reproducirse. Dar por resuelta la auto-mejora recursiva ocultaría precisamente esas preguntas.
Tampoco permite asegurar qué ocurrirá con el empleo en programación. La automatización puede transformar tareas y responsabilidades, pero un lanzamiento no determina por sí solo el futuro de una profesión.
La evidencia más útil será la que muestre mejoras sostenidas en proyectos reales, con costes medidos y resultados verificables.
Fuentes y referencias
- Recursive: ficha oficial de Flint, licencia, evaluaciones y limitaciones
- NVIDIA: presentación de Flint y optimización mediante Eureka Machine
- WIRED: reportaje sobre Flint y la estrategia de auto-mejora de Recursive
Sombra Radio · Apoyo de lectores
Ayuda a mantener viva Sombra Radio
Tu aportación voluntaria nos ayuda a seguir publicando sobre IA. Puedes apoyarnos desde 1 € al mes.
