Le goulot d'étranglement de la revue de code vient de céder
La revue de code, un goulot d'étranglement traditionnel dans le développement logiciel, connaît un changement tectonique. Le monorepo principal d'Anthropic, par exemple, est passé d'environ 2 500 modifications quotidiennes en mai à plus de 30 000 lors de sa journée la plus chargée en septembre. Parallèlement, Claude écrit désormais environ 90 % du propre code de Claude Code, rendant l'inspection humaine ligne par ligne impraticable.
Au lieu de viser une revue humaine de chaque ligne, les équipes d'Anthropic se demandent désormais : « Qu'est-ce qui pourrait mal tourner avec ce changement ? » et « Quel contrôle — automatisé ou humain — est le mieux adapté pour le détecter ? » Cette approche pragmatique garantit que la plupart des pull requests (PRs) sont fusionnées avec au plus une intervention humaine, souvent celle de l'auteur lui-même. Boris Cherny, créateur de Claude Code, publie 20 à 30 PRs par jour, un rythme impossible avec les méthodes conventionnelles.
Ce nouveau système a donné des résultats remarquables. Entre juin et septembre, le nombre de PRs fusionnées a plus que doublé. Fait crucial, la part des PRs ayant dû être annulées a chuté de 40 %, démontrant qu'une charge de revue humaine réduite n'équivaut pas nécessairement à davantage de défauts. Ce changement souligne une réévaluation fondamentale de la manière dont nous assurons la qualité du code à grande échelle.
Un bug doit survivre à un parcours du combattant
Les bugs font face à un parcours du combattant composé de contrôles automatisés conçus pour détecter les problèmes avant même que des yeux humains ne voient une pull request. Claude exécute d'abord des tests, compile l'application ou compare des captures d'écran au sein de la session de l'auteur pour auto-vérifier son travail. Ensuite, un sous-agent disposant d'un contexte frais examine indépendamment le diff, garantissant qu'aucun biais de la session de création ne contamine l'évaluation initiale.
Une fois qu'une pull request est créée, un produit de revue Claude dédié prend le relais, déployant plusieurs agents pour rechercher des bugs simultanément. Un groupe distinct d'agents vote ensuite sur ces conclusions, et ce n'est que si un nombre suffisant d'entre eux est d'accord qu'un commentaire est publié, réduisant considérablement les faux positifs.
Le système apprend de ses erreurs, transformant les problèmes récurrents en lint rules ou en conseils spécifiques dans les fichiers CLAUDE.md. Cela garantit que les erreurs courantes sont traitées en amont, empêchant leur réintroduction. Inversement, si le réviseur signale de manière répétée du code acceptable, des fichiers review.md, rédigés par les propriétaires du code, clarifient ce qui constitue un échec dans cette zone de code spécifique.
Avant la fusion, un agent de security review distinct scrute le code à la recherche de vulnérabilités, et les contrôles CI standards — incluant les tests, la vérification de type et le linting — doivent être validés. Ce modèle en couches de « fromage suisse » garantit que même si une défense présente un « trou », les couches suivantes sont susceptibles de détecter le défaut, permettant à Anthropic de mettre à l'échelle les fusions sans sacrifier la stabilité.
Le réviseur a aussi besoin d'un réviseur
La revue humaine reste une protection critique, bien que hiérarchisée. Les changements à faible risque provenant d'auteurs de confiance, comme les mises à jour de documentation ou le travail sous feature-flag, contournent souvent l'approbation humaine. Les changements ordinaires ou les modifications dans des zones sensibles exigent une validation humaine, tandis que les chemins à haut risque en exigent deux. Les agents classificateurs d'Anthropic déterminent ces niveaux, un second agent validant l'exigence de revue humaine.
L'évaluation se concentre sur l'impact dans le monde réel. Les bugs liés à des incidents sont convertis en cas de test quotidiens pour le réviseur, garantissant que le système apprend des échecs passés. Seuls les changements de prompt, de modèle ou de règle qui améliorent manifestement les performances sans générer de bruit excessif sont conservés. Cette boucle de rétroaction itérative affine constamment le processus de révision automatisé. Pour plus de détails sur ce système complexe, consultez How the Claude Code team does code review.
Cependant, les révisions d'agent à agent peuvent piéger le système dans une boucle. Des critiques excessives déclenchent des modifications répétées et des révisions ultérieures, comme l'a montré une PR ayant enregistré plus de 50 cycles. Pour contrer cela, Anthropic a limité le nombre de cycles de révision et a orienté les révisions ultérieures pour qu'elles se concentrent uniquement sur les nouveaux changements. Cette intervention a permis de faire passer le taux de PR validées après un seul cycle de 65 % à 78 %, tandis que celles nécessitant cinq cycles ou plus ont chuté de 9 % à 1,5 %.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Ce que les équipes peuvent copier — et ce qu'elles ne peuvent pas
Le passage à l'échelle spectaculaire d'Anthropic offre un aperçu de l'ingénierie nativement IA, mais toutes les équipes ne peuvent pas simplement copier-coller leur approche. Bien que les PR fusionnées aient plus que doublé et que la part des annulations (reverts) ait chuté de 40 %, les mesures publiées ne prouvent pas de manière définitive qu'un nombre moins élevé de changements totaux a causé des problèmes. Si le volume de changements a suffisamment augmenté, le nombre absolu d'annulations pourrait toujours avoir augmenté, même avec un pourcentage plus faible.
Répliquer le système de révision multi-agents d'Anthropic exige des ressources importantes et des outils internes hautement spécialisés. La plupart des organisations manquent de budget en jetons, de capacité de calcul ou des boucles de rétroaction sophistiquées qui permettent à Claude d'auto-améliorer ses capacités de révision. Il ne s'agit pas d'une intégration rapide ; c'est un changement architectural fondamental.
Néanmoins, il existe des leçons pragmatiques pour toute équipe. Guidez les agents avec des instructions concises et automatisez les vérifications des erreurs récurrentes plutôt que de les corriger de manière itérative. Limitez les boucles de révision — Anthropic a appris à ses dépens que les agents peuvent rester bloqués pendant plus de 50 cycles. Réservez l'attention humaine aux décisions vraiment importantes, comme les choix architecturaux ou le code de facturation à haut risque. En fin de compte, la règle « vous le déployez, vous en êtes responsable » reste primordiale : la responsabilité des résultats incombe toujours aux humains.
Foire aux questions
Anthropic demande-t-il à des humains de réviser chaque changement effectué par Claude Code ?
Non. La révision humaine dépend du risque : certains changements fiables et à faible risque peuvent être fusionnés sans approbation humaine, tandis que les changements sensibles ou à haut risque nécessitent l'intervention d'une ou deux personnes.
Comment Anthropic révise-t-il le code généré par l'IA ?
Son processus combine des tests locaux, une révision par agent avec un contexte actualisé, des vérifications de bugs et de sécurité multi-agents, une intégration continue (CI), une révision humaine basée sur le risque et une surveillance en production.
Le taux d'annulation d'Anthropic prouve-t-il qu'il y a eu moins de bugs en production ?
Pas par lui-même. La part des PR fusionnées qui ont été annulées a chuté de 40 %, mais le volume de PR fusionnées a plus que doublé, et Anthropic n'a pas publié les chiffres sous-jacents.
Que peuvent copier les petites équipes d'ingénierie auprès d'Anthropic ?
Utilisez des vérifications automatisées pour les risques répétables, gardez les instructions des agents ciblées, limitez les cycles de révision, adaptez la révision humaine au risque et faites en sorte que la personne qui déploie un changement soit responsable de son résultat.