Je suis généralement réticent à l’habitude répandue qui consiste à chercher des analogies avec l’ancien monde pour expliquer des phénomènes du nouveau monde. Alors merci de me pardonner pendant que je commets exactement ce péché : laissez‑moi expliquer pourquoi le prompting devrait être appelé conception de prompts et être comparé au web design.

Je considère le prompting comme une communication avec un humain soumis à une forte contrainte de temps. Bien que les techniques spécifiques aux LLM soient certainement utiles (notamment la technique de chain‑of‑thought), j’ai constaté que l’un des meilleurs moyens d’améliorer les performances est simplement d’avoir des instructions extrêmement claires et de grande qualité, de la même façon que la clarté et la concision aident aussi les vrais humains à mieux comprendre.

Le prompting comme communication claire fait ressembler le prompting à de l’écriture. La plupart du prompting que je fais, cependant, est paramétrique : j’ai un certain nombre de variables d’entrée et je dois adapter dynamiquement mon prompt en fonction de celles‑ci.

Ainsi, le prompting comme communication claire avec entrée dynamique me semble être la caractérisation la plus exacte.

Quel autre domaine consiste à communiquer clairement avec une entrée dynamique ? Le web design.

Énumérons toutes les similarités. Le prompting et le web design :

1. requièrent de la clarté, et ont la communication comme objectif principal ;

2. doivent répondre à un contenu dynamique, contrairement à l’écriture ou à la mise en page d’un magazine ; et

3. doivent adapter leur contenu à différentes tailles — tailles d’écran pour le web design, fenêtres de contexte pour le prompting.

D’après mon expérience en prompting et en web design, j’ai aussi constaté que j’ai des préférences de développeur similaires dans les deux domaines :

1. Regarder le prompt réel est extrêmement important, tout comme regarder le site web tel qu’il est rendu est extrêmement important. Je ne peux pas concevoir un site web si je dois simuler dans ma tête le processus de rendu HTML et CSS. De même, il est vraiment difficile d’écrire de bons prompts, clairs, sans regarder le rendu final d’un prompt avec toutes les variables d’entrée renseignées.

2. Par exemple, le prompt "Hi ${username} ${message}" peut sembler raisonnable, jusqu’à ce que vous le rendiez et réalisiez que le nom d’utilisateur se fond dans le message.

3. Les composants composables sont utiles à la fois pour le prompting et pour le web design.

4. Le déclaratif est meilleur que l’impératif dans les deux cas. Il est vraiment difficile de modifier un site web où tous les éléments HTML sont créés avec des appels à document.createElement. De même, lire et modifier un prompt qui consiste en une longue séquence de str += "..." devient facilement ingérable.

5. Dans les deux cas, je veux parfois atteindre une « perfection au pixel près ». Quand je fais du prompting avec des modèles moins capables (GPT‑3.5 et moins), je veux m’assurer qu’il n’y a pas de sauts de ligne superflus ni d’autres types de mise en forme imparfaite, et lorsque je conçois un site web, chaque pixel compte parfois.

Pour les agents LLM, il est possible d’aller encore plus loin dans l’analogie : le prompting des agents peut être vu comme la création d’un site web interactif pour les agents, où ils peuvent « cliquer sur des boutons » en appelant des fonctions, et où le prompt est à nouveau rendu en réponse à un appel de fonction, tout comme un site web se ré‑affiche en réponse à un clic sur un bouton.

Bien sûr, il existe des différences entre la conception de prompts et le web design :

1. Le prompting ne traite que du texte (pour l’instant !).

2. La mise en cache est différente : pour les agents en particulier, vous voulez vous assurer que vos ré‑affichages sont peu coûteux en ne modifiant que les dernières parties du prompt. On peut établir ici un parallèle un peu artificiel avec le web (vous voulez optimiser la mise en cache de votre site), mais je pense que c’est fondamentalement un défi assez différent.

Néanmoins, ces similarités m’ont convaincu que le prompting devrait être appelé conception de prompts, et non prompt engineering. Écrire un prompt donne exactement la même impression que concevoir un site web, et devrait donc être nommé de la même façon.

La perspective de la conception de prompts m’a inspiré à créer Priompt, une bibliothèque de conception de prompts inspirée de React et basée sur JSX.

#Priompt v0.1 : une première tentative de bibliothèque de conception de prompts

Priompt est une première tentative de création d’une bibliothèque de conception de prompts, inspirée par les principes de conception web modernes. Nous l’utilisons en interne chez Cursor, et on l’apprécie beaucoup.

Je pense que ce n’est sans doute pas parfaitement juste dans toutes ses abstractions, mais je suis au moins convaincu que JSX est une manière bien plus ergonomique d’écrire des prompts que des modèles de chaînes de caractères. Même le fait tout simple de pouvoir commenter facilement certaines parties de votre prompt rend la boucle d’itération beaucoup plus rapide.

Priompt est également fourni avec un site d’aperçu (mis en place très rapidement), où vous pouvez visualiser votre prompt sur de vraies données. Lors du développement de votre application, vous pouvez consigner dans les logs les props sérialisés qui arrivent dans un composant à chaque requête. Ensuite, lorsque vous observez un comportement inattendu, vous pouvez aller sur l’aperçu Priompt, regarder le prompt exact, puis modifier le code source et voir le prompt se mettre à jour avec les mêmes props que la requête réelle. Nous avons constaté que cela facilite l’itération sur les prompts.

Si vous l’essayez, dites-moi ce que vous en pensez ! J’adorerais voir plus d’idées dans le même esprit, ou simplement qu’on me dise que j’ai complètement tort et que la conception de prompts est stupide :)

#Mises en garde

Les modèles évoluent très vite, et les techniques de prompting doivent suivre le rythme. En ce sens, je pense qu’il y a quelques mises en garde à formuler concernant la caractérisation en conception de prompts :

1. Les designs au pixel près sont sans importance pour GPT-4, et seront probablement obsolètes pour GPT-4.5 ou des modèles plus performants.

2. La contrainte de fenêtre de contexte pourrait disparaître, si l’on extrapole la tendance récente des modèles à long contexte. Je n’en suis toutefois pas convaincu.

3. OpenAI semble évoluer vers un modèle où les développeurs ont de moins en moins de contrôle sur le prompt ; il est possible que dans un an il n’y ait plus vraiment de prompt, l’appel d’API nous demandant simplement les entrées brutes plus une instruction. Cette tendance vers moins de contrôle a commencé avec le format de chat et s’est poursuivie avec la fonctionnalité d’appel de fonctions récemment annoncée.

4. Il est possible que la mise en cache soit l’un des aspects les plus importants du prompting, auquel cas cela commence à ressembler un peu plus à de l’ingénierie qu’à du design.

5. Il est peut-être souhaitable que la conception de prompts reste à un niveau trop bas et soit déléguée à un framework ou à un compilateur de plus haut niveau (par exemple LangChain). Je pense que cela peut être vrai, mais étant donné la nature très changeante des modèles de langage de grande taille (LLM), je préfère personnellement rester aussi proche que possible du modèle brut.

#Dernière note obligatoire

...parce que j’adorerais travailler avec vous : chez Cursor, nous construisons Cursor, un éditeur de code conçu dès le départ pour l’IA. Si la conception de prompts, les LLM appliqués au code ou la création de produits remarquables vous enthousiasment, envoyez-moi un e-mail à arvid@cursor.com. Nous sommes une équipe de 5 personnes à San Francisco, tous mes collègues sont exceptionnels, et nous voulons quelques autres personnes tout aussi exceptionnelles — développeurs et designers — pour nous rejoindre et construire ensemble l’avenir du développement logiciel.