La recherche en IA te passionne ?
Les papers et avancées qui comptent, expliqués simplement, chaque soir. Gratuit.
Inclus dès l'inscription : notre sélection des meilleurs guides & comparatifs IA.
Choisis ton rythme
Gratuit · Pas de spam · Désabonnement en 1 clic
Applications LLM
Maximiser l'efficacité avec Claude Code
Dans le monde de la programmation assistée par intelligence artificielle, la manière dont vous formulez vos demandes, ou "invites", à 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 que vous leur fournissez.
Pourquoi optimiser la manière dont vous formulez vos invites
Tout d'abord, vous pourriez penser que la manière dont vous rédigez vos invites n'a plus vraiment d'importance, car les LLM sont devenus si puissants qu'ils peuvent vous comprendre de toute façon. Dans une certaine mesure, je suis d'accord avec cette idée. Cependant, il existe toujours de bonnes et de mauvaises façons de formuler des invites.
Une bonne invite serait explicite sur ce que vous voulez, 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 que vous effectuez 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 avec vous, ou de lui indiquer quelles hypothèses faire.
Comment je formule mes invites pour Claude Code
Je vais maintenant aborder la manière dont je formule mes invites pour Claude Code spécifiquement. Je vais vous expliquer quelques techniques que j'utilise 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 que j'aimerais aborder est que j'utilise un outil de transcription pour transmettre toutes mes pensées aux agents de codage. Actuellement, j'utilise un outil de transcription appelé FluidVoice, qui est un modèle que vous pouvez exécuter 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 votre capacité à taper, mais il est raisonnable de supposer que vous pouvez parler, en moyenne, deux à trois fois plus vite que vous ne pouvez taper sur votre ordinateur. De plus, cela vous évite de fatiguer vos mains et de vous concentrer sur la saisie.
Un autre avantage que j'ai remarqué est que je suis plus enclin à inclure tout le contexte dont mon agent de codage a besoin pour effectuer une tâche. Lorsque je devais tout taper à la main, il y avait des moments où je ne voulais pas écrire tout le contexte simplement parce que cela prenait beaucoup de temps. Cela est bien sûr très mauvais, car si vous ne donnez pas à Claude Code le contexte nécessaire pour résoudre une tâche, il lui sera très difficile de la résoudre. Cependant, maintenant que je transcris au lieu de taper, il est beaucoup plus facile pour moi 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 vous font gagner beaucoup de temps et facilitent l'inclusion de tout le contexte que vous devez 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 que vous demandiez au modèle d'implémenter la fonctionnalité A. C'est bien, mais vous devez également lui dire comment tester cette fonctionnalité. Par exemple, si vous implémentez une fonctionnalité de chat dans votre application, vous devez 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, vous devez dire au modèle comment il peut savoir qu'il a correctement implémenté la fonctionnalité. Cela vous fera gagner beaucoup de temps, car vous n'aurez pas à tester la fonctionnalité vous-même autant, et le modèle vous 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 que vous fournissez simplement une invite unique et laissez le modèle travailler jusqu'à ce qu'il ait terminé. Si vous avez la configuration d'invite parfaite, 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 vous, en tant qu'humain, ne pouvez pas 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 que vous pourriez oublier, ce qui n'est pas possible à retenir dans votre 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 que vous devriez faire chaque fois que vous commencez avec un agent de codage, que ce soit pour implémenter une nouvelle fonctionnalité, résoudre un bug ou autre, c'est d'avoir une discussion avec votre agent de codage. Vous devriez demander à votre 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 vous pose toutes les questions sur les éléments ambigus.
Lorsque les agents de codage écrivent du code pour vous, ils font un tas d'hypothèses. Beaucoup plus d'hypothèses que vous n'en êtes même conscient. La raison en est qu'il y a trop de décisions à prendre dans le codage pour que l'agent de codage puisse vous demander à 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, vous voulez 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 que vous devriez l'implémenter en tant que code et non directement via la CLI. Mais c'est un exemple d'une décision dont vous, en tant qu'humain, souhaitez être conscient afin que l'agent de codage ne fasse rien que vous ne voudriez pas qu'il fasse. Vous avez essentiellement cette discussion avec votre agent de codage pour aligner l'implémentation dans votre esprit avec ce que l'agent de codage va réellement implémenter.
Rapports HTML
Une dernière chose que je veux aborder 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 votre terminal, dont la plupart ne vous concernent pas, par exemple, les appels d'outils ou simplement des tokens de réflexion, etc. Cependant, parfois, vous devez 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ù vous souhaitez avoir une discussion avec le modèle sur la manière d'implémenter une fonctionnalité. Dans ces cas, vous devriez presque toujours demander au modèle de créer des rapports HTML pour visualiser ce dont vous discutez, ce qui facilite grandement la fourniture de vos retours au modèle.
Soyons très spécifiques ici. Supposons que je sois en train d'implémenter la fonctionnalité A, mais qu'il y ait plusieurs décisions que le modèle souhaite discuter avec moi avant de commencer l'implémentation. Dans ce cas, ce que je fais, c'est que je demande 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 pour moi 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 vous pouvez créer des visuels, comme des diagrammes, des organigrammes, des SVG, etc.
Je fais également des rapports HTML pour les tests. Donc, disons que le modèle a implémenté une fonctionnalité que j'ai demandée ou corrigé un bug. Je lui demande 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 me 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.
