Temos feito experimentos com agentes de programação sendo executados de forma autônoma por semanas.

Nosso objetivo é entender até onde podemos levar a fronteira da programação orientada a agentes em projetos que normalmente levam meses para equipes humanas concluírem.

Este artigo descreve o que aprendemos ao executar centenas de agentes simultâneos em um único projeto, coordenando seu trabalho e observando-os 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 é desafiador.

Nossa primeira intuição foi que planejar com antecedência seria rígido demais. O percurso em um projeto grande é ambíguo, e a divisão ideal do trabalho não é óbvia no início. Começamos com coordenação dinâmica, em que os agentes decidem o que fazer com base no que os outros estão fazendo no momento.

#Aprendendo a coordenar

Nossa abordagem inicial dava o mesmo nível de importância aos agentes e os deixava se coordenar sozinhos 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. Agentes mantinham bloqueios por tempo demais ou esqueciam de liberá-los completamente. Mesmo quando o bloqueio funcionava corretamente, ele se tornava um gargalo. Vinte agentes acabavam com uma vazão efetiva equivalente à de dois ou três, com a maior parte do tempo sendo gasta esperando.

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

Tentamos substituir bloqueios por controle de concorrência otimista. Agentes podiam ler o estado livremente, mas gravações falhavam se o estado tivesse mudado desde a última leitura. Isso era mais simples e mais robusto, mas ainda havia problemas mais profundos.

Sem hierarquia, os agentes se tornavam avessos ao risco. Eles evitavam tarefas difíceis e faziam mudanças pequenas e seguras. Nenhum agente assumia responsabilidade por problemas difíceis ou pela implementação ponta a ponta. Isso levava a um trabalho girando em falso por longos períodos de tempo, sem progresso.

#Planejadores e trabalhadores

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

• Planejadores exploram continuamente o codebase e criam tarefas. Eles podem gerar sub-planejadores para áreas específicas, tornando o próprio planejamento paralelo e recursivo.

• Trabalhadores assumem tarefas e se concentram totalmente em concluí-las. Eles não se coordenam com outros trabalhadores nem se preocupam com o panorama geral. Eles simplesmente trabalham intensamente na tarefa designada até terminá-la e então enviam suas alterações.

Ao final de cada ciclo, um agente avaliador determinava se deveria continuar; então a próxima iteração recomeçava do início. 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 excessivamente limitada.

#Em execução por semanas

Para testar o sistema, nós o direcionamos a uma meta ambiciosa: construir 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 codebase, novos agentes ainda conseguem entendê-la e fazer progresso significativo. Centenas de workers rodam em paralelo, fazendo push para o mesmo branch com conflitos mínimos.

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

Outro experimento foi fazer uma migração in-place de Solid para React na codebase do Cursor. Levou mais de três semanas, com +266K/-193K edições. Ainda precisa de uma revisão cuidadosa, mas já estava passando pelo nosso CI e pelas verificações iniciais.

Outro experimento foi melhorar um produto que ainda será lançado. 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 com efeito de mola natural e desfoques de movimento, seguindo o cursor. Esse código já foi mergeado e entrará em produção em breve.

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

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

#O que aprendemos

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

A escolha do modelo é importante para tarefas extremamente longas. Descobrimos que os modelos GPT-5.2 são muito melhores em trabalho autônomo prolongado: seguir instruções, manter o foco, evitar dispersão e implementar as coisas de forma precisa e completa.

Opus 4.5 tende a parar mais cedo e a pegar atalhos quando conveniente, devolvendo o controle rapidamente. Também descobrimos que modelos diferentes se destacam em funções diferentes. GPT-5.2 é um planejador melhor que 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, não de adicioná-la. Inicialmente criamos uma função de integrador para controle de qualidade e resolução de conflitos, mas vimos que ela criava mais gargalos do que resolvia. Os workers já eram capazes de lidar com conflitos por conta própria.

O melhor sistema costuma ser mais simples do que você imagina. Inicialmente tentamos modelar sistemas de computação distribuída e de desenho organizacional. Porém, nem todos funcionam para agentes.

A quantidade certa de estrutura está em algum ponto intermediário. Com estrutura de menos, os agentes entram em conflito, duplicam trabalho e se desviam. Com estrutura demais, o sistema fica frágil.

Uma parte surpreendentemente grande do comportamento do sistema se resume a como elaboramos os prompts para os agentes. Fazer com que se coordenem bem, evitem comportamentos patológicos e mantenham o foco por longos períodos exigiu muita experimentação. O harness e os modelos importam, mas os prompts importam mais.

#O que vem a seguir

A coordenação entre múltiplos agentes continua sendo um problema difícil. Nosso sistema atual funciona, mas estamos longe do ideal. Os planejadores deveriam ser ativados assim que suas tarefas forem concluídas para planejar o próximo passo. Às vezes, os agentes acabam rodando por tempo demais. Ainda precisamos de reinicializações periódicas para combater desvios e visão em túnel.

Mas a questão central — se conseguimos escalar a codificação autônoma simplesmente adicionando mais agentes a 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 progresso real em projetos ambiciosos.

As técnicas que estamos desenvolvendo aqui eventualmente vão orientar as capacidades de agentes do Cursor. Se você tiver interesse em trabalhar nos problemas mais difíceis em desenvolvimento de software com IA, gostaríamos muito de falar com você em hiring@cursor.com.