Comment écrire du code robuste avec Claude Code

les agents de codage peuvent être utilisés pour créer rapidement de nouvelles applications. Cependant, le problème lorsque vous créez rapidement une nouvelle application est que vous ne pouvez pas consulter le code.

À mon avis, c’est vraiment bien. Vous n’avez généralement pas besoin d’analyser le code, sauf si vous créez des applications critiques pour la sécurité ou similaires, étant donné que les agents de codage sont devenus si performants que cela n’est généralement pas nécessaire.

Cependant, si vous ne prenez pas certaines précautions, vous rencontrerez des problèmes de robustesse et votre application sera moins fiable que si vous la programmiez vous-même, en réfléchissant soigneusement à chaque morceau de code. Dans cet article, je couvrirai les tactiques et techniques spécifiques que j’utilise pour rendre mon code aussi robuste que possible lorsque je programme à l’aide de Claude Code sans regarder le code moi-même.

Pourquoi avez-vous besoin d’un code robuste ?

Il s’agit principalement d’une question rhétorique, car vous souhaitez bien sûr un code robuste capable de gérer de nombreuses situations différentes, car il permet aux utilisateurs de moins d’erreurs et, dans l’ensemble, d’avoir une meilleure expérience avec votre produit. Une autre question à vous poser ici est bien sûr la suivante : ne devriez-vous pas examiner le code vous-même pour le rendre plus robuste ?

J’ai deux réponses principales à ce dernier point :

1. Vous n’avez pas vraiment le temps de regarder tout le code vous-même si vous souhaitez garder un tempo élevé et développer un produit rapidement.
2. Les agents de codage sont devenus si efficaces pour détecter les problèmes et créer un code fiable, si vous y êtes invité correctement, que l’augmentation de la robustesse du code peut être effectuée automatiquement via des agents de codage et ne doit pas nécessairement être un travail manuel.

Nous arrivons ainsi au point principal de cet article, à savoir comment garantir automatiquement la robustesse du code grâce à des agents de codage afin de ne pas avoir à passer du temps à le faire vous-même. Je couvrirai cela dans les sections suivantes.

Comment construire un code initialement robuste

La première section que je vais aborder est de savoir comment créer initialement un code robuste. Et la section suivante expliquera comment vérifier la robustesse du code et le corriger une fois qu’il a été construit. Je considère cela comme deux problèmes distincts et j’utilise des techniques distinctes pour les résoudre, c’est pourquoi je l’ai divisé en deux sections.

Utilisation active du mode forfait

Le mode Plan est la première technique que je vais aborder et je pense qu’elle est très importante si vous souhaitez tirer le meilleur parti des agents de codage. L’utilisation du mode plan permet aux agents de codage de consacrer plus de temps à planifier la mise en œuvre au lieu de simplement la commencer immédiatement. Cela améliore généralement la capacité du modèle à avoir une vue d’ensemble et évite ainsi les bogues causés par exemple par les mises à jour d’un composant modifiant des éléments dans d’autres composants.

Le mode Plan pose également des questions de clarification afin que toute ambiguïté soit claire. Demander aux agents de codage de poser de nouvelles questions au lieu de poser des questions aux agents de codage est une fonctionnalité incroyablement puissante que je vous invite à utiliser activement davantage. Vous souhaitez laisser le modèle réfléchir autant que possible et ne revenir vers vous que lorsqu’il a besoin de clarifier quelque chose ou de mieux comprendre ce que vous souhaitez mettre en œuvre.

Il est bien plus puissant que les LLM vous posent des questions plutôt que de poser des questions aux LLM.

Dans la plupart des cas, cela conduit à moins de bogues et à un modèle plus efficace dans la mise en œuvre d’une solution. Bien que le mode Planification prenne au départ plus de temps puisque vous devez planifier avec l’agent et ne pas démarrer l’implémentation tout de suite, cela en vaut généralement la peine à long terme en raison du moins de bogues que vous rencontrez et du fait de devoir passer moins de temps à itérer avec l’agent après une implémentation pour vous assurer d’obtenir l’implémentation exacte que vous désirez.

Conservation des fichiers de compétences

La deuxième partie concerne les fichiers MD que vous avez dans votre référentiel. Au fil du temps, lorsque vous passez du temps à coder dans le référentiel, le nombre de fichiers de démarque devrait augmenter régulièrement, mettant en évidence la manière dont les agents doivent se comporter dans le référentiel, les bogues précédents qui ont été signalés et comment ils ont été corrigés, ainsi que d’autres problèmes survenus précédemment dans le référentiel.

Ceci est extrêmement important et utile pour les agents de codage, car ils disposent souvent de suffisamment de contexte pour pouvoir utiliser activement ces connaissances. Et cela les rend moins enclins à prendre les mauvaises décisions qu’ils ont prises dans le passé. Ces fichiers Markdown sont généralement créés à partir d’erreurs commises par les agents lors de sessions précédentes. En avoir un grand nombre les aide donc tous à prendre de meilleures décisions.

Pour créer ces fichiers Markdown, je vous invite à demander à un agent de généraliser les connaissances d’un fil après chaque fil de discussion que vous avez eu avec votre agent de codage. C’est probablement l’astuce numéro un qui rend le codage avec des agents plus efficace. Deuxièmement, chaque fois que vous découvrez et corrigez un bug, vous stockez une description du problème et comment il a été résolu dans un fichier markdown.

Si vous appliquez ces concepts à chaque fois que vous codez, vous développerez une base de connaissances incroyablement puissante au sein de votre référentiel, et vos agents s’amélioreront certainement au fil du temps et deviendront de plus en plus efficaces et moins sujets aux erreurs, et construiront ainsi un code plus robuste.

Évitez d’exécuter votre agent avec une fenêtre contextuelle trop grande

Une autre raison très courante pour laquelle je reçois du code non robuste, du code vulnérable ou du code contenant des bogues est que j’ai exécuté mon agent avec un contexte trop long. Claude Code, par exemple, a publié il n’y a pas si longtemps son modèle de contexte à 1 million. La fenêtre contextuelle d’un million de jetons est extrêmement longue et peut contenir beaucoup d’informations. Cependant, d’après mon expérience, les performances du modèle se dégradent fortement une fois que vous dépassez 3 à 400 000 jetons, ce qui ne représente que 30 à 40 % de la fenêtre contextuelle maximale du modèle.

Ainsi, à moins que vous ne soyez vraiment obligé de le faire, en raison de nombreux contextes spécifiques, je vous conseille vivement de travailler avec des agents dont le contexte est moins rempli afin qu’ils puissent devenir plus efficaces.

La raison pour laquelle les performances des agents de codage se dégradent avec un contexte plus long est que les agents doivent prendre davantage en compte le contexte, où une grande partie du contexte sera généralement du bruit, pas vraiment pertinent pour le problème sur lequel ils travaillent. Cependant, il est difficile pour les modèles de séparer le bruit des informations vraiment importantes, ce qui rend leurs performances moins bonnes.

Comment vérifier la robustesse du code via des agents de codage

Bien entendu, il est très important de construire initialement un code robuste. Cependant, il est inévitable que les agents de codage commettent des erreurs parce qu’ils ne sont pas capables de voir le contexte complet de ce qu’ils font ou, pour une autre raison, ils implémentent un code sujet aux erreurs et donc peu robuste. Dans ces situations, il est extrêmement important de disposer d’un filet de sécurité dans lequel vous trouvez le code sujet aux erreurs et le corrigez avant qu’un utilisateur n’en fasse l’expérience.

Révision du code de l’agent de codage

La première chose, et probablement la plus simple, que vous puissiez faire pour créer un code plus robuste est de demander aux agents de codage d’examiner le code produit par d’autres agents de codage. Pour ce faire, vous disposez d’un nouvel agent de codage avec une fenêtre contextuelle claire, à l’exception de son invite, bien sûr : analyser le code dans la demande d’extraction et rechercher d’éventuelles erreurs.

Cette invite que vous fournissez à l’agent de codage chargé de la révision des demandes d’extraction peut également être répétée au fil du temps. Par exemple, l’informer des bugs passés qui ont été rencontrés et de la manière dont ces bugs ont été détectés et comment ils ont été corrigés. Cela rendra probablement les agents de révision plus capables de découvrir les bogues.

Un conseil de pro ici pourrait être d’avoir un modèle distinct ou un modèle différent effectuant la révision du code. Par exemple, si vous avez du code Claude, écrivez votre code. Généralement, dans certains scénarios, il pourrait au moins être utile de demander à un autre agent de codage de réviser le code, par exemple GPT 5.5 ou Gemini 3. En effet, différents agents de codage penseront différemment et seront ainsi, dans certains scénarios, plus à même de découvrir des bugs.

Détection avant la validation

Les hooks de pré-commit sont un concept dans lequel vous exécutez un morceau de code avant chaque validation pour vérifier les erreurs statiques. Il peut s’agir, par exemple, d’erreurs de traduction manquantes, ce qui est un hook de pré-validation courant que de nombreuses bases de code ont implémenté. Bien sûr, ces hooks sont très efficaces et très utiles car si vous avez oublié d’ajouter une traduction, ils vous le feront savoir avant d’effectuer la validation. Certaines erreurs ne peuvent pas être détectées avec les hooks de pré-validation, mais dans ces scénarios, il peut être très utile de demander simplement à un agent d’effectuer rapidement une analyse préalable à la validation. C’est ici que l’agent effectue l’implémentation que vous venez de réaliser et recherche les erreurs potentielles. Dans de nombreux cas, cela me fait gagner beaucoup de temps car je n’ai pas besoin de soumettre le code à une révision de code. Je peux corriger les erreurs immédiates immédiatement.

Faire cela revient essentiellement à demander à l’agent :

La production du code est-elle prête ?

Cela semble très simple, mais cela peut en fait être très utile et permet parfois de découvrir des erreurs grâce à mon expérience.

Conclusion

Dans cet article, j’ai expliqué comment coder à l’aide d’agents de codage et m’assurer qu’ils produisent un code robuste. Bien entendu, les agents de codage se sont beaucoup améliorés depuis la sortie de ChatGPT en 2022. Cependant, ils sont toujours sujets à des erreurs, surtout s’ils ne sont pas utilisés correctement. J’ai abordé deux techniques principales, notamment comment créer un code initialement robuste et comment vérifier le code après sa mise en œuvre pour rechercher les bogues potentiels et les problèmes qui peuvent survenir avec le code. En général, je pense que le réglage de vos agents de codage pour des performances optimales deviendra extrêmement important à l’avenir, et de nombreuses techniques que j’aborde dans cet article resteront pertinentes même si les performances génériques ou générales des LLM augmentent considérablement. Je vous invite simplement à prendre en compte les conseils et à optimiser vos agents de codage.

👋 Entrer en contact

👉 Mon eBook et mon webinaire gratuits :

🚀 10x votre ingénierie avec les LLM (cours gratuit par e-mail de 3 jours)

📚 Obtenez mon ebook gratuit sur les modèles de langage de vision

💻 Mon webinaire sur les modèles de langage de vision

👉 Retrouvez-moi sur les réseaux sociaux :

💌 Sous-pile

🔗 LinkedIn

🐦 X/Twitter