Composer autoinstall: cómo las versiones antiguas ayudan a entrenar las nuevas

Cursor presentó Composer autoinstall — un sistema que utiliza versiones anteriores del modelo Composer para preparar automáticamente entornos para el entrenamiento con aprendizaje por refuerzo. Durante el desarrollo de Composer 2, el equipo utilizó la versión 1.5 para gestionar este proceso. La idea se basa en la experiencia con Cursor cloud agents, pero se aplica al entrenamiento RL de los propios modelos.

Por qué los entornos rotos matan el aprendizaje

El entrenamiento RL requiere entornos funcionales. Si un proyecto no se compila, las dependencias no se instalan o la configuración se niega a ejecutarse, el modelo desperdicia tokens depurando en lugar de aprender a resolver problemas reales de programación. En los peores casos, un entorno roto hace que la tarea sea completamente irresoluble — el modelo no recibe ninguna señal de recompensa y simplemente desperdicia computación. Esto es costoso e ineficiente.

Proceso de bootstrap de dos etapas

Autoinstall funciona mediante un esquema simple pero ingenioso. Etapa 1: El agente explorador determina el objetivo. Se le da a la primera versión del modelo (Composer 1.

5) un repositorio en estado fijo. Debe proponer 10 comandos y una descripción de alto nivel de su salida si el entorno está configurado correctamente. El modelo estudia README y Makefile, prueba comandos específicos del idioma (`uv`, `npm install`, `clippy`, `pytest`), y explora la estructura del proyecto.

El resultado es una lista de comandos de configuración, pruebas y scripts de ejecución. Etapa 2: El segundo agente lo implementa. La segunda versión (Composer 2) recibe el estado inicial del proyecto más tres comandos objetivo seleccionados de los diez propuestos.

Su tarea es llamar a herramientas (búsqueda, compilación, linter), explorar el código y configurar el entorno para que los tres comandos se ejecuten y su salida coincida con la descripción de la etapa 1. Si no coincide — el proceso se repite. Después de cinco intentos fallidos, el entorno se rechaza.

• El modelo explora el código y ejecuta herramientas de búsqueda
• Instala dependencias a través del gestor de paquetes
• Realiza configuración (configuración, variables de entorno)
• Verifica la salida contra la descripción objetivo
• Repite hasta el éxito o límite de intentos

Cómo el modelo supera componentes faltantes

Composer está dispuesto a llegar lejos para lograr un entorno funcional. El modelo simula archivos faltantes, crea stubs para imágenes, incluso tablas falsas en bases de datos. Si un proyecto necesita servicios en la nube como S3 o contenedores sidecar, Composer crea sus equivalentes — configuraciones MinIO para S3, contenedores Docker para servicios. Para procesos de larga duración, el sistema genera un script de inicio que inicia estos componentes al principio de la sesión RL.

"Los modelos de lenguaje modernos irán a grandes esfuerzos para configurar con éxito un entorno, simular dependencias y probar que la configuración funciona", dice el equipo

Cursor.

Lo que esto significa para el futuro

La idea es simple, pero tiene un significado enorme. Composer utiliza su propia versión anterior como ayuda para preparar la base funcional para la nueva versión. Esto no solo ahorra cálculo, sino que también mejora la señal para el aprendizaje por refuerzo. Cada nueva versión del modelo ahora se basa en los hombros de sus predecesores. Es lógico asumir que en el futuro, este bootstrapping se convertirá en estándar en el entrenamiento de grandes modelos de lenguaje.