Imagina 200 agentes de IA trabalhando ao mesmo tempo no mesmo projeto, gerando mais de um milhão de linhas de código, rodando por semanas sem parar. Parece ficção? A Cursor acaba de publicar os números reais dessa operação, e os resultados mexem com tudo que a gente achava saber sobre custo e escala de desenvolvimento com IA.

A empresa por trás de um dos editores de código mais populares do mercado revelou dois estudos internos que mostram como enxames de agentes (agent swarms) conseguem construir projetos complexos do zero, com centenas de agentes simultâneos, gerando milhares de commits por hora. E o mais interessante: o custo caiu de US$ 10.565 para US$ 1.339 dependendo da combinação de modelos.

Vamos direto ao que importa.

O Experimento: SQLite Reescrito em Rust por Agentes

O time da Cursor decidiu testar seus enxames com um desafio real: construir o SQLite do zero, em Rust, usando apenas a documentação como referência. Nada de copiar código existente, nada de fine-tuning específico. Puro prompt engineering e coordenação entre agentes.

O resultado? A versão nova do sistema atingiu 80% de aprovação numa suíte de testes SQL que os agentes nunca viram antes, usando o Grok 4.5 como modelo principal. Em quatro horas. A versão antiga do swarm? Entrou em espiral e precisou ser pausada antes de completar duas horas.

A diferença entre as duas versões não foi o modelo usado. Foi a arquitetura de coordenação.

Números que impressionam

Olha a diferença nas linhas de código: 64 mil contra 9.900. Menos código, melhor resultado. Isso diz muito sobre como agentes sem coordenação adequada geram lixo, duplicação e complexidade desnecessária.

Eu já vi isso acontecer em times humanos, diga-se de passagem. Dois devs trabalhando no mesmo módulo sem comunicação produzem o dobro do código e metade do resultado. A diferença é que com agentes, o estrago acontece em minutos, não em semanas.

A Arquitetura que Funciona: Planner + Worker

Depois de duas iterações fracassadas, a Cursor chegou numa arquitetura hierárquica que funciona. O design é simples de entender, mas difícil de acertar.

Primeira tentativa (falhou)

Estrutura plana onde agentes se coordenavam por arquivos compartilhados com locks. Vinte agentes produziam o equivalente a dois ou três. Gargalo total. É o equivalente distribuído de um mutex global: tecnicamente correto, praticamente inútil.

Segunda tentativa (parcial)

Controle de concorrência otimista substituiu os locks. Melhorou o throughput, mas criou outro problema: os agentes ficaram conservadores demais. Evitavam tarefas difíceis, escolhiam sempre o caminho seguro, e o trabalho girava sem progresso real. Imagine um dev que só pega tickets fáceis no sprint porque tem medo de conflito de merge.

Terceira tentativa (funcionou)

Pipeline hierárquico com papéis especializados:

• Planners: modelos mais capazes (frontier) que exploram o codebase, decompõem o projeto em tarefas e tomam decisões arquiteturais. Podem criar sub-planners para paralelizar o planejamento recursivamente.
• Workers: modelos mais rápidos e baratos que executam as tarefas delegadas. Foco total na implementação, sem coordenação entre si.
• Judge: agente que avalia se o ciclo deve continuar ou parar.

A sacada principal? Os planners tomam as decisões de design sozinhos, em vez de delegar para os workers. Na versão anterior, quando um worker precisava decidir algo arquitetural, ele não tinha contexto suficiente e tomava decisões ruins. Agora, o planner resolve o “quê” e o “como”, e o worker só executa.

Isso espelha uma lição antiga de engenharia de software: separação de responsabilidades. O planner é o tech lead que define a arquitetura. O worker é o dev que implementa. O judge é o QA que decide se passa ou não. Cada um faz o que sabe fazer.

Como os conflitos são resolvidos

Quando dois workers editam o mesmo arquivo (inevitável com centenas de agentes), um agente neutro (terceiro) resolve o conflito de merge de forma imparcial. Sem ego, sem preferência por “seu” código. O mediador analisa o contexto do projeto e decide qual versão faz mais sentido.

Além disso, arquivos que ficam grandes demais são automaticamente decompostos em módulos menores. E todas as decisões de design ficam documentadas em arquivos de referência que o código precisa seguir, com verificação em tempo de compilação. Se um worker ignora uma decisão arquitetural, o código não compila.

Essa abordagem de “documentação executável” é brilhante. Em times humanos, documentação de arquitetura fica desatualizada no dia seguinte. Aqui, ela é enforced pelo compilador.

A Economia que Muda o Jogo

Aqui é onde a coisa fica realmente interessante para quem paga a conta.

A Cursor testou múltiplas combinações de modelos no experimento do SQLite. Todas atingiram qualidade similar no resultado final, mas o custo variou absurdamente:

Quase 8x de diferença entre a combinação mais cara e a mais barata. E a qualidade final? Comparável.

O insight central é este: poucos momentos numa tarefa grande realmente exigem inteligência frontier. Decomposição, decisões de arquitetura, resolução de ambiguidades, revisão de trade-offs. Esses momentos pedem um modelo caro. Mas uma vez que o planner cria instruções explícitas e detalhadas, modelos mais baratos simplesmente seguem o roteiro.

É como contratar um arquiteto sênior para o projeto e pedreiros eficientes para a execução. Você não precisa de 50 arquitetos. Precisa que o único arquiteto seja bom e que os pedreiros saibam ler a planta.

Esse padrão tem nome na literatura: “context efficiency”. O planner absorve toda a complexidade contextual e a transforma em instruções atômicas. O worker opera num contexto estreito e bem definido, gastando menos tokens para produzir resultado.

Composer 2.5: O Worker Ideal

Para entender por que essa economia funciona na prática, vale olhar os números do Composer 2.5, o modelo proprietário da Cursor lançado em maio de 2026.

O Composer 2.5 custa cerca de um décimo do preço por token comparado ao Opus 4.6, e nos benchmarks de coding (SWE-Bench Multilingual) marca 79,8%. Para a função de worker, que recebe instruções claras e implementa, isso é mais do que suficiente.

Na análise da Cursor, o custo por request varia quase 9x entre famílias de modelos. Mas o custo por linha de código aceita varia “apenas” 7x, porque modelos mais caros produzem mais código útil por request. Ainda assim, a conta pende fortemente para modelos baratos na função de worker.

Para um time de 20 a 30 engenheiros gerando 10 milhões de tokens de output por mês, a diferença anual entre usar Opus 4.6 puro versus Composer 2.5 Standard é de aproximadamente US$ 2.700 só em tokens de saída. Parece pouco? Multiplica por centenas de agentes rodando por semanas. A conta escala rápido.

Projetos Reais: O Que Esses Enxames Já Construíram

A Cursor não ficou só no experimento do SQLite. O blog de scaling agents mostra projetos reais que rodaram por semanas com centenas de agentes simultâneos:

Um emulador de Windows 7 com 1,2 milhão de linhas de código. Uma implementação de Excel com 12 mil commits. Isso não é toy project, é escala de produto real.

O projeto de migração de framework (Solid para React) é particularmente revelador. Três semanas de trabalho autônomo, editando quase meio milhão de linhas de código no codebase real da Cursor. Esse tipo de migração normalmente leva meses com um time humano. Aqui, agentes fizeram sozinhos, sem ninguém sentado na frente do monitor acompanhando cada commit.

O projeto de renderização de vídeo é outro destaque. Os agentes conseguiram uma implementação em Rust otimizada que roda 25x mais rápido que a versão anterior. Não é só sobre volume de código: os agentes estão tomando decisões de performance que fazem diferença real.

Os Problemas que Ainda Existem

Seria desonesto pintar só o lado bonito. A Cursor é transparente sobre os problemas que ainda não resolveu, e isso vale ouro:

Agentes que rodam para sempre sem progresso. Às vezes um agente entra num loop, tentando resolver algo que não consegue, sem perceber que está preso. O judge agent deveria pegar isso, mas nem sempre funciona. Se você já viu um CI rodando por horas sem motivo, é basicamente o mesmo problema, só que multiplicado por 200.

Planners reativos demais. Hoje os planners fazem polling periódico para verificar o estado do projeto. O ideal seria um sistema orientado a eventos, onde o planner acorda automaticamente quando uma tarefa é concluída. Parece simples, mas na prática envolve gestão de estado distribuído que faz o Kubernetes parecer brincadeira de criança.

Drift acumulativo. Depois de dias rodando, os agentes começam a se desviar das decisões originais. Pequenas inconsistências se acumulam até que o projeto precisa de um “fresh start” parcial. A equipe da Cursor ainda faz reinícios periódicos para combater isso, admitindo que é um workaround, não uma solução.

O prompt importa mais que a infra. Essa foi uma descoberta que surpreendeu o próprio time: “The harness and models matter, but the prompts matter more.” A qualidade dos prompts que definem o comportamento dos agentes é mais determinante que a escolha do modelo ou a arquitetura do sistema. Uma mudança de prompt pode ser a diferença entre um swarm produtivo e um caótico. Quem diria que prompt engineering seria a habilidade mais valiosa numa arquitetura distribuída de IA.

Multi-Agent em 2026: Onde Estamos

O trabalho da Cursor não existe isolado. Em 2026, três topologias dominam o mundo multi-agent:

1. Supervisor/Hierárquico: um agente central coordena os demais. É o modelo que a Cursor usa.
2. Orquestrador-Worker: responsável por cerca de 70% dos deploys em produção. Similar ao hierárquico, mas com um orquestrador mais leve.
3. Swarm puro: agentes peers sem controle central. Mais usado em pesquisa, data labeling e red-teaming, onde paralelismo bruto importa mais que coordenação.

Sistemas multi-agent em geral adicionam entre 58% (independentes) e 285% (centralizados) de overhead em tokens. Isso significa que só vale a pena quando a tarefa genuinamente se beneficia de paralelismo, especialização ou revisão cruzada.

Coding é exatamente esse tipo de tarefa. Um projeto grande pode ser decomposto em módulos independentes, cada módulo pode ser implementado em paralelo, e a integração pode ser verificada automaticamente por testes e compilação. É o caso de uso perfeito para multi-agent.

A Cursor está provando isso com números. E a tendência é clara: os vendors de modelos estão separando o uso interativo (dev sentado usando o editor) do uso automático (agentes rodando em background), com pricing diferente para cada caso.

O Que Isso Significa para Quem Escreve Código

Se você é dev e está lendo isso pensando “vou perder meu emprego”, calma. O que a Cursor está mostrando é que o trabalho braçal de codificação está sendo automatizado, sim. Mas o trabalho de planejamento, arquitetura e tomada de decisão está sendo valorizado.

Os planners no sistema da Cursor são os modelos mais caros justamente porque fazer as perguntas certas e decompor problemas é a parte difícil. Implementar, dado um spec claro, é a parte fácil.

Para quem trabalha com desenvolvimento, o recado é: invista em entender sistemas, não em decorar sintaxe. Aprenda a escrever specs que máquinas conseguem seguir. Domine arquitetura e trade-offs. O “como codar” está virando commodity. O “o que codar” e “por que codar” continuam sendo humanos.

A Cursor está processando 1.000 commits por segundo com seus enxames. A pergunta não é se isso vai mudar o mercado. É quando você vai se adaptar.

—

Fonte de inspiração: Agent Swarms and the New Model Economics e Scaling Long-Running Autonomous Coding, publicados pela Cursor.