Nous avons déjà dit que Claude écrit environ 90 % du code de Claude Code lui-même. Alors, comment examinons-nous le code au volume où nous le produisons ? Est-ce que quelqu'un lit encore le code ? Et si quelque chose casse, qui le repère ? Cet article présente le flux de revue de code de l'équipe Claude Code et son évolution. De juin à septembre, le nombre de pull requests fusionnées dans la base de code de Claude Code a plus que doublé, tandis que la part de celles qui ont dû être annulées a baissé de plus de 40 %. Nous n'avons pas supprimé la revue. Mais nous avons déplacé l'essentiel de la lecture vers des machines, optimisées pour le temps et l'attention humaine, et nous avons beaucoup investi pour rendre la correction des erreurs rapide et facile.
Lorsque des agents écrivent du code, le nombre de modifications augmente rapidement. Dans le monorepo d'Anthropic, les modifications intégrées par jour sont passées d'environ 2 500 en mai à plus de 30 000 en septembre de cette année. Claude Code vit dans son propre dépôt, séparé du monorepo, mais il subit lui aussi une forte pression. Quand on livre à ce rythme, une revue manuelle ligne par ligne est extrêmement difficile, voire impossible. La revue de code remplit deux fonctions : trouver et corriger les problèmes avant la mise en production, et construire un contexte commun et une compréhension partagée de la base de code au sein de l'équipe. Cet article se concentre surtout sur la première fonction, mais nous reviendrons sur la seconde vers la fin.
Nous pensons que « un humain a-t-il lu le code ? » est un indicateur imprécis de « qu'est-ce qui pourrait mal tourner avec cette modification, et quel contrôle, automatisé ou humain, est le bon pour le détecter ? ». Poser cette question a aussi changé le moment où la revue a lieu. Auparavant, la revue était une barrière en bout de chaîne : on écrit le code, on ouvre une PR, on attend son collègue. Aujourd'hui, la revue tourne en continu, un peu comme un correcteur orthographique pendant qu'on écrit. La plupart des modifications ont déjà été relues et corrigées par Claude au moins une fois avant qu'un humain ne soit sollicité. Cela attrape la majorité des erreurs courantes et réserve l'attention de l'équipe aux questions de plus haut niveau et à un examen plus approfondi.
La ressource rare : le temps et l'attention humains. Nous voulons préserver le temps et l'attention humains pour les problèmes que seuls les humains peuvent résoudre, et nous assurer que les contrôles automatisés captent le reste. Au rythme actuel des modifications, il reste une quantité incroyable de travail pour les humains, et notre équipe rencontre presque chaque jour des défis nouveaux et inédits. Le temps humain couvre les deux côtés du coût de la revue : le temps que les gens passent à relire, et celui qu'ils passent à réparer ce que le mauvais code casse. Réduire le premier ne sert à rien si ce temps réapparaît dans le second. L'objectif est donc que la plupart des pull requests des dépôts de Claude Code (la CLI, les applications de bureau et web, et les applications mobiles) soient fusionnées avec au plus un humain dans la boucle, qui peut être l'auteur, sans hausse des annulations ni des incidents. Pour mesurer le temps humain, nous suivons le nombre d'approbations humaines par PR (médiane et 95e percentile), les commentaires humains et le temps d'attente d'une PR après une personne. Les taux d'annulation et d'incident sont le garde-fou : s'ils augmentent, nous n'avons pas économisé de temps humain, nous l'avons simplement déplacé.
La vie d'une modification. Une modification typique, depuis l'ordinateur portable d'un ingénieur (ou une session Claude dans Slack), traverse plusieurs couches de revue de code. La majeure partie du parcours est automatisée ; l'attention d'une personne se concentre là où se trouve le risque. Des couches, pas une barrière unique : six niveaux de contrôles, avec le retour en arrière en dessous. Chaque couche attrape certains problèmes et en manque d'autres. Peu passent à travers toutes, et le retour en arrière gère le reste. 1. Le travail est vérifié avant que quiconque ne le regarde. La majeure partie de la revue a désormais lieu avant même l'existence d'une PR. Nous donnons à Claude quelque chose qu'il peut exécuter, comme des tests, une compilation ou une capture d'écran à comparer avec la maquette, et nous lui demandons de montrer le résultat au lieu de dire qu'il a terminé. Un sous-agent examine ensuite le diff avec un contexte neuf. Ces deux habitudes viennent de notre guide des bonnes pratiques. Avant d'ouvrir une PR, beaucoup d'entre nous lancent aussi quelques compétences internes : l'une traque les bugs, une autre simplifie le diff, une dernière vérifie le comportement de bout en bout. Les modifications d'interface sont aussi contrôlées au regard de nos règles de design.
Source: Hacker News · Résumé par HeadlinesBriefing