Ouvrez une pull request avec la plupart des outils de revue de code IA et vous obtenez un mur de commentaires. Un par constat. Un par chipotage. Un par « envisagez d’extraire ceci dans une fonction utilitaire ». Poussez un correctif, relancez la revue, et vous obtenez un second mur empilé sur le premier. Maintenant votre coéquipier doit faire défiler deux murs pour trouver le commentaire qui compte vraiment.
Surmado Code Review fonctionne différemment. Une PR, un commentaire. Relancez-le et le même commentaire est édité sur place.
Comment ça fonctionne
Quand Scout examine une pull request, chaque constat va dans un seul commentaire structuré. Les niveaux de sévérité en haut. Les problèmes eux-mêmes en dessous. Un bref résumé à la fin pour que le relecteur humain sache où regarder en premier.
Quand vous poussez un correctif et commentez /rerun-review, Scout lit deux choses.
- Le nouveau diff.
- La revue précédente qu’il a postée.
Puis il édite le même commentaire sur place. Les problèmes que vous avez corrigés sont marqués comme résolus. Ceux que vous n’avez pas corrigés sont re-signalés avec une note indiquant qu’ils avaient déjà été relevés auparavant. Les nouveaux problèmes issus du nouveau code atterrissent en bas.
Le fil de commentaires de votre PR ne grandit pas. La revue unique devient simplement plus précise à chaque fois que vous poussez.
Pourquoi c’est important
Un fil de commentaires de PR est censé être une conversation, pas un panneau d’affichage. Chaque commentaire supplémentaire qu’un bot poste est un commentaire que votre coéquipier doit faire défiler pour trouver celui qui compte. Après quelques cycles, plus personne n’en lit aucun.
C’est le même compromis évoqué dans notre article sur les alternatives à CodeRabbit et notre analyse de Greptile. Le taux de détection n’est pas la seule métrique. Le rapport signal/bruit en est une aussi. Un relecteur qui détecte tout mais l’enfouit dans 40 commentaires a la même valeur pratique qu’un relecteur qui ne détecte rien.
La partie « conscient de ce qu’il a dit avant »
Éditer sur place est une chose. La partie la plus difficile est de rendre la relance utile, pas seulement plus courte.
La relance de Scout s’appuie sur la revue précédente. S’il vous a signalé lors du premier passage qu’une fonction manquait de rédaction des données PII, la relance examine spécifiquement si cette fonction rédige désormais les données PII. Pas « y a-t-il un problème de PII quelque part », mais « le problème que j’ai signalé a-t-il été corrigé ». Si oui, ce constat passe dans une section résolue. Si non, il reste ouvert avec un marqueur indiquant que c’est la deuxième fois qu’il est relevé.
Cette boucle de rétroaction est la raison pour laquelle « un seul commentaire » fonctionne. Le commentaire porte son propre historique. Vous n’avez pas besoin d’un fil chronologique de commentaires de bot pour vous souvenir de ce qui a été signalé avant. Le commentaire actuel le sait déjà.
À quoi ça ressemble en pratique
Poussez une PR. Recevez un commentaire de Scout, ancré aux règles de votre fichier STANDARDS.MD. Lisez-le. Corrigez ce qui compte. Poussez à nouveau. Commentez /rerun-review. Le même commentaire se met à jour avec ce qui est résolu, ce qui reste ouvert et ce qui est nouveau. Pas de nouveau fil. Pas de « vous avez été notifié 17 fois ».
Si vous voulez l’histoire complète de la façon dont l’outil a été construit, notre article sur le vibe-coding couvre les parties que nous avons façonnées à la main et celles que nous avons laissé Scout construire.
En résumé
Le spam de commentaires de PR n’est pas une fonctionnalité. C’est une habitude que d’autres outils ont prise parce que poster plus de commentaires est plus facile que de savoir lesquels comptent.
Surmado Code Review s’en passe. Un commentaire. Édité à chaque relance. Conscient de ce qu’il a déjà dit.
Essayez Surmado Code Review pour 15 $ par mois. 100 PR. Votre STANDARDS.MD. Chaque PR, avant que vos coéquipiers ne l’ouvrent.