Cursor Bugbot: como configurar, quanto custa e quando usar

Minha avaliação: vale considerar o Bugbot quando a equipe quer conectar os problemas encontrados nos PRs ao fluxo de correção do Cursor. Mantenha a aprovação humana e as verificações automatizadas que já existem. No Azure DevOps, avalie o revisor pelo que ele entrega por si só, já que o Bugbot Autofix não está disponível nessa plataforma. No GitLab e no Bitbucket, antes de ativar o Autofix, decida se permitir correções diretamente na branch do PR faz sentido para o seu fluxo.

O que o Cursor Bugbot analisa na revisão de código?

O Bugbot procura bugs, problemas de segurança e de qualidade de código no diff de um pull request, ou seja, nas alterações propostas para o merge. Pense em um inspetor que avalia uma reforma: o trabalho alterado é o ponto de partida, e as regras do repositório definem os requisitos específicos daquele prédio.

As revisões podem acontecer a cada atualização do PR ou quando alguém comenta cursor review ou bugbot run. Os comentários já existentes, tanto na discussão geral quanto nas linhas de código, servem de contexto para que o Bugbot leve em conta o feedback anterior. Cada problema apontado vem com explicações e sugestões de correção, além de links para continuar no Cursor ou na web. Como o Bugbot funciona.

O ganho prático está em chamar atenção mais cedo para um defeito que poderia passar pela revisão. A quantidade de comentários não mede esse ganho. Avalie se os apontamentos identificam uma falha real, explicam quando ela acontece e levam a uma correção útil. Mantenha os testes, as verificações de segurança e a revisão pelos responsáveis pelo código.

Como configurar o Bugbot em cada repositório

Conecte seu provedor de controle de versão pelo painel de integrações do Cursor. Depois, abra o Bugbot em Automations e ative os repositórios que deseja revisar. Conectar o provedor e ativar os repositórios são etapas separadas. A configuração do Cursor oferece suporte a GitHub, GitLab, Bitbucket e Azure DevOps Services, incluindo as variantes com hospedagem própria documentadas para os três primeiros. Configuração do Bugbot.

GitHub

Você precisa de acesso de administrador no Cursor e na organização do GitHub. Em Integrations, escolha Connect ao lado de GitHub ou Manage Connections, caso a conexão já exista. Selecione All repositories ou Selected repositories, conclua a conexão e volte ao Cursor para ativar os repositórios escolhidos no Bugbot. O GitHub Enterprise Server tem uma aba própria de configuração e orientações de rede específicas. Integração do Cursor com o GitHub.

GitLab

No GitLab.com, você precisa de acesso de administrador no Cursor, permissão de maintainer no GitLab e um plano pago GitLab Premium ou Ultimate. O Cursor exige tokens de acesso de projeto, que o GitLab Free não oferece. Em Integrations, escolha Connect ou Manage Connections, conclua a instalação no GitLab e use Manage → Sync Repos antes de ativar os repositórios no Bugbot. Instalações com hospedagem própria têm instruções de conexão separadas. Integração do Cursor com o GitLab.

Bitbucket

O Bitbucket Cloud está atualmente em beta público. Conecte sua conta em Integrations e autorize o Cursor. O workspace também precisa do aplicativo do Cursor: um administrador do workspace do Bitbucket abre o menu de gerenciamento do Bitbucket no Cursor, escolhe Install Cursor app e instala o aplicativo no workspace. Em seguida, um administrador da equipe no Cursor com acesso ao workspace abre Forge Apps → Cursor nas configurações do workspace do Bitbucket, seleciona Connect to Cursor e vincula a equipe. Depois, ative os repositórios no Bugbot. Conectar apenas uma conta pessoal não estabelece a identidade do aplicativo usada para publicar os comentários de revisão. O Bitbucket Data Center tem um processo de configuração separado. Integração do Cursor com o Bitbucket.

Azure DevOps

Use a configuração específica do Bugbot para o Azure DevOps Services. Ela exige o consentimento de um administrador do tenant do Microsoft Entra. Um Project Collection Administrator conecta o Azure DevOps e ativa o Bugbot em um repositório. Isso provisiona o service principal do Cursor, uma identidade de aplicativo na sua organização. Um administrador de projeto precisa adicionar essa identidade a Project Administrators em cada projeto que será revisado, para que ela possa gerenciar os service hooks, as notificações que disparam as revisões.

Mudanças de permissão podem levar algum tempo para se propagar. Resolva eventuais erros de configuração e tente ativar o repositório novamente. O Bugbot oferece suporte a repositórios de equipe, mas não a repositórios de escopo pessoal. Configuração do Bugbot no Azure DevOps.

Defina quando e para quem revisar

Em cada repositório ativado, escolha se o Bugbot deve revisar as atualizações ou executar apenas uma vez por PR, e configure as listas de autores permitidos ou bloqueados. Nas configurações pessoais, cada autor pode definir revisões apenas por menção, uma vez por PR ou que incluam rascunhos. Nos repositórios ativados, o Bugbot também pode revisar contribuições de pessoas que não fazem parte da sua equipe no Cursor. Configurações de repositório e pessoais.

O Azure DevOps tem uma condição adicional para disparar revisões manualmente: o endereço usado por quem comenta para entrar no Azure DevOps precisa corresponder a uma conta do Cursor na equipe proprietária do repositório. Essa restrição não se aplica às revisões automáticas. Acionamento de revisões no Azure DevOps.

Como usar o arquivo .cursor/config/bugbot.yaml

Mantenha a configuração de revisão no repositório quando quiser que as mudanças nela também passem por revisão de código. Este é o exemplo publicado na documentação de configuração de repositórios do Cursor:

# .cursor/config/bugbot.yaml
version: 1

triggers:
  drafts: false
  frequency: everyPush # everyPush | oncePerPr

review:
  effort: default # low | default | high | smart
  smartPrompt: ""
  incremental: true

prSummary:
  mode: comment # disabled | description | comment
  riskScore: true

autofix:
  mode: disabled # disabled | newBranch | existingBranch

Faça commit e push do arquivo nesse caminho, a partir da raiz do repositório. O Bugbot lê a versão da branch de destino do PR, aquela que receberá as alterações. Ele não usa a versão da branch de origem do PR; assim, uma alteração proposta não pode reescrever a configuração da própria revisão. Use CODEOWNERS, o mecanismo que define os responsáveis pelos arquivos do repositório, para controlar quem revisa mudanças nessa configuração.

Todos os campos são opcionais. Campos ausentes ou inválidos fazem o Bugbot buscar o valor na próxima fonte de configuração; arquivos maiores que 64 KB são ignorados. A ordem de prioridade é:

1. As configurações pessoais do autor para os próprios PRs.
2. O arquivo YAML do repositório.
3. As configurações de equipe e organização no painel.

Essa ordem faz diferença: consultar apenas o YAML não basta para saber quais configurações serão aplicadas a um autor. Além disso, autofix.mode pode restringir o que o painel permite, mas não pode ativar o Autofix quando ele está desativado no painel. Comportamento e precedência das configurações.

O exemplo define que o resumo seja publicado como comentário; ele não representa todos os padrões do painel. Sem essa configuração explícita, os resumos de PR vão para a descrição por padrão. A revisão incremental analisa as alterações feitas desde a revisão anterior do Bugbot. Níveis mais altos de esforço podem consumir mais tempo e uso na busca por bugs; a opção Smart deixa que suas instruções determinem o nível de esforço. Resumos, revisões incrementais e esforço.

Coloque as instruções de revisão em BUGBOT.md

Use .cursor/BUGBOT.md para registrar o conhecimento do projeto de que um revisor precisa. O arquivo da raiz é sempre incluído. O Bugbot também encontra arquivos .cursor/BUGBOT.md em subdiretórios, percorrendo os diretórios acima de cada arquivo alterado. Assim, um diretório de backend pode ter instruções diferentes das do frontend. As regras do editor Cursor em .cursor/rules/*.mdc não se aplicam ao Bugbot. Regras de projeto do Bugbot.

Uma boa regra descreve uma condição que sempre deve ser respeitada e a falha que merece atenção. Uma equipe de pagamentos, por exemplo, pode registrar que repetir uma operação não deve gerar uma nova cobrança ao cliente. Uma equipe de backend pode explicar quais transições de estado exigem um registro de auditoria. São sugestões de temas para regras, não promessas de que o Bugbot identificará toda violação.

Regras de equipe, arquivos de regras do projeto, regras aprendidas e regras manuais do repositório são combinados. Para usar as regras aprendidas e manuais do painel, o aprendizado precisa estar ativado na organização e no repositório. Mantenha as instruções focadas: cada regra é truncada em 30,000 caracteres, e o conjunto das regras de revisão tem um limite de 100,000 caracteres. Para conferir o que de fato foi carregado, comente bugbot run verbose=true ou cursor review verbose=true; a resposta identifica as regras incluídas, truncadas ou omitidas. Regras e limites.

Quanto custa o Bugbot no modelo atual?

Planeje o orçamento do Bugbot pelo consumo e contabilize o Autofix separadamente. A descrição atual do Cursor é a seguinte:

Esses são os termos atuais de cobrança do Bugbot. Não presuma que a franquia do editor da equipe cubra as revisões do Bugbot. O Autofix consome créditos do Cloud Agent, cobrados pelas tarifas do seu plano atual. Cobrança do Autofix.

A mudança de preços de maio passa a valer para assinaturas existentes na próxima renovação após 8 de junho de 2026. Por isso, uma assinatura anual antiga pode continuar nas condições anteriores até a renovação. Anúncio do Cursor sobre a mudança de preços.

A documentação atual do Bugbot não informa uma tarifa fixa por revisão que possa ser usada diretamente no orçamento. A complexidade do PR, a frequência das revisões e o nível de esforço afetam o trabalho realizado. Trate o custo médio por execução divulgado pelo fornecedor como uma referência, não como uma tarifa garantida para o seu repositório.

Para avaliar se o investimento compensa, compare gastos com revisões + gastos com Autofix + tempo dos engenheiros para avaliar os apontamentos com o esforço de revisão e retrabalho que a equipe evita. O orçamento da revisão humana continua existindo. A decisão depende dos problemas úteis que a ferramenta identifica e da atenção que ela poupa, não da capacidade de mais um bot produzir comentários.

Autofix e MCP têm requisitos diferentes

O Autofix inicia um Cloud Agent, um agente que trabalha no código remotamente, para corrigir os problemas apontados pelo Bugbot e informar o resultado no PR. O recurso exige que o uso sob demanda e o armazenamento estejam ativados; o Legacy Privacy Mode não atende a esse requisito de armazenamento. Escolha um modo compatível em Bugbot Automations. Requisitos do Autofix.

Esses são os modos de Autofix documentados pelo Cursor. O modo que usa a branch atual permite no máximo 3 tentativas por PR para evitar loops. Minha recomendação inicial é deixar o Autofix desativado até a equipe combinar como revisará as correções geradas; depois, equipes no GitHub podem escolher o modo de nova branch para inspecioná-las separadamente.

O MCP, um protocolo que dá a uma ferramenta de IA acesso a outras ferramentas e a contexto, pode ampliar o processo de revisão do Bugbot. Configure o servidor MCP e adicione suas ferramentas ao Bugbot em Automations. O suporte a MCP no Bugbot está disponível apenas nos planos Team e Enterprise. Disponibilidade do MCP.

Bugbot vs CodeRabbit vs Greptile: custos e diferenças

Escolha de acordo com o encaixe no fluxo de trabalho e com o modelo de custo que você consegue administrar. Os valores abaixo são preços publicados, não resultados de um teste comparativo.

Fontes: Cursor Bugbot, preços do CodeRabbit, preços do Greptile. Os valores anuais do CodeRabbit representam o equivalente mensal com cobrança anual. Os créditos do Greptile não são intercambiáveis com o uso do Cursor nem com a cobrança por arquivo revisado do CodeRabbit.

A comparação para o orçamento é direta: o CodeRabbit soma uma assinatura por assento a possíveis cobranças pela continuidade das revisões; o Greptile combina assentos e créditos; no modelo atual do Bugbot, a principal variável é o consumo das revisões. Não dá para afirmar honestamente qual opção é mais barata para sua equipe olhando apenas o preço por assento.

Para uma comparação mais detalhada entre os dois concorrentes, leia Greptile vs CodeRabbit. Para ampliar a seleção, veja alternativas ao CodeRabbit e melhores ferramentas de revisão de código com IA para equipes pequenas.

Em quais cenários o Bugbot pode trazer mais valor?

Eu priorizaria fluxos em que deixar um defeito passar custa mais do que a atenção necessária para avaliar um apontamento. Os casos abaixo são usos possíveis, ordenados por onde eu começaria, e não resultados medidos.

Os mecanismos de revisão, contexto, regras e Autofix por trás desses exemplos estão documentados no guia do Bugbot do Cursor. O valor de cada um depende do seu código e de quem faz a revisão.

O que vale a pena desenvolver em torno do Bugbot?

A oportunidade mais forte é ajudar a liderança de engenharia a entender os custos e os resultados das revisões. Criar mais um gerador de comentários é uma proposta mais difícil quando ferramentas consolidadas já fazem esse trabalho.

Um painel de custos e resultados das revisões

Uma equipe de plataforma poderia criar um painel que relacione os gastos por repositório aos problemas que os engenheiros aceitaram, descartaram ou corrigiram. O público comprador seria a liderança de engenharia. O preço de US$30/assento/mês do plano Pro do Greptile demonstra que já existe uma categoria paga de revisão, mas não prova que esses clientes pagariam por esse complemento. Preços do Greptile.

A menor versão útil combinaria os apontamentos e os registros de cobrança com uma classificação de utilidade feita por uma pessoa. A API de revisão do Cursor para Enterprise expõe dados analíticos das revisões, incluindo os problemas encontrados e o custo cobrado; o campo de custo pode não trazer um valor cobrado. Uma versão fora do Enterprise precisaria de entradas manuais autorizadas, sem presumir acesso a essa API. API e dados analíticos do Bugbot.

O ponto de atenção: comentários marcados como resolvidos são um indicador imperfeito de bugs cuja identificação trouxe valor, e uma atribuição incompleta dos gastos pode tornar o painel enganoso. Eu começaria por essa ideia porque ela responde à pergunta que volta a cada renovação: esse revisor vale o custo total?

Uma ferramenta para auditar políticas de revisão dos repositórios

Uma equipe de engenharia de plataforma poderia usar uma ferramenta que verifique se os repositórios têm a configuração aprovada do Bugbot, se faltam regras de projeto e se houve mudanças de política sem revisão. O preço mensal de US$60/desenvolvedor/mês do CodeRabbit Team mostra que as operações de revisão em equipe já fazem parte de uma categoria de produtos pagos; a disposição de comprar uma ferramenta separada de políticas ainda precisaria ser validada. Preços do CodeRabbit.

A menor versão poderia ler os arquivos dos repositórios e gerar um relatório para os responsáveis avaliarem. O ponto de atenção: as configurações pessoais têm prioridade sobre o YAML, então auditar apenas os arquivos não permite certificar o comportamento efetivo das revisões. Deixe essa limitação visível e inclua as configurações do painel no processo quando houver acesso autorizado. Precedência das configurações do Bugbot.

Mantenha explícita a aprovação do merge

Tornar a verificação do Bugbot obrigatória não significa automaticamente que problemas pendentes vão bloquear o merge. Por padrão, os apontamentos geram um resultado neutro. Exigir esse status garante que a verificação seja executada; quando disponível para sua organização, a opção de falhar diante de problemas não resolvidos transforma os apontamentos em um status de falha. Confira essa configuração antes de confiar na proteção de branches. Status das verificações do Bugbot.

Minha recomendação é usar o Bugbot como uma fonte adicional de evidências para quem revisa. Um relatório sem problemas não demonstra que a funcionalidade atende aos requisitos, e um patch gerado automaticamente precisa passar pelo mesmo rigor aplicado a qualquer outro código.

Por onde começar na segunda-feira

Escolha um repositório cujos responsáveis consigam definir quais falhas querem detectar. Peça ao administrador adequado que conclua a conexão com o provedor, ative o Bugbot nesse repositório, faça commit da configuração na branch de destino e escreva regras de revisão focadas. Defina quem será responsável pelo orçamento e tome a decisão sobre o Autofix separadamente. Durante as revisões normais, registre os apontamentos úteis, as sugestões descartadas e o tempo gasto avaliando ambos antes de ampliar a adoção.

Se você precisa incorporar relatórios de revisão ou controles de repositório ao seu fluxo de entrega, podemos ajudar com automação com IA.