L'écriture de code, l'IA s'en charge déjà. Mais la validation, elle, repose encore sur vous.
Pour savoir si un code est correct, l'IA n'est pas responsable, c'est à vous de le relire ligne par ligne : cette étape bloque beaucoup de monde.
Récemment, Anthropic a intégré la validation par l'IA dans la boucle.
Ils demandent à Claude, après avoir écrit du code, de ne pas le rendre directement, mais d'effectuer lui-même quatre vérifications :
/code-review pour débusquer les bugs, /simplify pour nettoyer les implémentations redondantes, /verify pour une validation de bout en bout, et si l'interface a été modifiée, /design pour vérifier la conformité visuelle avec DESIGN.md.
Ce n'est qu'après ces quatre étapes que le travail est considéré comme rendu.
Le 22 juillet, l'équipe Claude Code a rendu publique cette « boucle de vérification » interne.
En d'autres termes, après avoir écrit du code, Claude recherche d'abord lui-même les erreurs, les corrige, et ne revient vers vous que lorsque tout est en ordre.
Cela signifie que l'IA évolue de « savoir écrire du code » à « savoir vérifier le code qu'elle a écrit ».
La boucle de travail de l'agent intelligent s'enrichit d'une étape de vérification
Anthropic a donné un nom à ce système : la boucle de vérification (verification loop).
La définition officielle est simple : c'est un processus itératif où Claude vérifie et tente de corriger son propre travail.
Elle modifie la boucle de travail d'un agent intelligent.
Auparavant, c'était « collecter le contexte → exécuter l'action → vérification manuelle », cette dernière étape reposant sur l'humain : l'IA rendait le travail, et vous deviez le relire ligne par ligne.
Désormais, cette ligne s'est allongée en « collecter le contexte → exécuter l'action → vérification automatique → correction → revérification ». La vérification et la correction sont réintégrées dans la boucle.
Schéma officiel de la boucle de l'agent intelligent par Anthropic : après réception de l'invite, Claude collecte le contexte, exécute l'action, vérifie le résultat. Si la vérification échoue, il recommence ; s'il réussit, il rend le travail.
Claude sait déjà effectuer certaines vérifications. Il comprend les signaux déterministes du dépôt de code, comme le vérificateur de types, le linter, l'exécution des tests, les erreurs d'exécution, et les corrige au passage.
Ce qui pose vraiment problème, ce sont les autres : l'interface est-elle modifiée correctement ? Le flux utilisateur est-il fluide ? Cette modification a-t-elle introduit des bugs invisibles ?...
Auparavant, seule une surveillance humaine pouvait détecter ces problèmes, répétant les mêmes vérifications des dizaines, voire des centaines de fois.
La solution d'Anthropic consiste à noter une par une ces vérifications que vous effectuez manuellement à chaque fois, à les encapsuler en « Skills » (Compétences), et à les confier à Claude pour qu'il les exécute automatiquement à chaque tâche.
Au cours des dernières décennies, tous les processus du génie logiciel : rédaction des besoins, planification, revues en cascade, réunions interminables, existaient essentiellement parce que : écrire du code est trop lent, et le temps des ingénieurs est trop précieux.
Mais lorsque l'IA rend l'écriture de code plus rapide et moins coûteuse, cette prémisse disparaît.
Le jugement de l'équipe Claude Code elle-même est le suivant : le goulot d'étranglement n'a pas disparu, il s'est simplement déplacé : de « l'écriture de code » vers la vérification, la revue de code, la sécurité, etc.
La génération de code est devenue trop rapide, et le nouveau problème est de savoir si ce code est correct, qui le maintiendra, et si les humains peuvent suivre le rythme des revues.
Face à ce nouveau goulot d'étranglement, l'équipe Claude Code a d'abord expérimenté sur elle-même.
Les 4 Skills d'autocritique que l'équipe Claude Code utilise quotidiennement
En interne, l'équipe Claude Code utilise quotidiennement ces quatre Skills d'autocritique.
/code-review, spécialisé dans l'examen des modifications de code, débusque les bugs potentiels et fournit des commentaires de revue.
C'est comme se doter d'un relecteur infatigable.
/simplify, nettoie le diff des modifications, supprime les implémentations complexes et tortueuses, et simplifie la structure.
Il n'ajoute pas de fonctionnalités, mais élimine les redondances, simplifie l'implémentation, réduisant ainsi les coûts de maintenance futurs.
Ce point est crucial et révélateur d'une grande maîtrise. La plupart des gens ajoutent du code ; un outil capable de faire des soustractions est particulièrement précieux.
/verify, effectue une validation de bout en bout, exécute réellement le code pour confirmer que la fonctionnalité est réellement achevée, et non « semble être achevée ».
/design, n'intervient que si l'interface utilisateur a été modifiée. Il vérifie point par point, par rapport au DESIGN.md du dépôt, si votre implémentation visuelle est conforme.
Ces 4 Skills ne sont pas sortis de nulle part.
En amont, Claude Code a déjà mis en place une couche de support de vérification prête à l'emploi :
Le /verify intégré peut lancer l'application pour observer les changements ; si vous décrivez clairement les commandes de construction et de test dans CLAUDE.md, il les exécute ; il y a aussi Code Review pour des revues multi-agents sur les PR, et des GitHub Actions qui peuvent se déclencher automatiquement à chaque commit.
Les 4 Skills de l'équipe ajoutent une étape de traitement supplémentaire sur ces fondations génériques.
Comment écrire son propre Skill de vérification ?
La méthode donnée par Anthropic est également simple :
Notez dans un langage clair l'étape que vous effectuez manuellement à chaque fois, comme si vous expliquiez les points d'attention à un nouveau collègue le premier jour.
Si vous bloquez même sur la description de cette vérification, vous pouvez d'abord demander à Claude de fournir une version des meilleures pratiques générales, puis la modifier.
Votre version différera probablement sur quelques points spécifiques de la pratique générale, et ces différences sont précisément ce qui doit être noté.
La vérification ne doit pas nécessairement être un jugement vague du type « est-ce que ça semble bon ? ».
Par exemple : tout changement qui supprime un champ de la base de données sans étapes de migration de données correspondantes doit être rejeté. C'est une « règle maison » propre à votre projet qu'un linter générique ne capturera jamais.
Toute règle rouge que vous maintenez uniquement par une surveillance manuelle constante mérite d'être transformée en une boucle.
Que faire une fois écrit ?
Donnez-le à skill-creator pour qu'il vous interroge en retour, ou déposez simplement un fichier Markdown dans .claude/skills/.
Le Skill de vérification le plus simple est constitué de quelques lignes d'explication et d'un paragraphe de texte. Puis testez-le sur une nouvelle tâche pour confirmer que cette vérification s'exécute bien, et modifiez-le si ce n'est pas le cas.
Pour les Skills que vous ne pouvez pas modifier, comme ceux intégrés ou gérés par des extensions, il existe aussi une solution : écrivez un Skill wrapper qui appelle d'abord l'original, puis votre vérification. En contournant ainsi, l'inclusion de la vérification reste possible.
La vérification n'est pas uniforme, elle a 4 niveaux
Une fois les contrôles encapsulés en Skills, la question suivante est : quand ce système se déclenche-t-il ?
Anthropic propose 4 niveaux d'automatisation, du plus souple au plus strict.
Standalone : Vous y pensez vous-même et l'appelez manuellement.
Embedded : Intégré dans un flux de tâches spécifique, il s'exécute automatiquement avec lui.
Chained : Plusieurs Skills de vérification sont enchaînés en une chaîne, s'exécutant automatiquement les uns après les autres.
On every PR : Le niveau le plus strict, chaque commit de code déclenche automatiquement la vérification.
Officiellement, cette transition intermédiaire est appelée « de l'habitude au contrat ».
Ce qui était auparavant une habitude personnelle : « Je me souviens toujours de lancer /verify après /simplify », devient, une fois enchaîné, un contrat fixe : « Après l'exécution de /simplify, /verify est automatiquement appelé. »
La chaîne complète parcourt elle-même le cycle de développement et ne revient vous voir que lorsque votre approbation est nécessaire.
Plus la chaîne est longue, plus la fiabilité est élevée, mais l'équipe officielle précise : la vérification en chaîne consomme réellement des tokens.
Ne commencez donc pas par définir tous les contrôles comme des « gates » de PR, bloquant chaque commit. La bonne approche est d'abord d'évaluer sa stabilité, puis d'ajouter progressivement des niveaux.
Derrière les 4 Skills, la programmation IA change de voie
Derrière ces 4 Skills, la concurrence dans la programmation IA évolue de la génération vers la vérification.
Le « père » de Claude Code a émis le même jugement.
Le 9 juin dernier, il a tweeté : À l'ère où les modèles puissants peuvent fonctionner de manière autonome pendant de longues périodes, l'autovérification est la clé pour que les modèles fonctionnent plus longtemps et que leurs résultats se rapprochent de vos attentes : vous n'avez pas besoin de surveiller fréquemment Claude pour lui confier plus de travail.
En clair, plus la vérification est solide, plus l'agent intelligent peut fonctionner librement ; plus il fonctionne longtemps, plus l'humain est libéré.
Auparavant, nous comptions sur les invites, mais elles ont aussi un plafond : elles ne résolvent que la tâche en cours, la prochaine fois il faut recommencer.
Corrigeons d'abord un malentendu courant : un Skill n'est pas une simple invite Markdown.
C'est un module de capacité, contenant des instructions, une structure de fichiers, des scripts, des appels d'outils, des configurations et un ensemble complet de flux de travail. Il s'agit de précipiter les étapes de vérification de l'équipe, les normes de conception, les pièges rencontrés, en un package accessible à tout moment, que Claude peut consulter lorsque nécessaire.
Plus crucial encore, les Skills sont en train de passer d'une fonctionnalité de Claude Code à une norme ouverte interopérable.
Selon des analyses du secteur, GitHub Copilot, Cursor, OpenAI Codex, Gemini CLI ont déjà adopté le même format.
Cela signifie que les Skills que vous précipitez pour votre équipe ne seront pas verrouillés sur un outil spécifique. Ils précipitent l'expérience, les normes et les processus de vérification de l'équipe, devenant une capacité réutilisable.
Cela soulève également une réalité difficile : le même Claude peut être utilisé avec des efficacités très différentes selon les équipes. Cet écart ne provient pas du modèle, mais du flux de travail :
Avez-vous écrit les vérifications sous forme de Skills ? Avez-vous mis en place des boucles de vérification ? Avez-vous permis à l'agent intelligent de boucler lui-même le cycle de rétroaction ?
En fin de compte, la capacité d'un agent intelligent est une addition : le modèle, plus les outils, plus le mécanisme de vérification, plus le flux de travail.
Le premier terme, le modèle, devient de plus en plus similaire entre les fournisseurs. Ce qui crée vraiment l'écart, ce sont les trois derniers termes, qui sont entièrement entre les mains de l'utilisateur.
Bien sûr, ce que montre cet article est l'optimisation des processus de développement assisté par IA, et non « l'IA peut déjà écrire des logiciels de manière indépendante ». Elle reste dépendante des ingénieurs et ne peut pas réaliser des livraisons de niveau production sans intervention humaine.
Il ne s'agit donc pas d'agents intelligents venant voler le travail des ingénieurs humains, mais la direction est claire.
Par le passé, nous apprenions à l'IA à écrire du code. Désormais, il faut commencer à lui apprendre à vérifier si ce qu'elle écrit est correct.
Pour quelqu'un qui utilise quotidiennement l'IA pour écrire du code, le jour où « devoir encore vérifier manuellement son travail avant de quitter le bureau » pourra enfin être confié à l'IA en toute confiance, c'est à ce moment-là qu'elle commencera véritablement à vous soulager.
Références :
https://claude.com/blog/building-verification-loops-in-claude-code-with-skills
https://claude.com/blog/getting-started-with-loops?utm_source=chatgpt.com
Cet article provient du compte public WeChat « Xin Zhi Yuan », auteur : ASI Révélation
