Révision automatique du code de Claude – O’Reilly

Une invite système bien conçue augmentera la qualité du code produit par votre assistant de codage. Cela fait une différence. Si vous fournissez des directives dans l’invite de votre système pour l’écriture de code et de tests, les assistants de codage suivront les directives.

Bien que cela dépende de votre définition de « suivra ». Si votre définition est « suivra souvent », alors elle est exacte. Si votre définition est « suivra toujours » ou même « suivra la plupart du temps », alors elle est inexacte (à moins que vous n’ayez trouvé un moyen de les rendre fiables que je n’ai pas fait – faites-le-moi savoir).

Les agents de codage ignoreront régulièrement les instructions de l’invite du système. Alors que la fenêtre contextuelle se remplit et commence à les enivrer, tous les paris sont ouverts.

Même avec le dernier modèle Opus 4.5, je n’ai pas remarqué d’amélioration majeure. Donc, si nous ne pouvons pas compter sur des modèles pour suivre les invites du système, nous devons investir dans des cycles de rétroaction.

Je vais vous montrer comment j’utilise les hooks Claude Code pour implémenter la révision automatique du code sur tout le code généré par l’IA afin que la qualité du code soit meilleure avant qu’il n’atteigne l’humain dans la boucle.

Révision automatique du code pour un retour sémantique rapide

Lorsque je parle de révision automatique du code dans cet article, je décris un mécanisme de retour rapide destiné à examiner les problèmes courants de qualité du code. Cette opération sera exécutée chaque fois que Claude aura terminé ses modifications. Elle doit donc être rapide et efficace.

J’utilise également des assistants de codage pour des révisions détaillées du code lors de la révision d’un PR, par exemple. Cela fera tourner plusieurs sous-agents et prendra un peu plus de temps. Ce n’est pas de cela dont je parle ici.

Le but de la révision automatique du code est de renforcer le contenu de l’invite de votre système, la documentation du projet et les compétences à la demande. Des choses que Claude a peut-être ignorées. S’inscrit dans une approche à plusieurs volets.

Dans la mesure du possible, je vous recommande d’utiliser vos règles de charpie et de test pour améliorer la qualité, et de laisser la révision automatique du code pour les problèmes plus sémantiques que les outils ne peuvent pas vérifier.

Si vous souhaitez définir une longueur maximale pour vos fichiers ou un niveau d’indentation maximum, utilisez votre outil de charpie. Si vous souhaitez imposer une couverture de test minimale, utilisez votre framework de test.

Révision du code sémantique

Une révision sémantique du code examine dans quelle mesure le code est conçu. Par exemple, nommer : le code décrit-il avec précision les concepts commerciaux qu’il représente ?

L’IA utilise souvent par défaut des noms tels que « helper » et « utils ». Mais l’IA est également efficace pour comprendre les nuances et trouver de meilleurs noms si vous la contestez, et elle peut le faire rapidement. C’est donc un bon exemple de règle sémantique.

Vous pouvez interdire certains mots comme « helper » et « utils » avec des outils anti-peluches. (Je recommande de le faire.) Mais cela ne permettra pas de tout comprendre.

Un autre exemple est la fuite de logique hors du modèle de domaine. Lorsqu’un cas d’utilisation/un service d’application interroge une entité et prend ensuite une décision, il est fort probable que votre logique de domaine s’infiltre dans la couche application. Pas si facile à attraper avec des outils anti-peluches, mais cela vaut la peine d’y remédier.

Un autre exemple concerne les valeurs de secours par défaut. Lorsque Claude a une valeur non définie là où une valeur est attendue, il définira une valeur par défaut. Il semble détester lancer des exceptions ou contester la signature de type et demander : « Devrions-nous autoriser undéfini ici ? Il veut que le code s’exécute quoi qu’il arrive et peu importe combien l’invite système lui dit de ne pas le faire.

Vous pouvez en détecter une partie avec les règles de charpie, mais c’est très nuancé et dépend du contexte. Parfois, revenir à une valeur par défaut est correct.

Construire une révision de code automatique avec Claude Hooks

Si vous utilisez Claude Code et souhaitez créer une révision automatique du code pour les vérifications que vous ne pouvez pas facilement définir avec des outils de lint ou de test, une solution consiste à configurer un script qui s’exécute sur le Stop crochet.

Le Stop hook, c’est lorsque Claude a fini de travailler et redonne le contrôle à l’utilisateur pour qu’il prenne une décision. Ici, vous pouvez donc déclencher un sous-agent pour effectuer l’examen des fichiers modifiés.

Pour déclencher le sous-agent, vous devez renvoyer le code d’état d’erreur qui bloque l’agent principal et l’oblige à lire la sortie.

Je pense qu’il est généralement considéré comme une bonne pratique d’utiliser un sous-agent axé sur l’examen et doté d’un état d’esprit très critique. Demander à l’agent principal de noter ses propres devoirs n’est évidemment pas une bonne approche, et cela épuisera votre fenêtre contextuelle.

Dans l’exemple ci-dessus, vous pouvez voir que cela a pris 52 secondes. Probablement plus rapide que moi-même pour examiner et fournir mes commentaires. Mais ce n’est pas toujours le cas. Parfois, cela peut prendre quelques minutes.

Si vous restez bloqué en attendant un examen, cela peut être plus lent que de le faire vous-même. Mais si vous n’êtes pas bloqué et que vous travaillez sur autre chose (ou regardez la télévision), cela vous fait gagner du temps car le résultat final sera de meilleure qualité et nécessitera moins de temps pour l’examiner et le corriger.

Recherche de fichiers mis à jour

Je souhaite que ma révision automatique du code examine uniquement les fichiers qui ont été modifiés depuis la dernière pull request. Mais Claude ne fournit pas cette information dans le contexte du Stop crochet.

Je peux trouver tous les fichiers modifiés ou non mis en scène à l’aide de Git, mais ce n’est pas suffisant.

Ce que je fais à la place, c’est de m’accrocher PostToolUse en gardant un journal de chaque fichier modifié.

Quand le Stop hook est déclenché, la révision trouvera les fichiers modifiés depuis la dernière révision et demandera au sous-agent de réviser uniquement ceux-ci. S’il n’y a pas de fichiers modifiés, la revue de code n’est pas activée.

Les défis avec le Stop Crochet

Malheureusement le Stop hook n’est pas fiable à 100 % pour ce cas d’utilisation pour plusieurs raisons. Tout d’abord, Claude pourrait s’arrêter pour poser une question, par exemple pour que vous clarifiiez certaines exigences. Vous ne souhaiterez peut-être pas que la révision automatique se déclenche ici jusqu’à ce que vous ayez répondu à Claude et qu’elle soit terminée.

La deuxième raison est que Claude peut valider des changements avant le Stop crochet. Ainsi, au moment où le sous-agent effectue la révision, les modifications sont déjà validées dans Git.

Ce n’est peut-être pas un problème, et il existe des moyens simples de le résoudre si tel est le cas. Ce sont juste des choses supplémentaires à garder à l’esprit et à configurer.

La solution idéale serait qu’Anthropic (ou d’autres fournisseurs d’outils) nous fournisse des hooks d’un niveau d’abstraction plus élevé, plus alignés sur le flux de travail de développement logiciel et pas seulement sur les opérations de modification de fichiers de bas niveau.

Ce que j’aimerais vraiment, c’est un CodeReadyForReview hook qui fournit tous les fichiers que Claude a modifiés. Nous pouvons alors jeter nos solutions personnalisées.

Faites-moi savoir si vous avez une meilleure approche

Je ne sais pas si je ne cherche pas aux bons endroits ou si l’information n’est pas disponible, mais j’ai l’impression que cette solution résout un problème qui devrait déjà l’être.

Je serais vraiment reconnaissant si vous pouviez partager des conseils qui aident à améliorer la qualité du code avant que l’humain impliqué dans la boucle ne doive l’examiner.

D’ici là, je continuerai à utiliser cette solution de révision automatique du code. Lorsque vous donnez à l’IA une certaine autonomie pour mettre en œuvre des tâches et examiner ce qu’elle produit, il s’agit d’un modèle utile qui peut vous faire gagner du temps et réduire la frustration liée à la nécessité de répéter les mêmes commentaires à l’IA.