Présentation

Dans le monorepo d’Anthropic, le nombre de changements quotidiens est passé de environ 2 500 en mai à plus de 30 000 en septembre. Face à ce volume, la revue manuelle ligne par ligne devient impraticable. L’équipe Claude Code a donc réorienté le processus : la plupart des vérifications sont effectuées par des agents automatisés, tandis que l’intervention humaine se limite à un seul point d’approbation, sans augmentation du taux de reverts ou d’incidents.

Flux de revue automatisée

Avant l’ouverture d’une pull request (PR), le développeur lance plusieurs « skills » : un agent recherche les bugs, un autre simplifie le diff, un troisième exécute les tests ou génère une capture d’écran. Le résultat est présenté à Claude, qui analyse le diff dans le contexte du dépôt complet et de l’intention déclarée. Claude produit alors un commentaire structuré, classé Important, Nit ou Pre‑existing. Les commentaires sont filtrés : les remarques purement stylistiques sont éliminées après un test A/B, tandis que les problèmes de sécurité ou de logique restent obligatoires.

Chaque PR reçoit un examen Claude Review avant toute lecture humaine. Le processus comprend plusieurs couches : un sous‑agent vérifie le diff, puis d’autres agents votent sur chaque constatation. Un commentaire n’est publié que si un quorum d’agents le confirme, ce qui réduit les faux positifs. Les découvertes sont ensuite résolues soit par une correction automatique (souvent pendant la nuit), soit par l’auteur du code.

Impact sur le temps humain

Les métriques de suivi incluent le nombre d’approbations humaines par PR (médiane et 95e percentile) ainsi que le temps d’attente d’une PR sur une personne. Entre juin et septembre, le nombre de PR fusionnées a plus que doublé, tandis que la part des PR nécessitant un revert a chuté de plus de 40 %. Le taux de commentaires substantifs internes est passé de 16 % à 54 %, montrant que les agents capturent la majorité des problèmes avant l’intervention humaine.

Cette optimisation ne se limite pas à la réduction du temps de lecture : elle évite également le temps consacré à la correction de bugs introduits, car les revues automatisées détectent les défauts en amont. Ainsi, le coût total en heures humaines (lecture + correction) diminue, même si le nombre de changements augmente de façon exponentielle.

Limites et perspectives

Le système repose sur la qualité des « skills » et des règles de lint intégrées dans CLAUDE.md et REVIEW.md. Lorsque les agents signalent de façon récurrente le même problème, les développeurs doivent intervenir au niveau du skill ou ajouter une règle de lint, ce qui implique un effort de maintenance continu. De plus, les revues automatisées ne peuvent pas remplacer la compréhension contextuelle profonde requise pour des décisions d’architecture ou de sécurité critiques ; ces cas restent réservés aux humains.

Enfin, la dépendance à un modèle de langage interne pose des questions de robustesse : une mauvaise interprétation du diff peut entraîner des faux positifs ou des omissions. L’équipe prévoit d’affiner les filtres de vote et d’étendre les tests de validation (ex. : simulations d’applications mobiles) afin de couvrir davantage de scénarios d’usage.