Cursor: ambientes de nuvem para coding agents agora são maioria dos PRs

O salto de 10% para mais de 50% das PRs

Em dezembro de 2024, agentes na nuvem respondiam por cerca de 1 em cada 10 PRs mescladas ao monorepo do Cursor. Hoje, eles criam mais da metade. O post da equipe de engenharia do Cursor (Mathew Hogan e Arvind Saripalli) detalha como adaptaram o próprio ambiente de desenvolvimento para tornar isso possível.

Alinhando nuvem e ambiente local

A maioria dos devs do Cursor trabalha em Macs, mas as VMs na nuvem rodam Linux (Ubuntu). Foi necessário adaptar utilitários, scripts de configuração e dependências para um Dockerfile que serve como imagem inicial dos agentes. A equipe de segurança adicionou restrições de saída de rede, acesso a repositórios Git com escopo definido via proxy, verificação de segredos em commits e ocultação de segredos nos resultados das ferramentas - impedindo que o agente leia valores secretos mesmo que tente.

anydev: a CLI que simplificou tudo

Mesmo com o ambiente configurado, os agentes tinham dificuldade porque a experiência de desenvolvimento era confusa: múltiplos comandos, flags de build e scripts utilitários. A solução foi criar uma CLI chamada anydev, que centraliza a inicialização de todos os serviços, inclui menus --help e um processo supervisor que monitora e reinicia builds de longa duração. Isso eliminou a necessidade de o modelo lidar com comandos multi-etapa ou acompanhar processos demorados.

Com o anydev, os agentes passaram a testar alterações de ponta a ponta, gravar demonstrações de tela e compartilhá-las no Slack ou na PR. Engenheiros passaram a fazer merge de código dos agentes sem sequer fazer checkout da branch localmente.

Ambiente autorregenerativo com Cloud Doctor

Para manter o ambiente saudável, a equipe desenvolveu o Cursor Cloud MCP - um conjunto de ferramentas descobertas dinamicamente que os agentes usam para inspecionar o próprio ambiente (falhas de configuração, políticas de saída, segredos alterados). Sobre ele, criaram uma automação chamada Cloud Doctor, que periodicamente verifica falhas, faz análise de causa raiz e abre PRs para corrigir problemas com alta confiança.

O Cloud Doctor também inspeciona rastreamentos de sessões de outros agentes para identificar onde erraram, quais habilidades induziram ao erro e quais fluxos são sistematicamente lentos - e então corrige a habilidade, simplifica o caminho ou altera o ambiente para o próximo agente.

Checklist para preparar seu ambiente

A equipe sugere três perguntas para avaliar se uma base de código está pronta para agentes na nuvem:

1. Os agentes têm acesso às mesmas ferramentas e dados que um desenvolvedor teria?
2. Os agentes conseguem encontrar habilidades que documentam como os devs realmente trabalham?
3. Os agentes podem testar e verificar fluxos de trabalho principais?