Exemples d’ingénierie des prompts pour les ingénieurs logiciels
Des exemples concrets d’ingénierie des prompts pour le débogage, la refactorisation, les tests, l’architecture, la revue de code et la documentation.
Un prompt d’ingénierie utile amène l’assistant à raisonner à partir du problème, des preuves, des contraintes et des critères d’acceptation, plutôt qu’à partir d’une instruction isolée. Les exemples ci-dessous montrent comment cela transforme le débogage, la refactorisation, les tests, l’architecture, la revue de code et la documentation.
Chaque meilleur prompt est volontairement précis sur la décision que l’assistant doit prendre. Vous pouvez le raccourcir lorsque la tâche est petite, mais conservez les informations qui empêchent une modification inadaptée au produit.
Déboguer un paiement instable
Problème
Une requête de paiement réussit parfois après une nouvelle tentative, mais l’interface affiche toujours la première erreur.
Prompt faible
Corrige l’erreur de paiement instable.
Meilleur prompt
Symptôme : une requête de paiement peut échouer une première fois à cause d’un
délai d’expiration, puis réussir lors de la nouvelle tentative automatique.
L’écran de réussite n’apparaît pas après cette nouvelle tentative.
Attendu : une nouvelle tentative réussie doit remplacer l’état d’erreur et
activer l’étape suivante du paiement.
Observé : les journaux réseau indiquent une réponse 200, mais la première
bannière d’erreur reste affichée.
Périmètre : inspecte uniquement la mutation de paiement, le rappel de nouvelle
tentative et l’état de l’écran.
Contraintes : conserve l’intégration existante avec le fournisseur de paiement
et le texte des erreurs. Ne masque pas les erreurs avant qu’une requête ait
effectivement réussi.
Commence par fournir deux ou trois hypothèses fondées sur des preuves ainsi que
le plus petit scénario de reproduction ou signal de journal qui permettrait de
les distinguer. Propose ensuite un correctif minimal et un test de régression.
Pourquoi cela fonctionne
Le prompt sépare les preuves de l’hypothèse. Il demande un diagnostic des transitions d’état avant toute réécriture et protège l’intégration de paiement contre une modification sans rapport.
Refactoriser une logique de formulaire répétée
Problème
Trois formulaires de paramètres répètent le même code pour les états de chargement, d’erreur et d’enregistrement.
Prompt faible
Refactorise ces formulaires pour supprimer la duplication.
Meilleur prompt
Les formulaires de compte, de notifications et de profil dupliquent le rendu de
l’état d’enregistrement. Identifie le comportement exactement répété et les
endroits où les formulaires diffèrent.
Résultat : réduis le rendu dupliqué sans modifier les props publiques des
formulaires, le moment de la validation, les erreurs localisées, les événements
d’analytique ni le comportement au clavier.
Périmètre : les trois formulaires de paramètres et leurs tests directs.
Hors objectif : ne crée pas de framework général de formulaires et ne déplace
pas la responsabilité des requêtes hors des hooks de fonctionnalité existants.
Recommande l’extraction la plus réduite, montre le contrat préservé et ajoute ou
mets à jour les tests de chargement, d’échec et de réussite pour chaque formulaire.
Pourquoi cela fonctionne
« Supprimer la duplication » est un objectif, pas une conception. Le meilleur prompt demande à l’assistant de trouver le véritable point commun et évite une abstraction surdimensionnée.
Écrire un test de condition de concurrence
Problème
Les résultats d’une ancienne requête lente peuvent écraser ceux d’une requête plus récente.
Prompt faible
Ajoute des tests pour la recherche.
Meilleur prompt
Ajoute une couverture de régression pour une condition de concurrence dans la
recherche.
Scénario : un utilisateur recherche "network", remplace immédiatement la requête
par "terminal", puis la réponse pour network arrive en dernier.
Attendu : l’interface affiche uniquement les résultats pour "terminal". La
réponse plus ancienne ne doit pas les remplacer.
Utilise la pile de tests existante et des assertions accessibles. Évite
d’affirmer des noms d’état internes. Si le code de production ne peut pas
exprimer clairement l’annulation ou la fraîcheur, explique la plus petite
modification nécessaire avant d’écrire le test.
Pourquoi cela fonctionne
Le prompt de test définit le temps, l’action de l’utilisateur et le comportement visible. Il ne laisse pas un détail d’implémentation commode devenir le contrat du test.
Évaluer une modification d’architecture
Problème
Une équipe doit décider si elle doit ajouter une deuxième couche de cache pour la configuration.
Prompt faible
Ajoute un cache pour la configuration afin de rendre l’application plus rapide.
Meilleur prompt
Évalue si un cache de configuration côté client améliorerait l’écran lent sans
créer de décisions obsolètes concernant les droits ou les préférences.
Contexte : l’application dispose déjà d’un provider de configuration et l’écran
attend un utilisateur authentifié. Nous n’avons pas mesuré si la récupération
ou le rendu constitue le goulot d’étranglement.
Compare : l’absence de cache, un cache en mémoire limité et le cache persistant
proposé. Évalue la fraîcheur, l’invalidation, la confidentialité, le
fonctionnement hors ligne et la mesure nécessaire pour justifier la modification.
N’implémente rien avant d’indiquer quelle option tu recommandes et pourquoi.
Pourquoi cela fonctionne
Le prompt rend « plus rapide » mesurable et demande à l’assistant de remettre la prémisse en question. Un cache n’améliore pas automatiquement les performances.
Examiner un diff risqué
Problème
Une pull request modifie les autorisations et la navigation visible par les utilisateurs dans la même fonctionnalité.
Prompt faible
Examine cette pull request.
Meilleur prompt
Examine ce diff pour détecter des régressions d’autorisation, une navigation qui
casse les locales et des changements de comportement masqués par une refactorisation.
Remonte chaque décision d’autorisation modifiée jusqu’à son appelant. Vérifie que
les liens internes conservent la locale active et que les états de refus ne
révèlent pas de données protégées.
Signale uniquement les problèmes étayés par le diff ou ses sites d’appel directs.
Donne la priorité à la correction et à la sécurité avant les suggestions de style.
Liste séparément les tests manquants et les défauts confirmés.
Pourquoi cela fonctionne
La revue possède un modèle de menace et un périmètre. Cela produit un résultat plus court et plus exploitable qu’une demande de commentaires génériques.
Mettre à jour la documentation après un changement d’outil
Problème
La commande de configuration locale a changé et le guide de démarrage est désormais obsolète.
Prompt faible
Mets à jour la documentation de configuration.
Meilleur prompt
Mets à jour le guide de configuration locale pour les scripts de package actuels.
Vérifie chaque commande documentée dans package.json et dans les instructions de
configuration du dépôt. Explique les prérequis, la sortie attendue lorsque le
service est prêt, les signaux d’échec fréquents et une procédure de récupération sûre.
Ne documente pas de secrets, de valeurs copiées depuis un environnement local ni
de commandes que le projet n’exécute pas réellement. Ajoute une courte liste de
vérifications pour une nouvelle personne qui contribue au projet.
Pourquoi cela fonctionne
L’assistant doit ancrer le texte dans le dépôt plutôt que de produire un guide soigné mais fictif.
Utilisez l’exemple qui correspond à votre tâche
Le schéma répété est simple : nommez le problème, resserrez le périmètre, protégez les comportements importants, demandez des preuves et définissez la validation. Commencez par le cadre réutilisable de comment écrire de meilleurs prompts d’IA, puis consultez l’ingénierie des prompts pour les développeurs pour un flux de travail organisé par rôle d’ingénierie.
Les problèmes en production nécessitent une trace de preuves encore plus stricte. Poursuivez avec les modèles de prompts pour déboguer des problèmes en production avant de demander à un assistant de proposer un correctif pour un système en direct. Lorsqu’un bug implique une sortie shell ou un script, reproduisez le flux de travail en ligne de commande dans le navigateur avant d’automatiser une solution.
Références
Ces liens de documentation fournissent des informations fiables sur les commandes utilisées dans cet article.