Escalando a codificação autônoma de longa duração

• A Cursor experimentou se agentes autônomos de codificação podem ser executados em paralelo por semanas para concluir projetos de grande escala
• No início, usou uma estrutura de colaboração dinâmica, mas surgiram gargalos devido a conflitos de lock e duplicação de trabalho
• Depois, separou os papéis em Planner e Worker, melhorando bastante o paralelismo e a eficiência
• Com essa estrutura, implementou um navegador web do zero, com centenas de agentes escrevendo mais de 1 milhão de linhas de código
• O experimento mostrou que uma estrutura simples e um bom desenho de prompts são a chave para escalar a codificação autônoma de longo prazo

---

Limites de um agente único

• Os agentes de codificação únicos atuais são eficientes para tarefas simples, mas lentos em projetos complexos
  • Executar vários agentes em paralelo é um caminho natural para escalar, mas a coordenação de tarefas é difícil
• No início, foi tentada uma forma de colaboração dinâmica sem planejamento prévio
  • Uma estrutura em que cada agente observa o estado dos outros e decide por conta própria a próxima tarefa

Processo de aprendizado da colaboração

• Foi adotada uma estrutura em que todos os agentes tinham autoridade equivalente e coordenavam o trabalho por meio de arquivos compartilhados
  • Cada agente verificava o estado dos demais, recebia uma tarefa e atualizava seu estado
  • Para evitar duplicação, foi usado um mecanismo de lock
• Problemas
  1. Agentes mantinham locks por muito tempo ou não os liberavam, reduzindo a velocidade total para o equivalente a apenas 2 ou 3 entre 20
  2. Ocorriam instabilidades do sistema, como falhas enquanto o lock estava em posse do agente ou edição de arquivos sem lock
• Houve então a transição para controle de concorrência otimista (optimistic concurrency control)
  • Leituras livres e falha nas gravações quando havia mudança de estado
  • Era simples e estável, mas, em uma estrutura sem hierarquia, os agentes passaram a adotar um comportamento excessivamente avesso a risco
  • Evitavam problemas difíceis e repetiam apenas pequenas correções, gerando um ciclo de trabalho sem progresso

Estrutura de Planner e Worker

• A arquitetura foi alterada para um pipeline hierárquico com separação de papéis
  • Planners: exploram a base de código, criam tarefas e, quando necessário, geram planners subordinados
  • Workers: executam apenas a tarefa recebida e, ao concluir, fazem push das alterações
• Em cada ciclo, um agente juiz (judge) decide se o sistema deve avançar para a próxima etapa
  • Essa estrutura resolveu a maior parte dos problemas de colaboração, garantindo escalabilidade para projetos de grande porte

Experimentos de longa duração

• Objetivo do experimento: implementar um navegador web do zero
  • Execução de cerca de 1 semana, com mais de 1 milhão de linhas de código escritas em 1.000 arquivos
  • Centenas de workers fizeram push simultaneamente para a mesma branch, mas os conflitos foram mínimos
  • O código resultante foi publicado no GitHub
• Experimentos adicionais
  • Migração de Solid para React: em 3 semanas, mudanças de +266K/-193K, confirmando a viabilidade de merge
  • Melhoria de renderização de vídeo: versão em Rust com ganho de 25x em velocidade, além da adição de zoom, pan e motion blur
  • Esse código deve entrar em produção em breve

Principais aprendizados

• Após investir dezenas de bilhões de tokens, constatou-se que, embora não seja totalmente eficiente, o resultado foi melhor do que o esperado
• A escolha do modelo é central para tarefas autônomas de longa duração
  • GPT-5.2 se destacou em manter foco, seguir instruções e implementar com precisão
  • Opus 4.5 mostrou tendência a encerrar cedo
  • GPT-5.2 foi mais adequado para o papel de planner do que GPT-5.1-codex
  • O time passou a escolher o modelo ideal para cada papel
• A remoção de complexidade contribuiu para melhorar o desempenho
  • O papel de integrador de qualidade (integrator) acabou criando gargalos
  • Os próprios workers conseguiam resolver conflitos por conta própria
• A estrutura simples foi a mais eficaz
  • Teoria de sistemas distribuídos ou modelos de desenho organizacional se mostraram úteis apenas em parte
  • Estrutura de menos causa conflitos e duplicação; estrutura demais aumenta a fragilidade
• O desenho de prompts teve impacto decisivo no comportamento do sistema
  • Foi essencial para manter o foco no longo prazo, evitar comportamentos patológicos e incentivar colaboração

Próximos desafios

• A coordenação entre múltiplos agentes continua sendo um problema difícil
  • É preciso melhorar para que planners planejem automaticamente os próximos passos quando uma tarefa for concluída
  • Alguns agentes acabam rodando por tempo excessivo, exigindo reinicializações periódicas
• Ainda assim, para a pergunta central — “aumentar o número de agentes permite escalar a codificação autônoma?” —
  • Foi confirmado que centenas de agentes podem colaborar por semanas e produzir progresso real
• Essa tecnologia deve ser incorporada no futuro aos recursos de agentes da Cursor

[GN⁺]

Comentários do Hacker News

• Achei interessante porque estou trabalhando em algo relacionado ao texto do Steve Yegge, Welcome to Gas Town

• No texto de previsões sobre LLM que compartilhei recentemente, artigo de previsões sobre LLM, eu disse que por volta de 2029 não será surpreendente criar um navegador com programação assistida por AI, e este projeto recente do Cursor é a segunda tentativa. Outro exemplo pode ser visto neste post do Reddit

  • Se a implementação for inteligente, imagino que a pessoa simplesmente pegue o código-fonte do Chromium no GitHub, remova recursos desnecessários e mude só a aparência
  • Por volta de 2029, teremos que elevar o padrão a ponto de fazer piada de que a AI está criando navegadores para pelicanos
  • Olhei o código de exemplo do Reddit por uns 5 minutos e o tratamento de cálculo de layout de texto e bidi (texto bidirecional) estava péssimo. É difícil chamar de navegador de verdade um “navegador” que não considera os padrões
  • É impressionante, mas fico em dúvida se o código de navegadores open source não estava incluído nos dados de treinamento do modelo
  • Disseram que a previsão tinha errado, mas fico curioso por que a pessoa apareceu de novo no mesmo podcast uma semana depois para fazer uma nova previsão

• Rodei os testes do repositório por conta própria e estavam cheios de erros e avisos, e o CI já falhava havia muito tempo. Não sei se faz sentido chamar isso de “exemplo de sucesso”. Acho que uma abordagem assistida e centrada em humanos é mais realista do que programação totalmente autônoma

  • A base de código estava dividida em centenas ou milhares de arquivos pequenos, então entender a estrutura era quase impossível. O README também era mal feito e não havia explicação das dependências. Foi código gerado por AI, mas a manutenção é nível pesadelo
  • O próprio autor parece ver a programação totalmente autônoma mais como um experimento para testar os limites dos LLMs do que como um produto sério. No momento, estamos no estágio em que ela consegue gerar “um código razoável sozinha” apenas em projetos pequenos
  • Já que fizeram merge de um PR com CI quebrado, dá até para fazer a piada de que isso atingiu qualidade em nível humano
  • Não está claro o que exatamente significa dizer que é “lento”. Velocidade de GPU? Mais lento que um humano? No fim, pareceu um texto para inflar a bolha de AI

• Fico curioso por que esse PR ainda não foi mergeado. O futuro em que enxames de agentes de AI concluem softwares complexos no longo prazo é legal, mas o exemplo atual é fraco demais. O ponto de colaboração com humanos é mais importante

  • Pela minha experiência, os agentes não convergem e acabam criando um monstro de código cada vez mais bagunçado
  • O fato de não terem publicado nem um projeto simples funcionando parece isca para atrair investidores. O boom de AI lembra a bolha das pontocom, mas desta vez parece mais focado em ganhar dinheiro
  • Exemplos como navegador, Excel ou Windows 7 talvez tenham sido incluídos em parte nos dados de treinamento, mas isso não permite uma reprodução completa
  • O código é grande demais e cheio de problemas, então fazer review é impossível. No fim, só resta um merge estilo YOLO
  • Tenho interesse em condições de convergência. Não importa se o código aumenta ou diminui; o importante é estabilizar em um estado ótimo

• É uma pena que não tenham experimentado aumentando a dificuldade aos poucos. Se tivessem expandido gradualmente de React CRUD → clone do Paint → gerenciador de arquivos → navegador, daria para ver com clareza as etapas de evolução

• Eu também criei o tjs de forma parecida. É o validador de JSON Schema mais rápido e preciso do mundo, e o padrão de planner/delegate com git subtree funcionou bem. Softwares com padrões e testes bem definidos podem ser reescritos e otimizados rapidamente por agentes de AI. Os comandos relacionados podem ser vistos em spawn-perf-agents.md

• Criar um navegador do zero é muito difícil, mas o texto apresentado faltava análise detalhada. Se for só no nível de “compila”, o significado é pequeno. A verificação de verdade é se dá para incorporar a próxima mudança com estabilidade

  • O padrão mínimo para programação por agentes é: “compila com sucesso” → “executa normalmente” → “lida com casos extremos”. Só dá para confiar em um sistema que tenha menos bugs que humanos e rode de forma estável por mais de um ano
  • Na prática, até o CI está falhando, então até a alegação de que “compila” é duvidosa

• Segundo o blog, foram usados trilhões de tokens; calculando pelo preço da API da OpenAI, isso daria dezenas de milhões de dólares. Nesse nível, talvez fosse melhor simplesmente doar para uma equipe de navegador

• Tentei fazer o build pessoalmente e surgiram mais de 100 erros de compilação. A maioria dos commits estava com o CI falhando, e na prática era uma combinação de várias bibliotecas open source. quickjs, wgpu, winit, egui, html parser e outros componentes existentes foram trazidos quase como estavam, mas o CEO alegou que era uma “VM de JS customizada”, o que gera uma impressão enganosa Ainda assim, é impressionante que a AI tenha feito essa integração de forma autônoma

  • Os componentes usados são muito parecidos com o blitz, navegador em Rust, então é possível que isso estivesse nos dados de treinamento
  • Também apareceu a típica piada de startup no estilo “não importa se funciona, tire uma screenshot e mostre para os investidores”
  • Há uma estatística dizendo que, entre mais de 60 mil execuções de workflow, só cerca de mil tiveram sucesso. Na prática, isso parece um monte de código não validado
  • Termina com a piada: “cada um faça seu próprio Cursor customizado”

• O código parecia muito frágil e instável. Por exemplo, a função render_placeholder parece um código temporário que só preenche o frame buffer. Fiquei curioso sobre qual papel esse código realmente desempenha e qual é o custo em tokens/tempo por teste

  • A forma de extrair atributos de tags também pareceu um pouco estranha, como nesta parte
  • Mas, se o Cursor puder corrigir isso automaticamente, essa fragilidade também pode acabar sendo uma estratégia para aumentar a dependência no longo prazo