À medida que agentes de código se tornaram mais capazes, passamos a gastar mais tempo revisando código. Para resolver isso, criamos o Bugbot, um agente de revisão de código que analisa pull requests (PRs) em busca de bugs de lógica, problemas de performance e vulnerabilidades de segurança antes que cheguem à produção. No verão passado, ele estava funcionando tão bem que decidimos lançá-lo para os usuários.

O processo de construção do Bugbot começou com avaliações qualitativas e evoluiu gradualmente para uma abordagem mais sistemática, usando uma métrica personalizada baseada em IA para otimizar continuamente a qualidade.

Desde o lançamento, realizamos 40 grandes experimentos que aumentaram a taxa de resolução do Bugbot de 52% para mais de 70%, ao mesmo tempo em que elevaram o número médio de bugs sinalizados por execução de 0,4 para 0,7. Isso significa que o número de bugs resolvidos por PR mais que dobrou, de aproximadamente 0,2 para cerca de 0,5.

#Começos humildes

Quando tentamos criar nosso primeiro agente de revisão de código, os modelos não eram suficientemente capazes para que as revisões fossem úteis. Mas, à medida que os modelos de base melhoraram, percebemos que tínhamos várias maneiras de aumentar a qualidade dos relatórios de bugs.

Experimentamos diferentes configurações de modelos, pipelines, filtros e estratégias inteligentes de gerenciamento de contexto, consultando engenheiros internamente ao longo do processo. Se parecia que uma configuração tinha menos falsos positivos, nós a adotávamos.

Uma das melhorias de qualidade mais eficazes que encontramos logo no início foi executar várias passadas de detecção de bugs em paralelo e combinar seus resultados com votação majoritária. Cada passada recebia uma ordem diferente do diff, o que conduzia o modelo a diferentes linhas de raciocínio. Quando várias passadas marcavam de forma independente o mesmo problema, tratávamos isso como um sinal mais forte de que o bug era real.

Depois de semanas de iterações qualitativas internas, chegamos a uma versão do Bugbot que superou outras ferramentas de revisão de código do mercado e nos deu confiança para lançá-lo. Ele seguia este fluxo:

1. Executar oito passadas paralelas com ordem de diff aleatorizada
2. Combinar bugs semelhantes em um único grupo
3. Votação majoritária para filtrar bugs encontrados em apenas uma passada
4. Unir cada grupo em uma descrição única e clara
5. Filtrar categorias indesejadas (como avisos do compilador ou erros de documentação)
6. Passar os resultados por um modelo validador para capturar falsos positivos
7. Remover duplicatas em relação a bugs enviados em execuções anteriores

#Do protótipo à produção

Para tornar o Bugbot utilizável na prática, tivemos que investir em um conjunto de sistemas fundamentais em paralelo à lógica central de review. Isso incluiu tornar o acesso ao repositório rápido e confiável, recriando nossa integração com o Git em Rust e minimizando a quantidade de dados que buscávamos, além de adicionar monitoramento de rate limit, agrupamento de requisições e infraestrutura baseada em proxy para operar dentro das limitações do GitHub.

Conforme a adoção cresceu, as equipes também precisaram de uma forma de codificar invariantes específicos da base de código, como migrações inseguras ou uso incorreto de APIs internas. Em resposta, adicionamos as regras do Bugbot para dar suporte a essas verificações sem precisar fixá-las diretamente no sistema.

Juntos, esses componentes tornaram o Bugbot prático de executar e adaptável a bases de código reais. Mas eles não nos diziam se a qualidade estava realmente melhorando. Sem uma métrica para medir o progresso, não conseguíamos avaliar quantitativamente o desempenho do Bugbot em produção, o que colocava um teto em até onde poderíamos levá-lo.

#Medindo o que importa

Para resolver esse problema, criamos uma métrica chamada taxa de resolução. Ela usa IA para determinar, no momento do merge da PR, quais bugs foram realmente resolvidos pelo autor no código final. Ao desenvolver essa métrica, fizemos verificações pontuais internamente com o autor de cada PR e descobrimos que o LLM classificou corretamente quase todos os casos como resolvidos ou não.

As equipes frequentemente nos perguntam como avaliar o impacto que o Bugbot está gerando para elas, então damos destaque a essa métrica no dashboard. Para equipes avaliando a eficácia, é um sinal muito mais claro do que feedbacks anedóticos ou reações em comentários. A taxa de resolução responde diretamente se o Bugbot está encontrando problemas reais que os engenheiros corrigem.

#Melhoria incremental

Definir a taxa de resolução mudou como construímos o Bugbot. Pela primeira vez, conseguimos fazer melhoria incremental com base em sinais reais, e não apenas em intuição. Passamos a avaliar mudanças online usando as taxas reais de resolução e offline usando o BugBench, um benchmark selecionado de diffs de código reais com bugs anotados por humanos.

Executamos dezenas de experimentos envolvendo modelos, prompts, contagem de iterações, validadores, gerenciamento de contexto, filtragem por categoria e arquiteturas de agentes. Muitas mudanças, surpreendentemente, pioraram nossas métricas. No fim, descobrimos que vários dos nossos julgamentos iniciais das primeiras análises qualitativas estavam corretos.

#Arquitetura baseada em agentes

Vimos os maiores ganhos quando, neste outono, migramos o Bugbot para um design totalmente baseado em agentes. O agente podia raciocinar sobre o diff, chamar ferramentas e decidir onde investigar mais a fundo, em vez de seguir uma sequência fixa de passes.

O loop baseado em agentes nos forçou a repensar os prompts. Com as primeiras versões do Bugbot, precisávamos restringir os modelos para minimizar falsos positivos. Mas com a abordagem baseada em agentes encontramos o problema oposto: ele estava cauteloso demais. Passamos a usar prompts mais agressivos, que incentivavam o agente a investigar todos os padrões suspeitos e a pecar pelo excesso ao sinalizar possíveis problemas.

Além disso, a arquitetura baseada em agentes abriu um espaço mais rico para experimentação. Conseguimos mover mais informações para fora do contexto estático e para dentro do contexto dinâmico, variando quanto contexto inicial o modelo recebia e observando como ele se adaptava. O modelo buscava de forma consistente o contexto adicional de que precisava em tempo de execução, sem exigir que tudo fosse fornecido com antecedência.

A mesma configuração nos permite iterar diretamente sobre o próprio conjunto de ferramentas. Como o comportamento do modelo é moldado pelas ferramentas que ele pode chamar, mesmo pequenas mudanças no design ou na disponibilidade das ferramentas tiveram um impacto desproporcional nos resultados. Ao longo de várias rodadas de iteração, ajustamos e refinamos essa interface até que o comportamento do modelo ficasse de forma consistente alinhado com nossas expectativas.

#O que vem a seguir

Hoje, o Bugbot revisa mais de dois milhões de PRs por mês para clientes como Rippling, Discord, Samsara, Airtable e Sierra AI. Também executamos o Bugbot em todo o código interno da Cursor.

Olhando adiante, esperamos que novos modelos surjam regularmente, com diferentes pontos fortes e fracos, tanto de outros provedores quanto dos nossos próprios esforços de treinamento. O progresso contínuo exige encontrar a combinação certa de modelos, design do harness e estrutura de revisão. O Bugbot de hoje é várias vezes melhor do que o Bugbot no lançamento. Em alguns meses, esperamos que ele esteja novamente significativamente melhor.

Já estamos construindo esse futuro. Acabamos de lançar o Bugbot Autofix em Beta, que inicia automaticamente um Cloud Agent para corrigir bugs encontrados durante as revisões de PR. As próximas capacidades principais incluem permitir que o Bugbot execute código para verificar seus próprios relatórios de bugs e habilitar análises aprofundadas quando encontrar problemas complexos. Também estamos experimentando uma versão sempre ativa que analisa continuamente sua base de código em vez de esperar por pull requests.

Já avançamos muito até aqui, o que não seria possível sem as contribuições de alguns membros-chave da equipe, incluindo Lee Danilek, Vincent Marti, Rohan Varma, Yuri Volkov, Jack Pertschuk, Michiel De Jong, Federico Cassano, Ravi Rahman e Josh Ma. Juntos, nosso objetivo continua sendo ajudar suas equipes a manter a qualidade do código conforme seus fluxos de desenvolvimento com IA escalam.

Leia a documentação ou experimente o Bugbot hoje.