No dia 10 de setembro, a Cursor lançou o recurso Projects, atualmente em versão beta e aberto a todos os usuários. Ele é voltado para trabalhos que atravessam vários PRs e duram semanas ou até meses: desenvolvimento de novas funcionalidades, migração de frameworks, ou a construção de um aplicativo completo do zero.
A estrutura tem duas camadas. A camada superior é um agente coordenador, que não escreve código, apenas distribui tarefas para os agentes abaixo dele. Segundo a Cursor, o coordenador apenas delega, nunca executa, por isso nunca fica travado numa tarefa específica e está sempre pronto para receber novas instruções humanas. A camada inferior é composta por subagentes que escrevem código; segundo o anúncio oficial, um projeto pode comandar milhares deles.
"It doesn't write code itself but directs other agents that do."
(Ele mesmo não escreve código, apenas dirige os outros agentes que o fazem.)
Três capacidades de base
O Projects se apoia em três pilares:
- Cloud-first: os projetos rodam em servidores dedicados e não são interrompidos mesmo quando o notebook é fechado;
- Contexto compartilhado: os arquivos são sincronizados entre a nuvem e a máquina local, permitindo que o que um agente já entendeu seja reaproveitado diretamente pelos agentes seguintes;
- Assinaturas de eventos: um projeto pode monitorar um canal do Slack, rodar em horários programados, ou reagir automaticamente ao status de um PR.
A Cursor apresentou três usos típicos. No desenvolvimento de novas funcionalidades, vários agentes primeiro pesquisam o sistema existente em paralelo e depois implementam componentes diferentes separadamente; em migrações, as equipes usam o recurso para substituir gradualmente frameworks e sistemas de estilo ao longo de centenas de PRs; na manutenção, o coordenador monitora continuamente a qualidade do código e possíveis regressões.
O exemplo do design system
O caso descrito com mais detalhes no blog é a manutenção de um design system: o coordenador varre cada novo PR, extrai os componentes que deveriam entrar no design system e, quando o mesmo erro aparece pela segunda vez, adiciona uma regra de lint. Segundo estimativas da Cursor, esse tipo de projeto processa de 20 a 100 PRs por dia.
Fazendo uma conta rápida do que esse volume representaria em termos humanos: supondo que revisar com cuidado um PR de tamanho médio leve de 15 a 30 minutos, 20 PRs por dia equivalem a 5 a 10 horas, algo que uma pessoa consegue sustentar com dificuldade; já 100 PRs por dia seriam de 25 a 50 horas, o que, considerando 8 horas de trabalho por pessoa ao dia, exigiria de três a seis revisores em tempo integral. Conforme a velocidade de produção da máquina aumenta, o gargalo se desloca para a revisão, a menos que a equipe aceite que parte dos PRs seja mesclada apenas após passar pelas verificações automáticas. A Cursor não informou que proporção dos PRs gerados pelo Projects passa por revisão humana antes de ser mesclada.
De onde vem o “seis vezes”
A Cursor apresentou dois números de resultado: internamente, novos usuários mesclam 30% mais PRs; já os usuários que trabalham principalmente com o Projects têm um volume de merges seis vezes maior do que antes. Os dois números vêm de funcionários da própria Cursor, medem apenas a quantidade de PRs mesclados, não consideram o tamanho dos PRs, o retrabalho nem os rollbacks, e nem sequer especificam qual é a base de comparação para os 30%. Ainda não há dados disponíveis vindos de equipes externas.
Quanto a preços, o blog não menciona se o Projects será cobrado separadamente, nem como será medido o uso de milhares de subagentes rodando ao mesmo tempo. Manter centenas ou milhares de agentes ativos na nuvem por longos períodos certamente não é barato, e esse ponto ainda depende de a Cursor detalhar seu modelo de cobrança.
Dois passos que se conectam numa linha
Olhando para as movimentações da Cursor no último semestre, o Projects é mais um elo dessa cadeia. No lançamento da versão 3.0 em abril, a Cursor reposicionou a IDE como uma interface de gerenciamento de agentes; no início de setembro, passou a permitir que agentes na nuvem rodassem em servidores próprios das empresas. O Projects conecta essas duas etapas: humanos gerenciam o coordenador, o coordenador gerencia os executores, e os executores podem rodar tanto na nuvem quanto nos próprios servidores da empresa.
No mesmo dia, a Agents API lançada pela OpenAI também passou a permitir que um agente principal divida tarefas entre subagentes, mas as duas empresas atacam ângulos diferentes: a OpenAI vende a base para desenvolvedores construírem seus próprios agentes, enquanto a Cursor vende um produto pronto que executa o trabalho diretamente para as equipes. O acesso ao Projects fica na barra de navegação lateral esquerda, e a recomendação oficial é usá-lo apenas em trabalhos que atravessam vários PRs ou se estendem por um período mais longo.
Fontes: blog oficial da Cursor, CocoLoop, MarkTechPost; os detalhes sobre a escala dos subagentes, o percentual de aumento nos merges de PRs e os exemplos de caso foram verificados a partir do blog da Cursor.