Estamos experimentando executar agentes de programação de forma autônoma por semanas.

Nosso objetivo é entender até onde podemos escalar a fronteira da programação agêntica em projetos que normalmente levam meses para equipes humanas concluírem.

Este post descreve o que aprendemos ao executar centenas de agentes em paralelo em um único projeto, coordenar seu trabalho e vê-los escrever mais de um milhão de linhas de código e trilhões de tokens.

#Os limites de um único agente

Os agentes de hoje funcionam bem para tarefas específicas, mas são lentos em projetos complexos. O próximo passo natural é executar vários agentes em paralelo, mas descobrir como coordená-los é difícil.

Nosso primeiro instinto foi achar que planejar com antecedência seria rígido demais. O percurso em um projeto grande é incerto, e a divisão ideal do trabalho não é óbvia no início. Começamos com uma coordenação dinâmica, em que os agentes decidem o que fazer com base no que os outros estão fazendo atualmente.

#Aprendendo a coordenar

Nossa abordagem inicial colocava todos os agentes no mesmo nível e permitia que se autocoordenassem por meio de um arquivo compartilhado. Cada agente verificava o que os outros estavam fazendo, assumia uma tarefa e atualizava seu status. Para evitar que dois agentes pegassem a mesma tarefa, usamos um mecanismo de bloqueio.

Isso falhou de maneiras interessantes:

1. Os agentes mantinham bloqueios por tempo demais ou simplesmente se esqueciam de liberá-los. Mesmo quando o bloqueio funcionava corretamente, ele se tornava um gargalo. Vinte agentes acabavam limitados à taxa de processamento efetiva de dois ou três, com a maior parte do tempo sendo gasta esperando.

2. O sistema era frágil: os agentes podiam falhar enquanto mantinham bloqueios, tentar adquirir bloqueios que já mantinham ou atualizar o arquivo de coordenação sem sequer adquirir o bloqueio.

Tentamos substituir os bloqueios por controle otimista de concorrência. Os agentes podiam ler o estado livremente, mas as escritas falhavam se o estado tivesse mudado desde a última leitura. Isso era mais simples e robusto, mas ainda havia problemas mais profundos.

Sem hierarquia, os agentes se tornavam avessos ao risco. Eles evitavam tarefas difíceis e faziam pequenas alterações seguras em vez disso. Nenhum agente assumia a responsabilidade por problemas difíceis ou pela implementação de ponta a ponta. Isso fazia com que o trabalho se arrastasse por longos períodos sem progresso.

#Planejadores e Workers

Nossa próxima abordagem foi separar os papéis. Em vez de uma estrutura plana em que todo agente faz tudo, criamos um pipeline com responsabilidades distintas.

• Planejadores exploram continuamente a base de código e criam tarefas. Eles podem criar subplanejadores para áreas específicas, tornando o próprio planejamento paralelo e recursivo.

• Workers pegam tarefas e se concentram totalmente em concluí-las. Eles não se coordenam com outros workers nem se preocupam com o panorama geral. Apenas trabalham na tarefa atribuída até que ela esteja pronta e, então, fazem push das alterações.

Ao final de cada ciclo, um agente avaliador determinava se era para continuar, e então a próxima iteração começava do zero. Isso resolveu a maior parte dos nossos problemas de coordenação e nos permitiu escalar para projetos muito grandes sem que nenhum agente ficasse com visão de túnel.

#Rodando por semanas

Para testar esse sistema, definimos uma meta ambiciosa: desenvolver um navegador web do zero. Os agentes ficaram em execução por quase uma semana, escrevendo mais de 1 milhão de linhas de código em 1.000 arquivos. Você pode explorar o código-fonte no GitHub.

Apesar do tamanho da base de código, novos agentes ainda conseguem entendê-la e fazer progresso significativo. Centenas de workers executam simultaneamente, fazendo push para a mesma branch com conflitos mínimos.

Embora possa parecer apenas uma captura de tela simples, desenvolver um navegador do zero é extremamente difícil.

Outro experimento foi fazer uma migração direta de Solid para React na base de código do Cursor. Levou mais de três semanas, com +266K/-193K edições. Ainda precisa de uma revisão cuidadosa, mas estava passando na nossa CI e nas verificações iniciais.

Outro experimento foi melhorar um produto em desenvolvimento. Um agente de longa duração tornou a renderização de vídeo 25x mais rápida com uma versão eficiente em Rust. Ele também adicionou suporte a zoom e pan suaves, com transições de mola naturais e motion blur, seguindo o cursor. Esse código foi integrado e entrará em produção em breve.

Temos alguns outros exemplos interessantes ainda em execução:

• Java LSP: 7.4K commits, 550K LoC
• Windows 7 emulator: 14.6K commits, 1.2M LoC
• Excel: 12K commits, 1.6M LoC

#O que aprendemos

Já executamos trilhões de tokens nesses agentes com um único objetivo. O sistema não é perfeitamente eficiente, mas é muito mais eficaz do que esperávamos.

A escolha do modelo faz diferença em tarefas de longa duração. Descobrimos que os modelos GPT-5.2 são muito melhores em trabalho autônomo prolongado: seguir instruções, manter o foco, evitar desvios e implementar coisas com precisão e por completo.

O Opus 4.5 tende a parar antes e a pegar atalhos quando isso é conveniente, devolvendo o controle rapidamente. Também descobrimos que modelos diferentes se destacam em funções diferentes. O GPT-5.2 planeja melhor do que o GPT-5.1-Codex, embora este último seja treinado especificamente para programação. Agora usamos o modelo mais adequado para cada função, em vez de um modelo universal.

Muitas das nossas melhorias vieram de remover complexidade, e não de adicionar mais. Inicialmente, criamos uma função de integrador para controle de qualidade e resolução de conflitos, mas descobrimos que ela criava mais gargalos do que resolvia. Os workers já eram capazes de lidar com conflitos por conta própria.

O melhor sistema muitas vezes é mais simples do que você imagina. Inicialmente, tentamos modelar sistemas com base em computação distribuída e design organizacional. No entanto, nem todos funcionam para agentes.

A quantidade certa de estrutura está em algum ponto no meio-termo. Estrutura de menos faz com que os agentes entrem em conflito, dupliquem trabalho e percam o foco. Estrutura demais cria fragilidade.

Uma parte surpreendente do comportamento do sistema depende de como instruímos os agentes por meio de prompts. Fazer com que eles se coordenem bem, evitem comportamentos patológicos e mantenham o foco por longos períodos exigiu muita experimentação. A infraestrutura e os modelos importam, mas os prompts importam mais.

#O que vem a seguir

A coordenação multiagente continua sendo um problema difícil. Nosso sistema atual funciona, mas está longe do ideal. Os planejadores devem entrar em ação quando suas tarefas forem concluídas para planejar a próxima etapa. Os agentes ocasionalmente ficam em execução por tempo demais. Ainda precisamos de recomeços periódicos para combater a deriva e a visão de túnel.

Mas a questão central — se podemos escalar a programação autônoma colocando mais agentes para atuar em um problema — tem uma resposta mais otimista do que esperávamos. Centenas de agentes podem trabalhar juntos em uma única base de código por semanas, fazendo avanços reais em projetos ambiciosos.

As técnicas que estamos desenvolvendo aqui acabarão moldando as capacidades do Agente do Cursor. Se você tem interesse em trabalhar nos problemas mais difíceis do desenvolvimento de software assistido por IA, adoraríamos ouvir de você em hiring@cursor.com.