Claude Code : Optimiser les invites pour une efficacité maximale

Applications LLM

Maximiser l'efficacité avec Claude Code

Dans le monde de la programmation assistée par intelligence artificielle, la manière dont les demandes, ou "invites", sont formulées à des agents de codage comme Claude Code peut faire une grande différence. Bien que les modèles de langage de grande taille (LLM) soient devenus extrêmement puissants, la précision et l'efficacité de leurs réponses dépendent encore largement de la qualité des invites qui leur sont fournies.

Pourquoi optimiser la manière dont les invites sont formulées

Tout d'abord, on pourrait penser que la manière dont les invites sont rédigées n'a plus vraiment d'importance, car les LLM sont devenus si puissants qu'ils peuvent comprendre de toute façon. Dans une certaine mesure, cette idée est compréhensible. Cependant, il existe toujours de bonnes et de mauvaises façons de formuler des invites.

Une bonne invite serait explicite sur ce qui est souhaité, inclurait comment tester l'implémentation, et clarifierait toute ambiguïté. Par contre, une mauvaise invite pourrait faire des hypothèses qui ne correspondent pas à la base de code existante.

De plus, la formulation des invites n'est pas simplement une action unique effectuée pour un fil de discussion spécifique. C'est aussi la science de travailler de manière itérative avec le modèle pour établir un plan d'implémentation d'une fonctionnalité. Ainsi, une bonne invite pourrait également inclure des éléments comme demander au modèle de découvrir des ambiguïtés et d'en discuter, ou de lui indiquer quelles hypothèses faire.

Comment formuler des invites pour Claude Code

La manière dont les invites sont formulées pour Claude Code spécifiquement est abordée ici. Quelques techniques sont expliquées pour tirer le meilleur parti de Claude Code, bien que ces techniques soient très générales et s'appliquent également à tous les autres agents de codage, comme Codex.

Le premier sujet abordé est l'utilisation d'un outil de transcription pour transmettre toutes les pensées aux agents de codage. Actuellement, un outil de transcription appelé FluidVoice est utilisé, qui est un modèle pouvant être exécuté localement gratuitement et qui est incroyablement efficace, à la fois rapide et précis pour transcrire du texte en anglais.

Les outils de transcription sont évidemment très précieux car ils sont plus rapides que la saisie manuelle. Bien sûr, la rapidité dépend de la capacité à taper, mais il est raisonnable de supposer qu'on peut parler, en moyenne, deux à trois fois plus vite que taper sur un ordinateur. De plus, cela évite de fatiguer les mains et permet de se concentrer sur la saisie.

Un autre avantage remarqué est une plus grande inclination à inclure tout le contexte dont l'agent de codage a besoin pour effectuer une tâche. Lorsque tout devait être tapé à la main, il y avait des moments où tout le contexte n'était pas écrit simplement parce que cela prenait beaucoup de temps. Cela est bien sûr très mauvais, car si Claude Code ne reçoit pas le contexte nécessaire pour résoudre une tâche, il lui sera très difficile de la résoudre. Cependant, maintenant que la transcription est utilisée au lieu de taper, il est beaucoup plus facile d'inclure tout le contexte nécessaire, et cela demande très peu d'effort.

Dans l'ensemble, les outils de transcription sont très bénéfiques car ils font gagner beaucoup de temps et facilitent l'inclusion de tout le contexte nécessaire à fournir à l'agent de codage pour qu'il puisse effectuer la tâche efficacement.

Indiquer au modèle comment tester

Un autre point très important est d'indiquer au modèle comment tester. Supposons qu'il soit demandé au modèle d'implémenter la fonctionnalité A. C'est bien, mais il faut également lui dire comment tester cette fonctionnalité. Par exemple, si une fonctionnalité de chat est implémentée dans une application, il faut indiquer au modèle qu'il doit ouvrir le chat dans Chrome, taper une requête et s'assurer que l'IA répond correctement et que les flux de tokens fonctionnent.

En gros, il faut dire au modèle comment il peut savoir qu'il a correctement implémenté la fonctionnalité. Cela fera gagner beaucoup de temps, car il ne sera pas nécessaire de tester la fonctionnalité soi-même autant, et le modèle présentera une fonctionnalité plus opérationnelle immédiatement.

Avoir une discussion avec le modèle

Une idée reçue courante concernant la formulation des invites pour les agents de codage est qu'il suffit de fournir une invite unique et de laisser le modèle travailler jusqu'à ce qu'il ait terminé. Si la configuration d'invite parfaite est en place, cela est possible, car les agents sont capables de travailler pendant de nombreuses heures et d'accomplir beaucoup de tâches. Cependant, cela ne prend pas en compte la manière de construire l'invite parfaite.

Pour un humain, il est pratiquement impossible de construire une invite parfaite, car il est impossible d'avoir le contexte complet de l'ensemble de la base de code. Il y a simplement trop de code, trop de choses à prendre en compte et un contexte qui pourrait être oublié, ce qui n'est pas possible à retenir dans la mémoire à court terme. Cependant, pour les agents de codage, ils sont capables de stocker tout cela dans leur mémoire, ce qui en fait un très bon partenaire de discussion.

En gros, ce qui devrait être fait chaque fois qu'un agent de codage est utilisé, que ce soit pour implémenter une nouvelle fonctionnalité, résoudre un bug ou autre, c'est d'avoir une discussion avec l'agent de codage. Il faut demander à l'agent de codage de rechercher le sujet, de vérifier les journaux, de chercher en ligne s'il y a quelque chose de pertinent, etc. Et faire en sorte que l'agent pose toutes les questions sur les éléments ambigus.

Lorsque les agents de codage écrivent du code, ils font un tas d'hypothèses. Beaucoup plus d'hypothèses que l'on ne pourrait même en être conscient. La raison en est qu'il y a trop de décisions à prendre dans le codage pour que l'agent de codage puisse poser des questions à chaque fois. Lorsque les humains codent également, ils doivent faire un certain nombre d'hypothèses, parfois conscientes, parfois inconscientes. Cependant, lors de la planification, il est souhaitable que le modèle partage au moins les hypothèses significatives qu'il fait.

Un exemple d'une telle hypothèse pourrait être de savoir s'il faut implémenter l'infrastructure directement via une CLI, par exemple pour AWS, ou de l'implémenter en tant que CDK, donc en tant que code. Ce n'est pas un exemple parfait, car dans presque tous les cas, la bonne réponse est qu'il faudrait l'implémenter en tant que code et non directement via la CLI. Mais c'est un exemple d'une décision dont il est souhaitable d'être conscient afin que l'agent de codage ne fasse rien qui ne soit pas souhaité. Essentiellement, cette discussion avec l'agent de codage permet d'aligner l'implémentation dans l'esprit avec ce que l'agent de codage va réellement implémenter.

Rapports HTML

Une dernière chose abordée dans cet article est les rapports HTML. Lorsque les agents de codage travaillent, il y a beaucoup d'informations. L'agent écrira beaucoup de sorties dans le terminal, dont la plupart ne concernent pas directement, par exemple, les appels d'outils ou simplement des tokens de réflexion, etc. Cependant, parfois, il est nécessaire d'examiner ce que l'agent de codage fait. Cela pourrait, par exemple, être le plan qu'il a établi lors de la dernière tâche où il est souhaité avoir une discussion avec le modèle sur la manière d'implémenter une fonctionnalité. Dans ces cas, il est presque toujours recommandé de demander au modèle de créer des rapports HTML pour visualiser ce dont il est discuté, ce qui facilite grandement la fourniture de retours au modèle.

Soyons très spécifiques ici. Supposons qu'une fonctionnalité A soit en cours d'implémentation, mais qu'il y ait plusieurs décisions que le modèle souhaite discuter avant de commencer l'implémentation. Dans ce cas, il est demandé au modèle de générer un rapport HTML avec chaque décision listée, y compris le contexte tel que :

• Quelles sont les différentes options pour cette décision
• De quoi traite la décision
• Avantages et inconvénients de la décision

Cela rend incroyablement simple de comprendre quelles sont les différentes options pour chaque décision et d'avoir une vue d'ensemble des décisions à prendre. Et c'est beaucoup plus facile que de lire et de comprendre cela via le terminal, par exemple. Un autre avantage des rapports HTML est que des visuels peuvent être créés, comme des diagrammes, des organigrammes, des SVG, etc.

Des rapports HTML sont également réalisés pour les tests. Donc, disons que le modèle a implémenté une fonctionnalité demandée ou corrigé un bug. Il est demandé de créer un rapport HTML contenant chaque partie de la fonctionnalité ou du bug, avec des détails sur la manière dont cela a été testé et les résultats des tests. Cela permet de voir clairement ce qui a été fait et comment cela fonctionne, ce qui est essentiel pour s'assurer que tout fonctionne comme prévu.