A Cursor, empresa por trás de soluções de codificação assistida por inteligência artificial, demonstrou que sua nova arquitetura de enxame de agentes de IA pode reconstruir projetos complexos com 100% de precisão e custos drasticamente reduzidos. Em um desafio que consistia em recriar o SQLite em Rust usando apenas a documentação, sem acesso ao código-fonte ou à internet, o sistema atualizado superou seu predecessor ao empregar modelos de IA mais baratos para a execução da maior parte do código, enquanto modelos de fronteira se encarregavam do planejamento, resultando em uma economia substancial de custo.

Os enxames de agentes da Cursor evoluíram de um projeto de pesquisa para um produto central. Com o Cursor 3, desenvolvedores podem executar frotas inteiras de agentes de IA em paralelo. A Anysphere, empresa por trás da Cursor, foi recentemente adquirida pela SpaceX de Elon Musk por US$ 60 bilhões.

Divisão de Funções: Planejadores e Trabalhadores

O sistema divide os agentes em dois papéis principais: agentes planejadores, que utilizam modelos de fronteira poderosos para quebrar recursivamente um objetivo em tarefas menores, e agentes trabalhadores, que empregam modelos mais rápidos e baratos para executar essas tarefas. O resultado é uma árvore de tarefas que se adapta à medida que o trabalho avança.

A Cursor afirma que essa divisão de papéis resolve principalmente um problema de contexto. Um único agente precisa percorrer toda a árvore enquanto mantém tanto o objetivo quanto a tarefa atual em mente, o que explica por que os agentes podem se desviar durante trabalhos longos. No enxame da Cursor, os planejadores não escrevem código, e os trabalhadores não planejam.

Superando Gargalos de Versão e Conflitos

Um enxame anterior da Cursor no navegador alcançava cerca de 1.000 commits por hora no Git. Ele utilizava agentes trabalhadores, um agente juiz e um integrador que resolvia conflitos. Contudo, o integrador acabou criando mais gargalos do que eliminava.

O novo enxame atingiu a marca de 1.000 commits por segundo, o que levou a Cursor a construir seu próprio sistema de controle de versão, pois agentes trabalhando a essa taxa criavam modos de falha que equipes humanas nunca encontram. Em um que a Cursor chamou de “design de cérebro dividido”, dois planejadores construíam, sem saber, a mesma ideia em lugares diferentes e a implementavam de maneiras distintas. A disputa era ainda mais difícil de gerenciar quando os planejadores tinham conhecimento um do outro e se bloqueavam com edições concorrentes.

Para contornar isso, a Cursor fez com que os agentes registrassem decisões em documentos de design compartilhados. O código ligado a uma decisão remetia ao documento através de uma referência verificada no momento da compilação. Quando ocorriam conflitos de merge, um agente neutro intervinha e os resolvia. Além disso, os trabalhadores sinalizavam arquivos inchados para que um agente externo os dividisse em módulos menores. Como os agentes aprenderam a não tocar no código principal ao trabalhar em bases de código existentes com humanos no ciclo, a Cursor permitiu que eles 'quebrassem' as coisas intencionalmente. Um agente poderia corrigir o código fora de sua área atribuída, e o compilador levaria a mudança através do sistema.

Metodologias de Revisão e Aprendizado Contínuo

A Cursor testou várias abordagens de revisão. Um revisor recebia a transcrição completa do trabalhador, outro via apenas a saída, e um terceiro via apenas a base de código. Nenhuma perspectiva única capturava tudo, mas perspectivas não correlacionadas combinadas resultaram em maior confiabilidade.

A empresa também testou um “guia de campo”, uma pasta de conhecimento mantida pelos próprios agentes com um limite de linhas fixo. Cada agente recebia seu conteúdo na inicialização. Como os pesos dos modelos são fixos, é vantajoso capturar descobertas surpreendentes para que agentes posteriores possam usar atalhos.

O Desafio SQLite em Rust e Resultados Chave

A Cursor forneceu ao enxame o manual de 835 páginas do SQLite e o instruiu a construir uma implementação em Rust. O código-fonte, suítes de teste, o binário do SQLite e o acesso à internet foram todos retidos. O benchmark utilizado foi o sqllogictest, uma suíte de testes com milhões de consultas SQL e respostas conhecidas, da qual o enxame não tinha conhecimento prévio.

Foram testadas quatro configurações: GPT-5.5 solo, Grok 4.5 solo, Opus 4.8 como planejador com Composer 2.5 como trabalhador, e Fable 5 como planejador com Composer 2.5 como trabalhador. O novo sistema superou o antigo em todas as configurações. Após quatro horas, as novas execuções obtiveram entre 73 e 85% de acerto, enquanto as antigas variaram entre 11 e 77%. Todas as configurações do novo sistema, posteriormente, alcançaram 100%.

As execuções com Grok 4.5 revelaram por que o sistema antigo ficava para trás. O enxame antigo produziu 68.000 commits em duas horas, cerca de 70 vezes mais do que o novo. A maior parte dessa atividade foi trabalho desperdiçado. A execução antiga acumulou mais de 70.000 conflitos de merge, enquanto a nova permaneceu abaixo de 1.000 durante todo o teste.

O arquivo mais contestado na execução antiga registrou 7.771 conflitos de 1.173 agentes, em comparação com 47 na nova execução. O mesmo problema de “cérebro dividido” apareceu na estrutura do pacote. A execução antiga dividiu o projeto em 54 ‘crates’ Rust com três pacotes SQL separados. A nova execução se estabeleceu em nove ‘crates’ no início do projeto.

Na configuração Fable 5, o enxame antigo necessitou de 64.305 linhas de código de motor, enquanto o novo precisou de 9.908. Na configuração Opus, o sistema antigo produziu 19.013 linhas e obteve 97% de acerto. O novo sistema alcançou 100% com 4.645 linhas.

O Impacto Econômico dos Modelos Mais Baratos

Os custos totais variaram de US$ 1.339 para o híbrido Opus a US$ 10.565 para o GPT-5.5 rodando sozinho. Os trabalhadores foram responsáveis por pelo menos 69% dos tokens em cada execução e, geralmente, por mais de 90%. Os tokens dos planejadores custam mais, então a divisão de custos era diferente. No híbrido Opus, o planejador produziu apenas uma pequena parte dos tokens, mas respondeu por dois terços do custo total.

O modelo de trabalhador criou a maior diferença de custo. Na execução com GPT-5.5, os trabalhadores sozinhos custaram US$ 9.373. Na execução usando Opus e Composer, toda a frota de trabalhadores custou US$ 411 com qualidade comparável. A diferença se deve quase inteiramente ao preço. O Composer 2.5 se equipara aos níveis de Opus 4.7 e GPT-5.5, mas custa apenas US$ 0,50 por milhão de tokens de entrada e US$ 2,50 por milhão de tokens de saída. O modelo é baseado no Kimi K2.5, de acordo com o fundador da Cursor, Michael Truell.

A Cursor argumenta que apenas algumas partes de uma grande tarefa precisam da inteligência de um modelo de fronteira, incluindo a quebra de tarefas e as principais decisões de design. Uma vez que um planejador de fronteira resolve a ambiguidade, modelos mais baratos podem seguir seu plano, embora as execuções híbridas tenham mostrado que a qualidade do planejador ainda importa. O planejador Fable 5 usou menos tokens de planejamento do que o Opus, mas seus trabalhadores precisaram de muito mais tokens para concluir o trabalho, tornando a execução com Fable mais cara no geral.

A Cursor descreve os enxames como uma espécie de compilador probabilístico que traduz a intenção em trabalho executável passo a passo. A empresa afirma que descrever com precisão essa intenção foi a principal restrição no experimento. A Cursor publicou a base de código da execução solo do Opus como minisqlite no GitHub.

Execuções como essas não estão mais limitadas a experimentos de laboratório. Uma versão de pré-lançamento do Fable 5 lidou com a maior parte da reescrita do Bun de Zig para Rust. Sessenta e quatro instâncias escreveram mais de um milhão de linhas de código em 11 dias por cerca de US$ 165.000. No entanto, o uso em produção ainda apresenta desafios. Um estudo publicado no final de 2025 revelou que 68% dos agentes usados em produção não completaram mais de dez passos antes da intervenção humana. Para 47%, o limite foi de menos de cinco passos.Fonte: The Decoder (https://the-decoder.com/cursors-agent-swarm-suggests-cheaper-models-can-handle-most-coding-when-frontier-models-plan-the-work/)