La bonne façon d'écrire des prompts pour les agents de code IA
Voilà comment la plupart des développeurs utilisent un agent de code IA. Ils ouvrent la fenêtre de chat et tapent quelque chose comme « ajoute un bouton de mode sombre à la page des réglages ». L'agent produit un résultat. Ça marche à peu près. Il reste des coins à polir. Le développeur passe les vingt minutes suivantes à faire des allers-retours pour tout rafistoler.
Ensuite il conclut que le modèle n'est pas si bon.
Le modèle est bon. Le problème vient du prompt.
Chaque ambiguïté dans votre prompt est une décision que le modèle prend sans vous. La préférence de mode sombre doit-elle être conservée d'une session à l'autre ? Faut-il respecter le réglage du système d'exploitation ? Où stocke-t-on la préférence, dans localStorage, dans un profil utilisateur en base de données ou dans un cookie ? Quelle bibliothèque de composants est utilisée et comment le thème fonctionne-t-il à l'intérieur ?
Vous n'avez rien dit. Alors le modèle devine. Parfois il tombe juste. Souvent non. Et vous vous retrouvez avec du code qui marche dans un environnement et casse dans un autre, ou avec un composant qui ignore la préférence déjà réglée par l'utilisateur.
C'est un problème d'information.
Voici ce que les équipes sérieuses qui montent des flux de développement assisté par IA ont compris. Le modèle sait mieux que la plupart des développeurs ce dont il a besoin pour bien faire une tâche et comment le demander.
Il a traité un volume énorme de tâches d'ingénierie bien spécifiées, donc il sait à quoi ressemble une demande de fonctionnalité complète et ce qui manque d'habitude dans un rapport de bug vague. L'astuce est de le faire vous dire ce qui manque avant de lui demander quoi que ce soit.
Le flux ressemble à ceci :
Cette dernière étape est optionnelle mais vaut la peine. Vous pouvez demander à l'agent : « À partir de mes réponses, réécris ma demande initiale en spécification complète de la tâche. » Ce que vous récupérez, c'est un prompt que le modèle lui-même juge assez complet pour bien exécuter. Vous soumettez alors ce prompt comme tâche réelle.
Certains appellent déjà cela l'ingénierie inverse de prompt pour l'exécution de tâches. Le modèle montre ce que contiendrait un prompt parfait, et vous travaillez à partir de là.
Disons que vous voulez ajouter un bouton de mode sombre à une page de réglages. Voilà comment les deux approches se déroulent.
L'approche naïve :
« Ajoute un bouton de mode sombre à la page des réglages. »
L'agent produit un composant avec un bouton codé en dur, enregistre la préférence dans l'état du composant pour qu'elle se réinitialise au rafraîchissement, ignore le système de thème existant et utilise des styles en ligne au lieu de vos variables CSS ou de vos tokens de thème.
Vous passez l'heure suivante à corriger.
L'approche du prompt inversé :
Vous partez de la même phrase puis vous demandez : « Avant de commencer, de quoi auriez-vous besoin pour implémenter ça correctement ? Qu'est-ce que je devrais clarifier ? »
L'agent répond quelque chose comme :
- Où la préférence doit-elle être conservée (localStorage, base de données, cookie) ?
- Existe-t-il un système de thème (next-themes, variables CSS, variante dark de Tailwind) ?
- Le bouton doit-il respecter le mode sombre du système d'exploitation comme valeur par défaut ?
- Où placer ce bouton dans la page des réglages ? Y a-t-il déjà une section « Apparence » ?
- La préférence doit-elle se synchroniser entre les sessions si l'utilisateur est connecté ?
Vous répondez à ces questions. Vous dites à l'agent que l'app utilise next-themes, que les préférences sont enregistrées dans le profil utilisateur via un endpoint PATCH /users/me existant et qu'il y a déjà une section « Apparence » dans la page des réglages avec d'autres boutons qui suivent un patron de composant précis.
L'agent a maintenant ce qu'il lui faut. L'implémentation qu'il produit se connecte au bon fournisseur de thème, utilise l'API existante, respecte le patron d'interface en place et gère le repli sur le mode sombre du système. Vous n'avez rien à corriger.
Les rapports de bug sont l'endroit où le prompt vague fait le plus de dégâts. Un modèle sans contexte produit du code sûr de lui mais faux.
Imaginez que quelqu'un signale un bug : « Le bouton de connexion ne fonctionne parfois pas. »
L'approche naïve : Vous collez ça dans votre agent. Il commence à parcourir le code d'authentification, repère un motif async/await suspect, décide que c'est probablement ça, réécrit la fonction et ouvre une PR. Le bug est toujours là. La fonction qu'il a modifiée n'avait aucun rapport.
L'approche du prompt inversé :
Vous donnez le rapport de bug à l'agent et vous demandez : « De quoi auriez-vous besoin pour diagnostiquer ça efficacement ? Quelles questions un ingénieur senior poserait-il avant de toucher au code ? »
Il répond :
- Que veut dire « ne fonctionne pas » ? Le bouton ne répond pas aux clics, le clic se produit mais rien ne se passe, ou un message d'erreur s'affiche ?
- Le problème est-il reproductible en permanence ou intermittent ? Y a-t-il un motif (navigateur précis, conditions réseau, état de l'utilisateur) ?
- Y a-t-il des erreurs de console ou des requêtes réseau qui échouent quand ça arrive ?
- Quel composant gère le clic sur le bouton, et quel service gère l'authentification ?
- Est-ce que ça a toujours été cassé ou est-ce une régression récente ? Si c'est une régression, qu'est-ce qui a changé ?
Vous revenez vers la personne qui a signalé le bug et vous obtenez les réponses. C'est intermittent et ça ne se produit qu'après plus de dix minutes passées sur la page. Pas d'erreur de console, mais la requête réseau ne part jamais. C'est un bug complètement différent. La cause probable est une expiration de token ou une fermeture obsolète dans un gestionnaire d'événements.
Vous donnez cette information à l'agent, et il va maintenant au bon endroit. Il trouve un useCallback avec une dépendance obsolète qui capture un token d'authentification depuis le rendu initial. La correction tient en un seul changement ciblé.
Si la plupart du développement assisté par IA ressemble à une négociation, c'est parce que le prompt initial laisse trop de décisions au modèle. Vous allez et venez pour affiner le résultat sur plusieurs tours. Chaque tour de révision consiste à corriger une hypothèse que le modèle a faite parce que vous n'aviez rien précisé.
Le prompt inversé réduit presque tous ces tours à une seule conversation menée au départ. Les questions du modèle vous disent exactement quelles décisions il aurait prises seul. Vous les prenez à sa place. Le résultat sort juste du premier coup parce qu'il disposait d'informations complètes.
Il y a aussi un bénéfice secondaire. Les questions posées par le modèle forment une checklist. Si vous utilisez la même technique de façon régulière pour des tâches semblables, comme ajouter de nouveaux réglages ou corriger des bugs d'authentification, les questions deviennent familières. Avec le temps, vous apprenez à inclure ces détails dans vos prompts sans qu'on vous les demande, et la qualité de base de vos prompts s'améliore.
Cette technique fonctionne mieux avec les agents qui ont accès aux outils et aux fichiers, comme Cursor ou GitHub Copilot en mode agent. Un agent qui peut lire votre base de code pose des questions bien plus précises qu'un agent qui travaille à l'aveugle.
Le flux en deux temps (ce qu'il vous faut -> le voici -> maintenant la tâche) ajoute bien une étape. Pour les petites tâches bien définies, c'est superflu. Mais pour tout ce qui touche plusieurs fichiers ou s'intègre à des systèmes existants, le résultat est régulièrement meilleur que d'aller droit à l'implémentation.
La spécification générée à l'étape 3 vaut la peine d'être conservée. C'est un modèle réutilisable. La prochaine fois que quelqu'un devra ajouter un réglage qui se sauvegarde dans le profil utilisateur, vous aurez déjà un prompt bien spécifié.
La façon dont la plupart des développeurs écrivent des prompts pour les agents de code est optimisée pour la vitesse au détriment de la qualité. Une phrase rapide envoyée, un résultat médiocre en retour, puis dix minutes de nettoyage. Et ça se répète des dizaines de fois par jour.
L'approche du prompt inversé inverse ce compromis. Vous passez un peu plus de temps au départ à vous assurer que le modèle a ce qu'il lui faut. En échange, le résultat se rapproche de ce que vous vouliez, et vous passez moins de temps à le corriger.
Le meilleur prompt pour une tâche est celui que le modèle vous dit qu'il lui faut.
© Melvin Laplanche - All rights reserved.