Devin Review 2.0 réduit de 82% le coût de la revue de code : une PR pour $0,25–0,75

Imaginez un développeur qui, avec l'aide d'un agent, assemble une dizaine de pull requests (PR, un ensemble de modifications en attente de vérification avant fusion dans le code principal) en une journée, alors qu'un relecteur humain n'a le temps d'en lire attentivement que deux ou trois. Les autres restent dans la file d'attente ou passent en lecture « en diagonale ». Les créateurs de Devin estiment qu'il faut confier la première ligne de vérification à un autre agent, et ils ont lancé Devin Review 2.

0. L'argument central de cette version, c'est le prix : depuis août, la revue d'une PR coûte 82% de moins (soit environ cinq fois moins) et revient désormais à $0,25–0,75. À ce tarif, on peut lancer le bot sur chaque PR, comme des tests automatisés en CI, plutôt que de sélectionner les PR « importantes » à la main.

Combien ça coûte et ce qu'on obtient

Selon l'entreprise, les économies viennent de deux sources : une meilleure combinaison de modèles pour les différentes étapes de la revue, et l'optimisation de l'infrastructure qui les entoure (le harness). La qualité n'en a pas souffert : le nombre moyen de bugs détectés est passé de 1,22 à 1,32 par PR.

Quelques autres chiffres tirés du blog. Le temps médian de revue est passé de 139 à 94 secondes, soit environ 1,5 fois plus rapide. Environ 80% des PR coûtent moins d'un dollar, en comptant tous les pushs sur la branche. Quant au coût moyen d'un bug réellement corrigé chez les clients, il s'établit autour de $2,25. Cela ne remplace pas l'humain, mais la comparaison avec une heure de travail d'ingénieur tourne à l'avantage du bot.

Comment ne pas payer deux fois pour la même chose

La principale évolution technique est la revue incrémentale. Lorsqu'un commit supplémentaire est ajouté à une PR, Devin Review n'analyse que les parties modifiées, et non la PR entière. Ce mode est activé par défaut. Il présente deux avantages : la facture baisse, car chaque push est plus petit que l'ensemble de la PR, et le bruit diminue, car les nouvelles remarques portent sur les modifications récentes au lieu de répéter les anciennes.

La revue peut être déclenchée de plusieurs façons :

• par le commentaire /devin review dans GitHub ou GitLab ;
• depuis la page Devin Review dans Devin Cloud ou Devin Desktop ;
• automatiquement, quand la PR est prête pour la revue, ou à chaque push.

Le lancement automatique se règle par des règles : on peut inclure les brouillons et filtrer par chemins de fichiers, branches et étiquettes. Les clients s'en servent pour ne pas dépenser d'argent sur des PR de faible valeur. Il existe aussi une limite de dépenses par PR, de sorte qu'une PR qui grossit sans fin ne fera pas exploser la facture. Par ailleurs, le bot construit une « visite guidée » de la PR : il explique brièvement ce qui a changé et où regarder, ce qui aide l'humain à entrer dans le contexte. Cette visite peut elle aussi être mise à jour à chaque push.

Couplage avec Devin et réglages fins

Devin Review sait vérifier des PR provenant de n'importe quelle source, mais, selon ses créateurs, il fonctionne mieux associé à Devin lui-même. Dans cette configuration, l'agent traite chaque remarque et décide de la corriger, de la rejeter ou de la transmettre à un humain. Quand le développeur revient dans la session, il ne reste que les vrais bugs et les décisions litigieuses.

Deux modes ont été ajoutés. Le premier concerne les niveaux d'effort. Par défaut, la revue est réglée pour économiser, mais dans le code de facturation ou de sécurité, un bug manqué coûte bien plus cher que la vérification.

Pour ces zones, il y a Devin Review Ultra : une vérification plus minutieuse et plus chère. Le second mode, Custom Reviewers, est encore en bêta. Il s'agit de relecteurs personnalisés qui suivent vos propres instructions.

En interne, l'entreprise les utilise pour vérifier les pratiques de sécurité du backend, les migrations de bases de données sûres, les requêtes SQL performantes et les composants d'interface accessibles. Chaque relecteur peut avoir ses propres règles de déclenchement, ses trouvailles remontent dans le rapport commun et dans la correction automatique de Devin, et ses dépenses sont encadrées par les mêmes limites.

Que faire de tout ça

En pratique : si une revue coûte moins d'un dollar, il est plus rentable de l'activer sur toutes les PR que de choisir à la main. Il est raisonnable de commencer par le lancement automatique sur les PR prêtes, d'écarter les petites modifications avec des filtres par chemins et étiquettes, et de réserver Ultra aux paiements et à l'autorisation. Custom Reviewers mérite un essai sur les remarques que votre équipe répète sans cesse en revue.

Il y a aussi des réserves. Tous les chiffres proviennent du blog de l'entreprise, et les « 1,32 bug par PR » sont une moyenne sur les clients, sans comparaison avec des outils indépendants. La métrique des « bugs détectés » ne dit pas combien d'entre eux sont réellement importants. Il vaut donc mieux observer pendant une ou deux semaines, sur votre propre dépôt, la part de remarques utiles et la facture réelle avant de faire du bot une étape obligatoire de la CI.