Como configuramos nosso ambiente de agentes na nuvem
Quando decidimos dar computadores aos agentes na nuvem para que pudessem testar suas alterações, o primeiro passo foi garantir que eles soubessem testá-las bem em nossa própria base de código.
Adaptar nosso monorepo para agentes na nuvem nos ensinou que o ambiente de desenvolvimento é um produto por si só — com agentes como usuários. É preciso fazer com que a nuvem corresponda ao ambiente de desenvolvimento local, tornar o repositório legível o bastante para que os agentes possam executar e testar código sem conhecimento tácito e manter esse ambiente saudável conforme a base de código evolui.
Desenvolver esse ambiente mudou nossa forma de trabalhar. Em dezembro, os agentes na nuvem foram responsáveis por aproximadamente uma em cada dez PRs mescladas ao monorepo do Cursor. Hoje, eles criam mais da metade.
7-day rolling share of merged PRs from cloud agents
Alinhando a nuvem ao desenvolvimento local
A primeira etapa para fazer os agentes na nuvem funcionarem bem em nosso repositório foi garantir que ele funcionasse bem em uma VM na nuvem. Essa etapa é familiar para qualquer engenheiro que já tenha configurado um ambiente de desenvolvimento remoto pela primeira vez.
A maioria dos desenvolvedores do Cursor trabalha localmente em Macs, mas nossas VMs na nuvem executam Linux. Isso significava que precisávamos adaptar vários utilitários de desenvolvimento e scripts de configuração para que funcionassem em VMs Ubuntu. Adicionamos dependências críticas de desenvolvimento a um Dockerfile definido pelo Cursor, que serve como imagem inicial para agentes na nuvem.
Também trabalhamos com nossa equipe de segurança para adicionar recursos de segurança ao produto de agente na nuvem, permitindo que os usuários inserissem com confiança os segredos necessários no ambiente do agente. Esses recursos incluem restrições de saída de rede, acesso a repositórios remotos do Git com escopo definido e via proxy, verificação de segredos em commits e mensagens de commit e ocultação de segredos nos resultados das ferramentas, o que impede o agente de ler valores secretos, mesmo que tente.
Uma interface mais simples para agentes
Mesmo depois de configurarmos nosso ambiente de desenvolvimento em VMs Ubuntu, os agentes ainda tinham dificuldade para executar nosso código. Isso não era surpreendente, pois nossa experiência de desenvolvimento era confusa e exigia aprender e memorizar diversos comandos e flags de construção, além de scripts utilitários.
Criamos habilidades que explicavam como construir e executar várias partes do sistema, mas isso ajudou apenas em casos pontuais. As habilidades podem documentar os comandos corretos, mas os próprios comandos eram complicados e cheios de armadilhas.
Para reduzir essa complexidade, desenvolvemos uma CLI chamada anydev, que os agentes podem usar para iniciar todos os serviços. Também centralizamos scripts utilitários comuns no anydev e o equipamos com vários menus --help que explicam como usar cada subcomando. O anydev também conta com um processo supervisor que monitora e reinicia comandos de construção de longa duração, eliminando totalmente essa responsabilidade do modelo.
O anydev simplificou a experiência de desenvolvimento a ponto de os agentes conseguirem executar seu código com confiabilidade. As habilidades ajudaram a documentar como usá-lo, mas a maior mudança foi que os agentes não precisavam mais lidar com comandos de construção específicos e com várias etapas, evitar armadilhas ocultas ou acompanhar processos de longa duração.
Foi então que os agentes na nuvem, cada um com seu próprio computador, passaram a agregar valor real em relação aos agentes locais. Com o uso do computador, a ferramenta recordScreen e um ambiente de desenvolvimento funcional, os agentes passaram a conseguir testar suas alterações de ponta a ponta e comprovar a correção de seu trabalho para o usuário.
Eles também podiam compartilhar demonstrações gravadas pelos agentes no Slack quando alguém corrigia um relatório de bug ou em uma PR ao abrir uma alteração. Em muitas tarefas, os engenheiros passaram a poder fazer merge e implementar código dos agentes na nuvem com confiança, sem sequer fazer checkout da branch localmente.
Um ambiente autorregenerativo
O ambiente em torno do agente está sempre mudando. Mantê-lo operacional exige atualizar continuamente a forma como ele é executado e o que pode acessar.
Para diagnosticar e recuperar ambientes não saudáveis à medida que apresentam falhas, desenvolvemos o Cursor Cloud MCP. Escolhemos o MCP porque ele nos fornecia ferramentas descobertas dinamicamente, com interfaces que podíamos alterar sem reconstruir o ciclo do agente. Os agentes na nuvem o usam para inspecionar o próprio ambiente em busca de falhas de configuração, políticas de saída, segredos alterados e muito mais. Isso permite que eles diagnostiquem e corrijam problemas à medida que surgem e recuperem ambientes não saudáveis mais rapidamente.
Com o Cursor Cloud MCP em funcionamento, configuramos uma automação chamada Cloud Doctor, que verifica periodicamente se há falhas, identifica quais erros podem ser transitórios e quais são relevantes, realiza análises de causa raiz e pode abrir PRs para corrigir problemas com alta confiança.
Melhorando a experiência com agentes
Mesmo em um ambiente saudável, os agentes às vezes percorrem caminhos demorados ou pouco diretos para verificar suas alterações. Eles podem usar a habilidade errada, enfrentar problemas evitáveis na VM ou seguir fluxos de trabalho que levam mais tempo do que deveriam.
Também usamos o Cursor Cloud MCP nesse caso. Os agentes Cloud Doctor inspecionam rastreamentos para identificar onde outro agente errou, quais habilidades ou comandos induziram ao erro e quais fluxos de trabalho são sistematicamente lentos. Com base nessas descobertas, o Cloud Doctor corrige a habilidade, simplifica o caminho ou altera o ambiente para facilitar o trabalho do próximo agente.
Esse ciclo melhora continuamente a experiência dos desenvolvedores com os próprios agentes. Quando o ambiente é saudável e autorregenerativo, os agentes são executados de forma confiável, e os desenvolvedores confiam aos agentes na nuvem tarefas mais importantes.
Isso nos permitiu ampliar internamente a adoção de agentes na nuvem, que agora produzem a maior parte do código que entregamos.
Preparando seu ambiente para agentes na nuvem
Grande parte da produtividade dos agentes na nuvem depende do ambiente. Para saber se sua base de código está pronta, comece respondendo a três perguntas:
- Os agentes têm acesso às mesmas ferramentas e aos mesmos dados que um desenvolvedor teria?
- Os agentes conseguem encontrar habilidades que documentam como seus desenvolvedores realmente trabalham?
- Os agentes podem testar e verificar fluxos de trabalho principais?
Se quiser ajuda para preparar seu ambiente, entre em contato.
Ou, para saber mais, leia como a Faire dobrou o volume semanal de PRs com agentes na nuvem.
