Anthropic affirme que Claude Code écrit désormais environ 90 % de son propre code et que l’équipe adapte la façon dont elle relit ce travail. Dans un billet, Addy Osmani, Morgan Westlee Lunt et Qing Wang décrivent leur objectif : fusionner la plupart des pull requests avec au plus une personne, qui peut être l’auteur du changement, sans augmenter le nombre de retours en arrière ni d’incidents.
L’équipe estime que les relecteurs n’ont pas besoin de maîtriser mentalement l’ensemble de Claude Code. Ils demandent plutôt à Claude de leur expliquer la partie de la base de code qu’ils doivent comprendre. Cette approche a suscité des critiques dans une discussion sur Hacker News : certains intervenants se sont demandé si s’appuyer sur les explications de l’IA permettrait encore à quelqu’un de déboguer une panne lorsque le modèle se trompe.
Fonctionnement des étapes de validation
Un classificateur attribue un niveau de risque à chaque changement en fonction de sa nature, et non de son auteur. Les changements à faible risque — documentation, textes et ajouts derrière un indicateur de fonctionnalité — peuvent être acceptés sans approbation humaine. Ceux à risque moyen, notamment les changements concernant la mise en cache, le programme de mise à jour automatique et les prompts système, nécessitent l’intervention d’une personne. L’approbation d’un agent ne compte pas comme une approbation humaine, mais la personne à l’origine d’une demande de changement peut tenir ce rôle.
Le processus de revue comporte son propre risque d’échec : les agents donnent suite à des commentaires qu’une personne pourrait ignorer. Anthropic décrit une pull request qui a fait l’objet de plus de 50 cycles de revue et de corrections au cours de la nuit, avant que son auteur ne mette fin au processus. L’équipe explique avoir plafonné le nombre de cycles après avoir constaté que multiplier les revues aggravait les choses. Elle a également observé qu’environ 59 % du code signalé lors des cycles ultérieurs était déjà présent au premier examen du relecteur.
Les incertitudes qui demeurent
Un autre exemple tiré du dépôt public de Claude Code illustre les limites des explications générées. En août, une réponse produite par Claude indiquait que des problèmes avaient été fermés faute d’activité, alors qu’il leur manquait des informations nécessaires pour reproduire le problème. Or, les règles du dépôt autorisent la fermeture des problèmes après 14 jours avec le statut « stale », puis 14 jours supplémentaires, sauf s’ils ont reçu au moins 10 votes positifs. Un développeur a dénombré plus de 6 000 problèmes étiquetés comme comportant des étapes de reproduction, mais toujours fermés pour inactivité. La réponse conseillait aussi de laisser un commentaire pour rouvrir un problème, alors que le processus verrouille les problèmes fermés au bout de sept jours.
Anthropic indique ne pas encore disposer de mécanismes de sécurité qui renforceraient les exigences d’approbation si ses indicateurs de revue se dégradaient. Son produit Code Review est généralement disponible avec les forfaits Team et Enterprise. L’action GitHub d’analyse de sécurité est open source, mais son fichier README avertit qu’elle n’est pas protégée contre les injections de prompt et qu’elle ne doit servir qu’à examiner des pull requests de confiance.
Pourquoi c'est important
Pour les équipes qui envisagent de confier la revue de code à l’IA, le processus d’Anthropic montre que les changements à faible risque peuvent être fusionnés sans approbation humaine, tandis que ceux à risque moyen nécessitent toujours l’intervention d’une personne. L’entreprise dit ne pas avoir mis en place de mécanismes qui renforceraient les approbations si les indicateurs de revue se dégradaient ; le billet ne précise donc pas comment le processus réagirait si ses protections commençaient à échouer.
