À mesure que les agents de codage gagnaient en capacités, nous passions de plus en plus de temps sur la revue. Pour résoudre ce problème, nous avons créé Bugbot, un agent de revue de code qui analyse les pull requests afin de détecter les bugs logiques, les problèmes de performance et les vulnérabilités de sécurité avant qu’ils n’atteignent la production. L’été dernier, il fonctionnait tellement bien que nous avons décidé de le mettre à disposition des utilisateurs.

Le processus de création de Bugbot a commencé par des évaluations qualitatives et a progressivement évolué vers une approche plus systématique, en utilisant une métrique personnalisée pilotée par l’IA pour optimiser la qualité.

Depuis le lancement, nous avons mené 40 expériences majeures qui ont fait passer le taux de résolution de Bugbot de 52 % à plus de 70 %, tout en faisant passer le nombre moyen de bugs signalés par exécution de 0,4 à 0,7. Cela signifie que le nombre de bugs résolus par PR a plus que doublé, passant d’environ 0,2 à près de 0,5.

#Des débuts modestes

Lorsque nous avons tenté pour la première fois de créer un agent de revue de code, les modèles n'étaient pas assez performants pour que les revues soient réellement utiles. Mais à mesure que les modèles de base se sont améliorés, nous avons réalisé que nous disposions de plusieurs moyens d'augmenter la qualité des rapports de bugs.

Nous avons expérimenté différentes configurations de modèles, de pipelines, de filtres et de stratégies astucieuses de gestion du contexte, en sondant les ingénieurs en interne au fil du temps. Dès qu'une configuration semblait produire moins de faux positifs, nous l'adoptions.

L'une des améliorations de qualité les plus efficaces que nous avons trouvée dès le début a été d'exécuter plusieurs passes de détection de bugs en parallèle et de combiner leurs résultats par vote majoritaire. Chaque passe recevait un ordre différent du diff, ce qui orientait le modèle vers différentes lignes de raisonnement. Lorsque plusieurs passes signalaient indépendamment le même problème, nous l'interprétions comme un signal plus fort que le bug était réel.

Après des semaines d'itérations qualitatives en interne, nous avons abouti à une version de Bugbot qui surpassait les autres outils de revue de code du marché et nous a donné la confiance nécessaire pour le lancer. Elle utilisait le processus suivant :

1. Lancer huit passes parallèles avec un ordre de diff aléatoire
2. Regrouper les bugs similaires dans un même groupe
3. Appliquer un vote majoritaire pour filtrer les bugs trouvés par une seule passe
4. Fusionner chaque groupe en une description unique et claire
5. Filtrer les catégories indésirables (comme les avertissements du compilateur ou les erreurs de documentation)
6. Faire passer les résultats par un modèle de validation pour détecter les faux positifs
7. Supprimer les doublons par rapport aux bugs signalés lors des exécutions précédentes

#Du prototype à la production

Pour rendre Bugbot réellement utilisable, nous avons dû investir dans un ensemble de systèmes fondamentaux en plus de la logique de revue principale. Cela passait par un accès au dépôt rapide et fiable en reconstruisant notre intégration Git en Rust et en minimisant la quantité de données que nous récupérions, ainsi que par l'ajout d'une surveillance du rate limit, d'un regroupement des requêtes et d'une infrastructure basée sur un proxy pour rester dans les contraintes imposées par GitHub.

Avec l'adoption croissante, les équipes avaient aussi besoin d'un moyen de formaliser des invariants propres à leur base de code, comme des migrations dangereuses ou une utilisation incorrecte d’API internes. En réponse, nous avons ajouté les règles Bugbot pour prendre en charge ces vérifications sans les coder en dur dans le système.

Ensemble, ces éléments ont rendu Bugbot pratique à exécuter et adaptable à des bases de code réelles. Mais ils ne nous disaient pas si la qualité s'améliorait réellement. Sans indicateur pour mesurer les progrès, nous ne pouvions pas évaluer quantitativement les performances de Bugbot dans la nature, ce qui limitait jusqu'où nous pouvions le pousser.

#Mesurer ce qui compte

Pour résoudre ce problème, nous avons mis au point une métrique appelée taux de résolution. Elle utilise l’IA pour déterminer, au moment où la PR est fusionnée, quels bugs ont réellement été corrigés par l’auteur dans le code final. Lors de la mise au point de cette métrique, nous avons effectué des vérifications ponctuelles sur un échantillon d’exemples en interne avec l’auteur de la PR et constaté que le LLM les classait presque tous correctement comme résolus ou non.

Les équipes nous demandent souvent comment évaluer l’impact de Bugbot pour elles, c’est pourquoi nous faisons ressortir cette métrique de manière bien visible dans le dashboard. Pour les équipes qui évaluent l’efficacité, c’est un signal bien plus clair que des retours anecdotiques ou des réactions à des commentaires. Le taux de résolution répond directement à la question de savoir si Bugbot trouve de vrais problèmes que les ingénieurs corrigent.

#Optimisation itérative (hill-climbing)

La définition du taux de résolution a changé notre façon de construire Bugbot. Pour la première fois, nous pouvions faire de l’optimisation itérative sur la base de signaux réels, plutôt que sur une simple impression. Nous avons commencé à évaluer les changements en ligne en utilisant les taux de résolution réels, et hors ligne en utilisant BugBench, un benchmark composé de vrais diffs de code avec des bugs annotés par des humains.

Nous avons lancé des dizaines d’expériences sur les modèles, les prompts, les nombres d’itérations, les validateurs, la gestion du contexte, le filtrage par catégorie et les conceptions à base d’agents. Fait surprenant, nombre de ces changements ont dégradé nos métriques. Il s’est avéré qu’un grand nombre de nos jugements initiaux issus des premières analyses qualitatives étaient corrects.

#Architecture agentique

Nous avons constaté les plus grands gains lorsque, cet automne, nous avons fait évoluer Bugbot vers une conception entièrement agentique. L'agent pouvait raisonner à partir du diff, appeler des outils et décider où creuser davantage au lieu de suivre une séquence fixe d'analyses.

La boucle agentique nous a obligés à repenser la façon de concevoir les prompts. Avec les premières versions de Bugbot, nous devions contraindre les modèles pour minimiser les faux positifs. Mais avec l'approche agentique, nous avons rencontré le problème inverse : il était trop prudent. Nous sommes passés à des prompts plus agressifs qui encourageaient l'agent à examiner chaque motif suspect et à privilégier le signalement des problèmes potentiels.

De plus, l'architecture agentique a ouvert une surface d'expérimentation plus riche. Nous avons pu déplacer davantage d'informations du contexte statique vers le contexte dynamique, en faisant varier la quantité de contexte initial que le modèle recevait et en observant la façon dont il s'adaptait. Le modèle récupérait systématiquement le contexte supplémentaire dont il avait besoin à l'exécution, sans exiger que tout soit fourni à l'avance.

La même configuration nous permet également d'itérer directement sur l'ensemble d'outils lui‑même. Comme le comportement du modèle est façonné par les outils qu'il peut appeler, même de petits changements dans la conception ou la disponibilité des outils avaient un impact disproportionné sur les résultats. Au fil de plusieurs itérations, nous avons ajusté et affiné cette interface jusqu'à ce que le comportement du modèle s'aligne systématiquement sur nos attentes.

#Et la suite

Aujourd'hui, Bugbot examine plus de deux millions de PR par mois pour des clients comme Rippling, Discord, Samsara, Airtable et Sierra AI. Nous utilisons également Bugbot sur l'ensemble du code interne chez Cursor.

Pour la suite, nous nous attendons à ce que de nouveaux modèles apparaissent régulièrement, avec des forces et des faiblesses différentes, provenant à la fois d'autres fournisseurs et de nos propres efforts d'entraînement. Continuer à progresser nécessite de trouver la bonne combinaison de modèles, de conception de l’infrastructure et de processus de revue. Bugbot est aujourd'hui bien meilleur que Bugbot au moment de son lancement. D'ici quelques mois, nous nous attendons à ce qu'il soit à nouveau nettement meilleur.

Nous construisons déjà cet avenir. Nous venons de lancer Bugbot Autofix en Beta, qui déclenche automatiquement un Cloud Agent pour corriger les bugs trouvés pendant les revues de PR. Les prochaines fonctionnalités majeures incluent la possibilité pour Bugbot d'exécuter du code pour vérifier ses propres rapports de bugs et d'effectuer des recherches approfondies lorsqu'il rencontre des problèmes complexes. Nous expérimentons également une version toujours active qui analyse en continu votre base de code plutôt que d'attendre les pull requests.

Nous avons déjà fait d'énormes progrès, qui n'auraient pas été possibles sans les contributions de plusieurs membres clés de l'équipe, notamment Lee Danilek, Vincent Marti, Rohan Varma, Yuri Volkov, Jack Pertschuk, Michiel De Jong, Federico Cassano, Ravi Rahman et Josh Ma. Ensemble, notre objectif reste d'aider vos équipes à maintenir la qualité du code à mesure que vos workflows de développement avec l’IA changent d’échelle.

Lire la documentation ou essayer Bugbot dès aujourd'hui.