O experimento mais recente da Cursor entrega a um enxame de agentes de IA um único recurso — o manual oficial do SQLite de 835 páginas — e nada mais: sem código-fonte, sem suíte de testes, sem binários, sem internet. A tarefa: construir um motor de banco de dados funcional em Rust do zero. A nova arquitetura de enxame passou em todos os testes de conformação SQL reservados. Mais consequente ainda é a economia: combinar um modelo de fronteira para planejamento com modelos baratos para execução reduziu a conta de $10.565 (todos de fronteira) para $1.339 — quase 8x mais barato.
A lição para desenvolvedores não é “agentes podem substituir engenheiros de banco de dados”. É que, em escala, como você orquestra os agentes importa mais do qual modelo você escolhe. A separação planejador-executor, árvores de tarefas hierárquicas, documentos de design compartilhados e cadeias de referências verificáveis estão se tornando a camada de infraestrutura da codificação com IA — e se você roda projetos complexos no Cursor, Windsurf ou Cline, ou encadeia agentes para migrações, refatorações e preenchimento de testes, esse blueprint é diretamente copiável.
A Ideia Central: Divida a Árvore de Tarefas em Planejadores e Trabalhadores
Um único agente responsável por uma tarefa grande enfrenta um dilema clássico: seu contexto precisa conter, ao mesmo tempo, o objetivo global, a subtarefa atual, todas as decisões históricas e os detalhes do código. Com o tempo, ele ou não enxerga a floresta por causa das árvores, ou vice-versa. A resposta da Cursor é dividir papéis ao longo da árvore:
-
Planejador: apenas decompõe — nunca escreve implementação. Ele detém o objetivo completo e gera recursivamente unidades de trabalho bem delimitadas para delegar.
-
Trabalhador: implementa apenas a tarefa delegada, nunca planeja. Todo o seu contexto vai para um pequeno trecho de código.
-
Árbitro/Revisor: julga a conclusão e o rollback, fornecendo múltiplas perspectivas de revisão deliberadamente divergentes.
-
Resolvedor de Conflitos: um agente terceiro neutro que cuida de conflitos de merge e contradições de design entre planejadores.
A divisão é fundamentalmente isolamento de contexto: os planejadores nunca se afogam em detalhes de implementação; os trabalhadores nunca perdem o foco com o objetivo global. A própria afirmação da Cursor é que esse isolamento — não o paralelismo bruto — é a principal fonte da escalabilidade do enxame. Em termos de engenharia, o sistema é um pipeline: objetivo mais especificação → planejador raiz → delegação recursiva em sub-planejadores e unidades de trabalho → agentes trabalhadores → documentos de design compartilhados com referências compiláveis → coordenação de conflitos mais camadas empilhadas de revisão → uma suíte de testes reservada como juiz.
E isso não se limita ao SQLite. A Cursor relata ter executado estruturas semelhantes para implementações de navegadores, resolução de problemas matemáticos, otimização de kernels de GPU, caça a vulnerabilidades em código aberto, melhoria de cobertura e geração de dados de treinamento.
Mecanismo 1: Documentos de Design Compartilhados Com Referências Compiláveis
O medo na colaboração multiagente é a cérebro dividido: dois planejadores implementam o mesmo conceito em cantos diferentes do codebase, sem saber um do outro. Ferramentas de merge em nível de texto resolvem conflitos textuais, não semânticos. A abordagem da Cursor:
-
Os planejadores escrevem as decisões de design em um documento de design compartilhado.
-
Qualquer código que dependa de uma decisão carrega uma referência apontando para a entrada correspondente do documento.
-
A referência é verificável por máquina. Quando um coordenador faz merge ou altera o documento de design, a cadeia de referências propaga a resolução para todo o código a jusante.
É verificação de tipos para decisões de arquitetura. Times humanos escrevem ADRs (Architecture Decision Records) à mão e os deixam apodrecer; aqui, o ADR é um cidadão de primeira classe — mantido por agentes, imposto pelo compilador. Um esboço simplificado:
// Design-decision reference in code: points at design doc entry B-07
// @design-ref: B-07 "SQL expression evaluation uses the Row struct uniformly"
#[derive(Clone, Debug)]
pub struct Row {
// ... field definitions
}
pub fn eval_expr(expr: &Expr, row: &Row) -> Value {
// implementation details
}Em uma implementação real, a referência vive como um comentário mais uma verificação estática. O ponto é: tornar a intenção de design rastreável, passível de merge e verificável — não algo que os agentes precisam lembrar do histórico de conversas.
Mecanismo 2: Um Sistema de Controle de Versão Feito para Agentes
O Git tolera mil commits por hora. O novo enxame da Cursor chega a picos próximos de 1.000 commits por segundo, onde o modelo de travamento e merge grosseiro do Git simplesmente falha. A execução do enxame antigo com Grok 4.5 produziu 68.000 commits em duas horas e acumulou mais de 70.000 conflitos de merge — um arquivo foi tocado por 1.173 agentes diferentes e atingiu 7.771 conflitos. O novo enxame rodou por quatro horas com menos de 1.000.
Por isso a Cursor escreveu seu próprio VCS, e ele empurra a coordenação de conflitos para dentro do próprio controle de versão: commits pequenos o suficiente para expor conflitos; conflitos roteados para o agente resolvedor neutro; arquivos inflados sinalizados e congelados contra novos commits até que um agente externo divida o módulo. A conclusão para quem roda agentes concorrentes em um mesmo codebase: antes de compartilhar branches no Git, defina descoberta de conflitos, resolução de conflitos e limites de módulos — caso contrário, mais agentes significam um inferno de merge ainda mais profundo.
Mecanismo 3: Permitir Breaking Changes — De Propósito
Em codebases mantidas por humanos, os agentes andam na ponta dos pés ao redor do código central, e os módulos centrais aos poucos se fossilizam. A solução da Cursor: os agentes podem introduzir proativamente breaking changes anotadas. O fluxo: um agente decide que o código central precisa ser reestruturado e envia um patch com uma nota explicativa; o compilador propaga o impacto por todo o sistema e os módulos relacionados falham ao compilar; os outros agentes leem a nota, entendem a causa e atualizam seus próprios códigos. Refatorar deixa de ser um ritual exclusivo de especialistas e se torna procedimento padrão do enxame. As pré-condições: as mudanças devem carregar explicações, e as falhas devem se propagar.
Mecanismo 4: Uma Suíte de Testes Reservada Como Juiz, Não Como Alvo
A pontuação usava o sqllogictest do SQLite — milhões de consultas SQL que verificam se motores diferentes retornam resultados consistentes para as mesmas consultas. Crucialmente, os agentes nunca souberam que a suíte existia, e a equipe revisou manualmente o código e os logs de execução depois para confirmar que não houve manipulação. A lição se generaliza: deixe que os agentes escrevam seus próprios testes e eles escreverão testes que conseguem passar. Uma suíte de testes fixa e invisível é a única medida honesta. Uma configuração prática:
# Keep a portion of test cases hidden from the agents
# Public tests: used for the agent's own iteration
public_tests/
# Held-out tests: run only at final evaluation
held_out_tests/
# Evaluation script
python evaluate.py --engine ./target/minisqlite --tests held_out_tests/Testes reservados são a defesa mais simples contra o autoengano dos agentes.
Economia de Modelos: Planejadores Caros, Trabalhadores Baratos
A Cursor executou quatro combinações de modelos; todas passaram, com custos drasticamente diferentes:
| Configuração | Planejador | Trabalhador | Custo aprox. | Resultado |
|---|---|---|---|---|
| Todos de fronteira | GPT-5.5 | GPT-5.5 | ~$10.565 | Aprovado |
| Linha de base de custo | Grok 4.5 | Grok 4.5 | Médio | Aprovado |
| Híbrido A | Opus 4.8 | Composer 2.5 | $1.339 | 100% aprovado |
| Híbrido B | Fable 5 | Composer 2.5 | Um pouco mais alto | Aprovado |
-
Os trabalhadores consomem pelo menos 69% dos tokens — geralmente mais de 90%.
-
Ainda assim, os tokens dos planejadores, embora poucos, respondem por cerca de dois terços do custo.
-
A inteligência de fronteira só é realmente necessária para decomposição de tarefas, decisões de design e trade-offs-chave.
-
Uma vez que o planejador comprime a incerteza em instruções explícitas, os modelos baratos executam fielmente.
A conclusão é direta: não rode modelos de fronteira por toda a cadeia. Dê o trabalho de alta incerteza aos modelos fortes e o de alta certeza aos rápidos.
Como Reaproveitar Isso no Seu Próprio Projeto
1. Comece pela decomposição de tarefas
Não peça a um agente que construa um módulo inteiro. Faça um modelo forte gerar primeiro uma árvore de tarefas hierárquica:
Goal: add OAuth2 login to an existing Django project
├── Subtask 1: add dependencies and configure settings
├── Subtask 2: implement the OAuth provider adapter
├── Subtask 3: implement user binding/creation logic
├── Subtask 4: add login and callback routes
├── Subtask 5: write unit tests
└── Subtask 6: write integration tests2. Anexe critérios de aceitação a cada folha
-
Passa na suíte pública em
pytest tests/oauth/. -
A rota
/auth/callback/retorna 302 e definesession["user_id"]. -
Não introduz novos tipos de exceção não tratadas.
3. Modelos baratos executam; modelos fortes revisam
Trabalhadores: classe Claude Sonnet / GPT-4o-mini / DeepSeek-V3 para o código. Planejadores e revisores: classe Opus / GPT-5.5 / Kimi K3 para decomposição e revisão final.
4. Mantenha um conjunto reservado
Esconda 20% dos casos de teste e execute-os apenas na avaliação final — o antídoto contra o overfitting nos testes visíveis.
5. Nunca deixe dois agentes escreverem o mesmo arquivo
Se a concorrência for inevitável, desenhe primeiro os limites dos módulos — ou aproveite o pesadelo do enxame antigo: 7.771 conflitos em um único arquivo.
Recursos
-
Blog da Cursor: Agent Swarms and the New Model Economics
-
Repositório do experimento: github.com/cursor/minisqlite
-
Harness de testes do SQLite: sqllogictest
-
Experimento anterior: Self-Driving Codebases
-
Cobertura: InfoQ
Quando uma tarefa ultrapassa a capacidade de qualquer agente único, a combinação de “modelo forte planeja, modelos baratos executam, documentos de design compartilhados coordenam, testes reservados julgam” supera a capacidade bruta do modelo tanto em custo quanto em controle. A Cursor traçou o mapa da rota — o trabalho restante é dissecá-lo dentro do seu próprio codebase.
