La revue de code Claude d’Anthropic remplace la lecture humaine routinière alors que l’IA écrit 90 % du code

La revue Claude Code d’Anthropic est entrée en territoire inconnu, car Claude écrit désormais environ 90 % du code du produit, selon l’entreprise. De juin à septembre 2026, les pull requests fusionnées ont plus que doublé. Pourtant, la part nécessitant une annulation aurait chuté de plus de 40 %.

Cette combinaison constitue le véritable sujet. Anthropic n’a pas répondu à l’explosion du code écrit par machine en demandant aux humains d’inspecter davantage de lignes. L’entreprise a confié l’essentiel de la lecture routinière à d’autres agents Claude, puis réservé l’approbation humaine aux changements présentant davantage de risques.

Il ne s’agit pas simplement d’une version plus rapide de la revue conventionnelle. Cette approche modifie la signification même de la revue, ceux qui l’effectuent et le point de départ de la responsabilité. Anthropic considère désormais l’attention humaine comme une ressource rare qui doit suivre le risque plutôt que chaque ligne individuelle.

Cette approche s’accompagne également d’une limite importante. Les résultats mis en avant reposent sur les propres mesures d’Anthropic, sans données brutes publiées ni audit indépendant. Son processus dépend d’une automatisation étendue, d’une infrastructure interne, de déploiements progressifs et d’un accès exceptionnellement important à ses propres modèles.

La confrontation qui en résulte n’oppose pas Claude aux programmeurs humains. Elle oppose une couverture automatisée à une inspection humaine universelle. Anthropic parie que des contrôles superposés, des approbations ciblées et une réversibilité peu coûteuse peuvent maîtriser davantage de risques qu’une lecture ligne par ligne à la vitesse des machines.

Ce qui a changé dans la revue Claude Code d’Anthropic

Anthropic a fait passer la revue de code d’un unique contrôle humain à un système continu de vérifications automatisées, d’agents réviseurs, d’approbations ciblées et de retours en arrière rapides.

L’entreprise a décrit ce système dans une publication d’ingénierie du 15 octobre consacrée à la revue Claude Code. Les auteurs Addy Osmani, Morgan Westlee Lunt et Qing Wang ont présenté le problème sous l’angle du volume de production. Lorsque les agents génèrent des changements plus vite que les personnes ne peuvent les lire, une file d’attente traditionnelle devient un goulot d’étranglement pour la livraison.

Anthropic affirme que chaque pull request reçoit une revue de Claude avant qu’une personne ne l’examine. Le réviseur lit le changement proposé à la lumière du dépôt plus large et de l’intention déclarée de la pull request. Pour les corrections de bugs, il tente d’identifier la cause première plutôt que de vérifier uniquement le correctif visible.

Plusieurs agents recherchent ensuite en parallèle des défauts potentiels. Un autre groupe vote sur chaque constat, et le système ne publie un problème que lorsqu’un nombre suffisant de réviseurs est d’accord. Anthropic indique avoir testé des filtres supprimant les commentaires limités au style, aux diagnostics ou à un nettoyage facultatif.

Les constats restants reçoivent des niveaux de gravité. Les développeurs ou les agents doivent soit corriger chaque constat, soit fermer son fil de discussion en justifiant leur décision. Une revue de sécurité automatisée distincte peut également empêcher une fusion tant qu’un problème demeure non résolu.

Ces revues s’ajoutent aux garde-fous conventionnels. Les pull requests restent soumises au linting, aux vérifications de types, aux builds et aux tests sur les plateformes prises en charge. Une file de fusion relance les vérifications par rapport à la branche principale actuelle, réduisant les échecs provoqués par des changements individuellement valides qui interagissent mal entre eux.

La revue commence avant même qu’une pull request existe. Claude exécute des tests, des builds ou des vérifications visuelles et affiche les preuves correspondantes. Un sous-agent disposant d’un contexte neuf inspecte ensuite le diff, ce qui réduit le risque que l’agent auteur répète simplement ses hypothèses initiales.

Les précédentes pratiques de codage d’Anthropic recommandaient de séparer les contextes de rédaction et de vérification. Le nouveau flux de travail transforme cette recommandation en système d’exploitation pour toute l’équipe.

L’approbation humaine dépend du risque classifié du changement. Les travaux à faible risque peuvent être fusionnés après validation des contrôles automatisés et de sécurité. Les exemples incluent la documentation, les modifications de texte, les fonctionnalités internes et les ajouts cachés derrière des feature flags.

Le travail produit ordinaire nécessite généralement une personne. Les domaines sensibles tels que la mise en cache, les prompts système et les mécanismes de mise à jour reçoivent également une attention humaine. Les changements les plus risqués nécessitent deux personnes, tandis que certains chemins protégés déclenchent toujours une revue manuelle.

Le classificateur évalue le changement, et non le fait qu’il ait été écrit par une personne ou un agent. Un second classificateur peut tout de même exiger une intervention humaine lorsque le niveau initial paraît trop permissif. L’approbation d’un agent ne remplace jamais une place réservée à une personne.

Cette distinction est importante. Anthropic n’a pas éliminé la responsabilité humaine ni affirmé que la revue par IA rend les logiciels exempts d’erreurs. L’entreprise a séparé la détection routinière des défauts des décisions liées à l’architecture, à l’orientation produit, aux systèmes sensibles et au risque acceptable.

La personne qui a donné ses instructions à Claude reste responsable du résultat. Chaque approbation s’applique à un commit spécifique, de sorte que des changements ultérieurs peuvent l’invalider. Dans le modèle d’Anthropic, la délégation modifie qui écrit et lit le code, mais pas qui assume le résultat.

Les chiffres rendent la revue exclusivement humaine insoutenable

Les métriques rapportées par Anthropic suggèrent que la production de code a déjà dépassé tout processus de revue fondé sur une lecture humaine universelle.

L’entreprise affirme que les pull requests fusionnées dans le dépôt Claude Code ont plus que doublé entre juin et septembre 2026. Durant la même période, la part nécessitant des annulations a reculé de plus de 40 %.

Ces chiffres décrivent une direction, et non une performance complète. Anthropic n’a pas communiqué le nombre absolu de pull requests, le taux d’annulation initial, le taux d’annulation final ni les variations statistiques. Une baisse relative de 40 % peut partir d’une référence élevée comme faible.

Le chiffre de 90 % doit également être formulé avec prudence. Anthropic affirme que Claude écrit environ 90 % du code de Claude Code. Cela ne signifie pas que le modèle choisit indépendamment les priorités produit, définit chaque exigence ou assume la responsabilité du déploiement.

Les ingénieurs dirigent toujours les tâches, évaluent les preuves, résolvent les arbitrages de conception et décident si le travail doit exister. La paternité du code par machine mesure la génération de code, tandis que l’ingénierie logicielle comprend bien davantage que la production de lignes.

Même avec ces réserves, Anthropic fait face à un véritable problème de mise à l’échelle. Son monorepo distinct serait passé d’environ 2 500 changements fusionnés par jour en mai à plus de 30 000 en septembre. L’entreprise a créé un système interne de contrôle de code source nommé Scion pour gérer cette charge de travail.

Claude Code utilise un dépôt distinct, de sorte que le chiffre de 30 000 changements ne mesure pas directement l’équipe produit. Néanmoins, le récit d’Anthropic sur sa refonte du contrôle de code source montre la pression plus large entourant son infrastructure de développement.

Les histoires de Scion et de Claude Code renvoient au même goulot d’étranglement. Une fois que les agents de codage peuvent créer, tester et réviser continuellement des changements, l’écriture du code cesse de contrôler le débit. Les files de revue, les builds, les autorisations, les systèmes d’intégration et les contrôles de publication deviennent les facteurs limitants.

La revue de code traditionnelle suppose qu’un nombre gérable de changements arrive de la part de personnes. Une autre personne lit chaque diff, demande des révisions et approuve la version finale. Ce modèle commence à se rompre lorsque la production augmente plus vite que la capacité des réviseurs.

Ajouter des réviseurs ne résout pas entièrement le décalage. Les ingénieurs expérimentés sont rares, et la revue constante interrompt le travail de conception, le débogage et les décisions produit. Une organisation peut accroître ses effectifs de revue tout en continuant de perdre de l’attention partagée face à un flux croissant de changements.

Anthropic mesure donc plus que le nombre de commentaires produits. L’entreprise suit les approbations humaines par pull request, les commentaires humains, le temps d’attente, les annulations et les incidents. L’objectif déclaré est de réduire le temps de revue humaine sans reporter ce temps sur la récupération en production.

L’entreprise rapporte également que son réviseur commercial par IA a fait passer la part des pull requests internes recevant des commentaires substantiels de 16 % à 54 %. La plupart des changements de plus de 1 000 lignes attireraient des constats, tandis que la plupart des changements plus petits ne soulèveraient aucun problème.

Ce résultat n’établit pas à lui seul l’exactitude. Davantage de commentaires peuvent représenter une meilleure détection, davantage de bruit, ou les deux. Anthropic affirme évaluer la qualité des commentaires en observant si les développeurs corrigent les constats, les rejettent ou identifient le comportement signalé comme intentionnel.

Le signal plus large est organisationnel. Anthropic ne considère plus la lecture humaine de chaque ligne modifiée comme la preuve déterminante de la revue. L’entreprise mesure si le système combiné détecte les problèmes, oriente bien l’attention et limite les dommages en production.

Ce changement exerce une pression sur toute organisation d’ingénierie qui déploie des agents de codage. Si la production des agents augmente alors que la politique de revue reste fixe, les files s’allongent et les gains de productivité attendus disparaissent. Les équipes doivent soit limiter la génération, soit repenser la façon dont elles la valident.

La couverture automatisée remet en question l’inspection humaine universelle

La confrontation centrale oppose la large couverture des machines à la conviction que chaque changement significatif mérite une lecture humaine directe.

L’inspection humaine universelle offre une promesse intuitive. Un ingénieur qualifié comprend le code, voit le changement et accepte sa responsabilité avant sa mise en production. Cette pratique peut diffuser les connaissances tout en détectant des hypothèses que les tests automatisés ne voient pas.

Cependant, cette promesse s’affaiblit lorsque la revue devient précipitée. Une personne confrontée à une longue file d’attente peut survoler au lieu de raisonner, approuver un code d’apparence familière ou se concentrer sur le style plutôt que sur le comportement. Une signature humaine ne garantit pas la compréhension.

L’alternative d’Anthropic utilise plusieurs couches spécialisées. Un agent rédige le changement, un autre le révise avec un contexte neuf, plusieurs agents recherchent des bugs et des agents distincts évaluent chaque constat. La revue de sécurité, l’intégration continue, les vérifications de fusion, le déploiement progressif et le retour en arrière couvrent différents modes de défaillance.

Cela ressemble à une défense en profondeur. Aucune couche individuelle n’a besoin d’un rappel parfait, car les couches suivantes peuvent détecter ce que les précédentes ont manqué. La classification du risque oriente alors le jugement humain rare vers les changements ayant un impact potentiel plus élevé.

Le mécanisme donne également à Anthropic une couverture de revue plus large. Les machines peuvent inspecter chaque pull request sans attendre l’emploi du temps d’un collègue. Elles peuvent examiner le contexte du dépôt, appliquer les conventions documentées et répéter les mêmes contrôles sur des milliers de changements.

Les instructions stockées dans CLAUDE.md décrivent le projet, ses conventions et ses limites. Un fichier REVIEW.md distinct indique au réviseur à quoi ressemble une défaillance dans un dépôt particulier. Les propriétaires du code peuvent identifier les chemins sensibles et exclure ceux qui ne sont pas pertinents.

Lorsque le réviseur signale à répétition une erreur, l’équipe peut déplacer la leçon en amont. Elle peut ajouter une règle de linting, améliorer un fichier d’instructions, modifier une compétence ou créer un nouveau contrôle automatisé. Les retours de revue deviennent alors une infrastructure réutilisable.

Les échecs passés deviennent des cas d’évaluation. Anthropic affirme avoir collecté des pull requests associées à des incidents, des annulations et des correctifs ultérieurs. Les ingénieurs ont vérifié les bugs sous-jacents, et le réviseur s’exécute désormais chaque jour sur cet ensemble.

Il s’agit d’un écart important par rapport à une revue conçue comme une rencontre entre deux personnes. Le système tente de préserver les leçons dans des contrôles exécutables plutôt que de dépendre de la mémoire individuelle. Chaque incident peut étendre la couverture future de détection de l’organisation.

Pourtant, la revue humaine traite toujours des questions qui ne peuvent être réduites à une correction locale. Les ingénieurs décident si une fonctionnalité doit exister, si une abstraction crée un précédent néfaste et si les preuves justifient le déploiement.

Ils inspectent également des domaines sensibles, notamment la facturation, les mécanismes de mise à jour, l’intégration continue et les workflows de publication. Ces changements peuvent avoir un large rayon d’impact même lorsque leur code semble correct à l’échelle locale.

Le processus ne prétend donc pas que les machines sont de meilleurs relecteurs à tous égards. Il confie aux machines le travail de lecture qu’elles peuvent effectuer de manière répétée, tout en attribuant aux personnes les décisions liées à l’objectif, à l’architecture, à l’incertitude et à la responsabilité.

Cette répartition transforme également les compétences d’ingénierie. Les ingénieurs doivent préciser l’intention, identifier les contraintes, concevoir la vérification, interpréter les éléments de preuve et reconnaître lorsqu’un agent a optimisé le mauvais objectif. Lire le code reste utile, mais ce n’est plus le seul chemin vers la compréhension.

L’équipe Scion d’Anthropic a proposé un exemple similaire. Des ingénieurs ont signalé que Claude poursuivait parfois des conceptions inefficaces ou excessivement défensives, conformes aux schémas locaux. Des humains devaient écarter ces orientations parce qu’ils comprenaient les arbitrages à l’échelle du système.

L’expression « human in the loop » peut masquer ce rôle. Une personne qui se contente d’approuver la sortie d’une machine constitue une faible protection. Une personne qui définit les limites, choisit les éléments de preuve et sait quand arrêter l’automatisation exerce un contrôle significatif.

Pour les autres organisations, la leçon n’est pas de supprimer les relecteurs. Elle consiste à distinguer l’inspection mécanique du jugement. La couverture automatisée devient précieuse lorsque les personnes conservent l’autorité sur les décisions aux conséquences importantes et les preuves ambiguës.

Comment les revues Claude Code évitent les boucles d’agents interminables

Anthropic a découvert que les auteurs IA et les relecteurs IA peuvent générer un travail illimité, à moins que le processus de revue ne soit explicitement conçu pour converger.

Davantage de revue n’est pas automatiquement préférable. Anthropic décrit une pull request Claude Code ayant traversé plus de 50 cycles de revue et de correction pendant la nuit. L’auteur a fini par arrêter la boucle.

Le relecteur ne découvrait pas un nouveau défaut critique à chaque passage. Anthropic a utilisé l’historique des versions pour examiner les constats répétés et a constaté qu’environ 59 % concernaient du code déjà présent lors de la première revue.

L’agent continuait de repérer d’autres anciens problèmes au lieu d’évaluer uniquement la nouvelle correction. Chaque commentaire déclenchait une nouvelle correction, un commit et une revue. Le système restait actif sans progresser efficacement vers un état final acceptable.

Cet échec illustre un risque spécifique aux revues de code par IA. Une personne peut écarter une suggestion de faible valeur en quelques secondes. Un agent auteur a tendance à l’appliquer, produisant un nouveau diff qui donne au relecteur IA davantage de matière à examiner.

Anthropic a réagi avec des contrôles de convergence. Après trois cycles, le relecteur demande à l’auteur de reconsidérer l’approche. Les passages ultérieurs se concentrent sur le nouveau diff plutôt que de rechercher à répétition dans l’ensemble du changement.

Le relecteur signale également toute une catégorie de défauts connexes en une seule fois. Cela permet à l’auteur de corriger chaque occurrence au lieu de recevoir des commentaires similaires au fil de cycles successifs. Les constats déjà publiés ne devraient pas réapparaître.

Anthropic affirme que ces changements ont amélioré son cycle de revue interne. La part des pull requests validées après un cycle de revue et de correction serait passée de 65 % à 78 %.

Les pull requests nécessitant cinq cycles ou davantage seraient passées de 8,9 % à 1,5 %. Le nombre moyen de revues avant validation a baissé de 2,08 à 1,32. Ces indicateurs restent déclarés par l’entreprise, mais ils traitent un problème opérationnel que de nombreux workflows d’agents négligent.

La convergence est importante, car le travail automatisé n’est pas gratuit simplement parce qu’il ne reçoit pas de salaire. Chaque cycle supplémentaire consomme de la capacité de modèle, retarde le changement, crée davantage de code et augmente la matière que les contrôles ultérieurs doivent inspecter.

Le même problème apparaît lorsque les relecteurs réagissent de manière excessive à des menaces hypothétiques. Anthropic indique qu’une revue adversariale peut devenir myope et encourager une validation ou une complexité excessive. Un système optimisé pour découvrir des défaillances possibles peut engendrer de nouveaux coûts de maintenance.

Une profondeur fondée sur le risque offre un moyen de contrôle. Le service Code Review d’Anthropic, généralement disponible, prend en charge différents niveaux de revue pour les dépôts courants et critiques. L’entreprise indique que la plupart des revues s’achèvent désormais en six à dix minutes.

Cependant, un relecteur plus rapide ne résout pas la question de gouvernance sous-jacente. Les équipes doivent toujours décider quels constats comptent, quels chemins méritent une inspection plus approfondie et combien de cycles sont acceptables.

Les instructions de revue peuvent également devenir une couche de politique cachée. Si CLAUDE.md, REVIEW.md ou les prompts de classification contiennent des hypothèses fragiles, les agents peuvent appliquer ces hypothèses de façon cohérente dans tout le dépôt.

La cohérence n’aide que lorsque la règle est correcte. Les équipes ont besoin de responsabilité, de contrôle de version, de cas d’évaluation et de revue pour les instructions qui guident leurs relecteurs. Sinon, l’automatisation peut déployer une politique erronée plus vite que les humains ne s’en aperçoivent.

C’est là que le contexte d’ingénierie partagé devient important. Les organisations qui adoptent des agents ont besoin de traces durables des décisions d’architecture, des enseignements tirés des incidents et des approches rejetées. Une base de connaissances d’ingénierie consultable peut aider à préserver ce contexte au-delà d’un seul fil de revue.

Le processus d’Anthropic fonctionne parce qu’il traite le relecteur comme un système qui doit être mesuré. Il suit l’exactitude, le bruit, les cycles, les incidents et les réponses des développeurs. Installer un relecteur IA sans ces boucles de rétroaction reviendrait à copier l’outil visible tout en passant à côté du modèle opérationnel.

Ce que les résultats d’Anthropic ne démontrent pas encore

Les affirmations les plus fortes restent auto-déclarées, et Anthropic n’a pas démontré que ses résultats se transfèrent à des équipes dotées d’infrastructures, de budgets ou de tolérances aux défaillances différents.

La première incertitude concerne la mesure. Anthropic a indiqué que les pull requests fusionnées avaient plus que doublé et que la part des reverts avait diminué de plus de 40 %. L’entreprise n’a pas publié le jeu de données sous-jacent, les taux absolus ni la répartition de la gravité des incidents.

Une baisse de la part des reverts peut être encourageante tout en masquant des résultats importants. Les équipes peuvent corriger en avançant plutôt que revenir en arrière, désactiver un feature flag ou tolérer une régression qui ne reçoit jamais cette étiquette. Les reverts sont utiles, mais incomplets.

Les taux d’incidents fournissent une autre protection, mais le billet public ne présente pas de série détaillée d’incidents. Sans données sur la gravité et l’exposition, les observateurs externes ne peuvent pas déterminer si le processus a réduit le risque ou modifié la manière dont les défaillances étaient traitées.

Le chiffre de 90 % d’auteur comporte une ambiguïté similaire. Il ne précise pas si la mesure compte les lignes générées, les lignes acceptées, les commits ou une autre unité. Il ne révèle pas non plus l’ampleur du prompting, de l’édition et des itérations humaines ayant précédé le code final.

L’environnement d’Anthropic est exceptionnellement favorable à cette méthode. L’entreprise contrôle les modèles, peut consacrer une puissance de calcul substantielle à des relecteurs parallèles et développe une infrastructure interne autour de charges de travail générées par des agents.

Ses employés utilisent également Claude Code avant les lancements publics. Les nouvelles fonctionnalités peuvent passer par un déploiement interne, un canal latest, puis un canal stable. Les feature flags permettent à l’équipe de désactiver un comportement sans procéder à un déploiement complet.

Les équipes qui exploitent des systèmes médicaux, financiers, industriels ou critiques pour la sécurité peuvent faire face à des exigences différentes. Un retour en arrière rapide ne peut pas annuler toutes les conséquences. Une migration de données défectueuse, un changement d’autorisation ou une action externe peut causer un préjudice irréversible.

Anthropic reconnaît que les mauvaises fusions dépendent encore des auteurs, des ingénieurs d’astreinte, de la télémétrie et des tableaux de bord pour être détectées. L’entreprise ne dispose pas encore de disjoncteurs automatiques qui renforcent les exigences d’approbation lorsque les reverts ou les incidents augmentent.

Cette lacune est importante, car la classification des risques peut devenir obsolète. Un changement considéré comme peu risqué peut interagir avec des dépendances cachées. Une série de changements individuellement sûrs peut également produire un état combiné dangereux.

La sécurité soulève une autre préoccupation. Anthropic utilise une revue de sécurité automatisée, mais ses propres documents sur les risques montrent pourquoi la supervision humaine demeure nécessaire. Son évaluation du sabotage décrit la surveillance des modèles comme un contrôle en évolution plutôt que comme une garantie complète.

Les réactions de la communauté ont soulevé des questions plus larges sur le coût et la compréhension. Certains développeurs soutiennent qu’Anthropic peut maintenir des schémas de revue qui seraient peu rentables ailleurs. D’autres craignent que moins de personnes lisant les diffs affaiblisse la connaissance collective de la base de code.

Anthropic déclare ouvertement que personne dans l’équipe Claude Code ne maintient un modèle mental complet du produit. Les ingénieurs demandent plutôt à Claude d’expliquer le sous-système concerné lorsqu’ils en ont besoin.

Cette approche peut maintenir les explications à jour, mais elle crée une dépendance. Si l’explication générée omet une interaction, l’ingénieur peut prendre une décision à partir d’une carte incomplète. La même famille de modèles peut également répéter les hypothèses intégrées au code qu’elle examine.

La revue inter-modèles pourrait apporter une diversité supplémentaire, mais elle n’améliore pas automatiquement l’exactitude. Des systèmes différents peuvent partager des schémas d’entraînement ou échouer pour des raisons distinctes. La propriété importante est l’indépendance des preuves, et pas simplement un nom de modèle différent.

Aucune de ces questions n’invalide les résultats rapportés par Anthropic. Elles limitent ce que ces résultats établissent. L’entreprise a montré un processus interne détaillé avec des indicateurs directionnels encourageants, et non un remplacement universel de la revue humaine du code.

Trois signaux permettront de vérifier si le modèle tient

Le prochain test consistera à voir si Anthropic peut préserver la qualité à mesure que les fusions sans intervention humaine s’étendent, que les produits de revue atteignent d’autres entreprises et que les concurrents adoptent des contrôles différents.

Le premier signal est la politique d’approbation d’Anthropic elle-même. Son processus actuel permet à certains changements sélectionnés à faible risque d’être fusionnés sans relecteur humain distinct une fois les contrôles automatisés réussis.

Il faudra observer si cette limite s’étend à davantage de code produit. Si Anthropic ajoute les disjoncteurs que ses ingénieurs souhaitent, une escalade automatique pourrait rendre un déploiement plus large plus crédible. Une hausse des incidents ou un retour à des approbations plus strictes affaiblirait l’argument.

Le deuxième signal sera constitué par les preuves provenant d’organisations externes qui utilisent la revue automatisée. Anthropic a lancé Code Review pour les clients Team et Enterprise, créant un test plus large sur des dépôts et des cultures d’ingénierie inconnus.

Les indicateurs utiles ne seront pas le nombre de commentaires ou de pull requests examinées. Les équipes devraient publier les constats acceptés, les défauts passés au travers, les faux positifs, la latence de revue, l’effort humain et les incidents en production.

Des résultats comparables en dehors d’Anthropic renforceraient l’affirmation selon laquelle une revue IA en couches peut passer à l’échelle. Un bruit élevé, une utilisation croissante des modèles ou des taux d’incidents inchangés suggéreraient que le succès d’Anthropic dépend de son environnement interne.

Le troisième signal est la réponse concurrentielle. OpenAI, GitHub, Google, Cursor et les autres fournisseurs d’agents de codage font face au même déséquilibre entre le code généré et la capacité des relecteurs.

Leurs choix révéleront si la revue fondée sur les risques devient un modèle partagé. Les systèmes concurrents pourraient privilégier la revue inter-modèles, un sandboxing plus rigoureux, la vérification formelle, une évaluation propre au dépôt ou une approbation humaine plus persistante.

Les développeurs devraient résister à la tentation de réduire ce débat à la capacité de l’IA à trouver des bugs. La question pratique est de savoir si un système de revue complet peut répartir l’attention, préserver la responsabilité et se rétablir en toute sécurité lorsque chaque couche rate quelque chose.

Pour les responsables de l’ingénierie, l’action immédiate est la mesure. Établissez une référence du temps de revue, des défauts échappés, des faux positifs, des taux de revert et de la gravité des incidents avant de modifier la politique d’approbation. Sans cette référence, des fusions plus rapides peuvent sembler être une amélioration tout en déplaçant les coûts ailleurs.

Les équipes doivent également distinguer les changements réversibles des changements irréversibles. La documentation, les ajustements d’interface signalés et les outils internes ne méritent pas le même processus que l’authentification, la facturation, les migrations ou l’infrastructure de mise en production.

L’examen d’Anthropic Claude Code apporte une réponse concrète à un problème auquel de nombreuses équipes seront bientôt confrontées. Il considère la revue comme un système de contrôle à plusieurs niveaux, plutôt que comme la preuve qu’une personne a lu chaque ligne.

Les chiffres communiqués par l’entreprise font de cette réponse une piste à tester, pas à reproduire aveuglément. Si vos agents doublent demain la production de code, quelles preuves permettraient à vos réviseurs de cesser, en toute sécurité, de tout lire dès aujourd’hui ?