Composer autoinstall: como versões antigas ajudam a treinar as novas

O Cursor apresentou o Composer autoinstall — um sistema que usa versões anteriores do modelo Composer para preparar automaticamente ambientes para treinamento com aprendizado por reforço. Durante o desenvolvimento do Composer 2, a equipe usou a versão 1.5 para gerenciar esse processo. A ideia é baseada na experiência com Cursor cloud agents, mas aplicada ao treinamento RL dos próprios modelos.

Por que ambientes quebrados matam o treinamento

O treinamento RL requer ambientes funcionais. Se um projeto não compilar, as dependências não se instalarem ou a configuração se recusar a executar, o modelo desperdiça tokens depurando em vez de aprender a resolver problemas reais de programação. Nos piores casos, um ambiente quebrado torna a tarefa completamente insolúvel — o modelo não recebe nenhum sinal de recompensa e simplesmente desperdiça computação. É caro e ineficiente.

Processo de bootstrap de dois estágios

O Autoinstall funciona por meio de um esquema simples mas genial. Estágio 1: Agente de reconhecimento determina o objetivo. A primeira versão do modelo (Composer 1.

5) recebe um repositório em estado fixo. Deve propor 10 comandos e uma descrição de alto nível de sua saída se o ambiente estiver configurado corretamente. O modelo estuda README e Makefile, tenta comandos específicos de linguagem (`uv`, `npm install`, `clippy`, `pytest`), e explora a estrutura do projeto.

O resultado é uma lista de comandos de configuração, testes e scripts de execução. Estágio 2: O segundo agente o implementa. A segunda versão (Composer 2) recebe o estado inicial do projeto mais três comandos alvo selecionados dos dez propostos.

Sua tarefa é chamar ferramentas (busca, compilação, linter), explorar o código e configurar o ambiente para que todos os três comandos sejam executados e sua saída corresponda à descrição do estágio 1. Se não corresponder — o processo se repete. Após cinco tentativas falhadas, o ambiente é rejeitado.

• O modelo explora o código e executa ferramentas de busca
• Instala dependências através do gerenciador de pacotes
• Realiza configuração (configuração, variáveis de ambiente)
• Verifica a saída em relação à descrição do alvo
• Repete até o sucesso ou limite de tentativas

Como o modelo supera componentes ausentes

O Composer está disposto a ir longe para alcançar um ambiente funcionante. O modelo simula arquivos faltantes, cria stubs para imagens, até tabelas falsas em bancos de dados. Se um projeto precisar de serviços em nuvem como S3 ou contêineres sidecar, o Composer cria seus equivalentes — configs MinIO para S3, contêineres Docker para serviços. Para processos de longa duração, o sistema gera um script de inicialização que inicia esses componentes no início da sessão RL.

"Modelos de linguagem modernos farão grandes esforços para configurar com sucesso um ambiente, simular dependências e testar que a configuração funciona", diz a equipe

Cursor.

O que isso significa para o futuro

A ideia é simples, mas tem um significado enorme. Composer usa sua própria versão mais antiga como auxiliar para preparar a base funcional para a nova versão. Isso não apenas economiza cálculo, mas também melhora o sinal para aprendizado por reforço. Cada nova versão do modelo agora se baseia nos ombros de seus predecessores. É lógico assumir que no futuro, esse bootstrapping se tornará padrão no treinamento de grandes modelos de linguagem.