Se você usou Bugbot, você conhece o padrão: abre um PR, espera, vai tomar um café, volta, lê os comentários. A review funcionava, mas a espera era real — cerca de cinco minutos por execução. Em 10 de junho, o Cursor lançou uma atualização que praticamente mata a espera, e o porquê por trás é mais interessante do que os números em si.
O destaque: o tempo médio de review do Bugbot caiu de ~5 minutos para ~90 segundos. Além disso, encontra cerca de 10% mais bugs por review (0,62 vs 0,56 em média), e custa ~22% menos por execução. São os números próprios do Cursor — auto-reportados pelo fabricante, sem validação independente — então leia-os como direção, não como evangelho. Mas a direção é íngreme.
O que realmente mudou
Os ganhos vêm do Composer 2.5, o modelo próprio do Cursor, que agora alimenta o Bugbot. Essa é a parte para parar um segundo — voltamos a isso.
Na prática, há uma nova forma de usá-lo. Agora você pode executar uma review antes de fazer push, direto do seu agente:
/review— pergunta qual agente executar (Bugbot, Security Review, ou ambos)/review-bugbot— executa o Bugbot diretamente/review-security— executa o agente de Security Review diretamente
E o detalhe que te poupa de trabalhar em vão: /review sincroniza com o Bugbot no GitHub e GitLab. Se você o executar localmente e depois abrir um PR com o mesmo diff, o Bugbot o reconhece, pula a re-review, e deixa um comentário avisando que já revisou esse diff. Você não paga duas vezes, não lê os mesmos comentários duas vezes.
Também há uma configuração nova para revisar apenas o que é novo desde a última review, assim o feedback se mantém focado nas suas últimas mudanças em vez de re-debater toda a branch.
Tudo isso está no Cursor 3.7+ e em cursor.com/agents. O suporte em CLI está a caminho, mas ainda não chegou.
Por que o pre-push muda a conta
Aqui está a mudança de workflow. O padrão antigo era: escreve código → push → abre PR → espera a review → corrige → push novamente. O Bugbot vivia no PR, o que significava que a review era um checkpoint depois que você já declarou o trabalho “suficientemente pronto para compartilhar”.
Execute /review antes do push e a review sobe no fluxo, no mesmo loop onde você ainda está editando ativamente. Você pega os erros antes de eles serem públicos, antes de a notificação disparar para um colega, antes de o diff ser algo que você tenha que defender. O comportamento de sincronização com o PR significa que movê-lo mais cedo não custa nada — você não está adicionando uma etapa, está relocalizando uma.
Uma review de 90 segundos é o que torna isso viável. A cinco minutos, executar a review em cada pre-push é um atrito que você vai pular sob deadline. A 90 segundos, é mais ou menos o custo de reler seu próprio diff, coisa que você deveria estar fazendo de qualquer forma.
Onde não se encaixa
Se seu time já tem um pipeline de review humana maduro e de baixo volume — diffs pequenos, turnaround rápido, reviewers que conhecem o codebase de memória — uma passada automática em pre-push adiciona mais ruído do que sinal. E se sua organização bloqueia modelos proprietários por políticas de dados, saiba que o Bugbot respeita as listas de bloqueio de modelos, mas a performance do destaque vem especificamente do Composer 2.5; bloqueie-o e os números mudam. Esta é uma ferramenta para times que lançam um alto volume de PRs onde o gargalo é a atenção do reviewer, não para o workshop de duas pessoas que se revisam o código em tempo real.
A parte para os CTOs que estão lendo
Saia um passo do feature e veja o lance. O Cursor não fez o Bugbot 3x mais rápido tuning prompts contra o frontier model de outro. Chegaram lá treinando seu próprio modelo — Composer 2.5 — e apontando-o para um trabalho específico e bem definido: revisar código.
Essa é a tendência para seguir. A primeira onda de ferramentas de AI dev era uma camada fina sobre um frontier model emprestado; a diferenciação estava no UX. O que o Cursor está sinalizando aqui é a fase seguinte: fabricantes treinando modelos verticais tuning para uma única tarefa — review, neste caso — onde controlam a curva de custo, a latência e o teto de qualidade em vez de alugar os três a um laboratório frontier.
Para qualquer um que esteja avaliando gastos em ferramentas, essa é a pergunta que convém começar a fazer a cada fabricante: o que estou pagando, é um wrapper, ou eles são donos do modelo embaixo do feature que realmente uso? Porque o fabricante que é dono do modelo é quem pode te entregar um corte de custo de 22% e um 3x de velocidade em uma única entrada de changelog — e continuar fazendo isso.