💻 computer science

Prompt Quality and Pull Request Outcomes: A Stage-Based Empirical Study of LLM-Assisted Development

Cette étude analyse empiriquement 265 interactions entre développeurs et ChatGPT dans des pull requests en open-source pour démontrer que des caractéristiques de prompt spécifiques — Contexte, Spécificité et Vérification — exercent des effets distincts et dépendants des étapes sur les résultats du développement logiciel assisté par l'IA, où la Spécificité et le Contexte pilotent la génération de code exploitable, la Vérification prédit l'adoption du code, et le Contexte détermine la profondeur d'intégration.

Auteurs originaux : Richard Sserunjogi, Daniel Ogenrwot, John Businge

Publié 2026-06-19

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Richard Sserunjogi, Daniel Ogenrwot, John Businge

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes un chef (le développeur) essayant de cuisiner un plat complexe, mais que vous avez un sous-chef très talentueux, bien qu'un peu littéral (l'IA). Vous ne pouvez pas simplement crier « Prépare le dîner ! » et vous attendre à un repas étoilé au Michelin. Vous devez donner des instructions spécifiques.

Cet article est une étude sur la manière dont la façon dont vous demandez de l'aide au sous-chef affecte l'ensemble du processus de cuisine, du premier ingrédient jusqu'à l'assiette finale servie au client.

Les chercheurs ont examiné 265 exemples réels où des développeurs ont partagé leurs conversations avec une IA (ChatGPT) au sein de projets logiciels. Ils voulaient voir si la qualité de la « demande de recette » (le prompt) déterminait si le code de l'IA était utile, accepté et réellement utilisé dans le produit final.

Voici le détail de leurs conclusions, en utilisant des analogies simples :

1. Les trois ingrédients d'une bonne demande

Les chercheurs ont décomposé chaque demande en trois parties, comme pour vérifier une fiche de recette :

Le Contexte (Le cadre) : Le développeur a-t-il expliqué où ce code s'insère ? (ex : « Ceci est pour l'écran de connexion de notre application bancaire. »)
La Spécificité (Les détails) : Le développeur a-t-il dit exactement ce qu'il voulait ? (ex : « Rends le bouton bleu et arrondi », et non pas « Fais en sorte qu'il soit joli. »)
La Vérification (Le test de goût) : Le développeur a-t-il indiqué comment vérifier si c'est correct ? (ex : « Si je clique ici, je devrais être connecté sans erreur. »)

2. Les trois étapes du flux de travail en cuisine

L'étude a révélé que la « demande parfaite » change selon l'étape du processus de cuisine dans laquelle vous vous trouvez. Il n'y a pas de solution universelle.

Étape 1 : Obtenir le premier brouillon (Génération de code)

Ce qui importe le plus : Le Contexte et la Spécificité.
L'analogie : Si vous voulez que l'IA rédige réellement une recette, vous devez lui dire quel type de nourriture vous préparez et lui donner des étapes claires.
Le constat : Si la demande était vague ou manquait d'informations de fond, l'IA donnait souvent une explication générique au lieu de produire du code réel. Mais si le développeur donnait un objectif clair et un peu de contexte, l'IA produisait presque toujours un code utilisable.
Ce qui n'importait pas encore : Le fait que la demande inclue ou non un « test de goût » (Vérification) n'empêchait pas l'IA d'écrire le code.

Étape 2 : Décider d'utiliser le brouillon (Adoption du code)

Ce qui importe le plus : La Vérification.
L'analogie : Maintenant, l'IA a écrit une recette. Le développeur doit décider : « Puis-je faire confiance à ceci ? » Si le développeur a inclus un moyen de vérifier le résultat (comme « Cela doit passer ce test spécifique »), il était beaucoup plus susceptible de dire : « Oui, utilise ceci ! »
Le constat : Même si le code était bien écrit, si le développeur ne fournissait pas de moyen de vérifier qu'il était correct, il le rejetait souvent. Le « test de goût » était la clé pour que le code soit accepté.
Ce qui importait moins : À cette étape, avoir un objectif ultra-spécifique ou des informations de contexte supplémentaires n'était plus le facteur décisif ; la capacité à prouver que cela fonctionnait l'était.

Étape 3 : Mélanger dans le plat final (Profondeur d'intégration)

Ce qui importe le plus : Le Contexte à nouveau.
L'analogie : Le code est accepté, mais il doit maintenant être mélangé dans la grande marmite du logiciel existant. Si le code de l'IA a été écrit sans connaître le « profil de saveur » du reste du plat, il pourrait avoir un goût étrange et nécessiter une réécriture importante.
Le constat : Plus le développeur donnait d'informations de fond (Contexte), plus le code de l'IA s'intégrait parfaitement au projet existant. Si l'IA devait deviner comment elle s'insérait, les développeurs devaient passer beaucoup de temps à le corriger plus tard.
La leçon : Pour obtenir un code qui s'intègre de manière fluide, vous devez dire à l'IA exactement où il se situe dans le tableau d'ensemble.

3. Le vérificateur « Robot vs Humain »

Les chercheurs ont également essayé de voir s'ils pouvaient utiliser une IA pour noter automatiquement ces demandes.

Le résultat : C'était mitigé. L'IA était correcte pour repérer la « Spécificité » (instructions claires), mais mauvaise pour repérer le « Contexte » (elle passait souvent à côté des informations de fond) et la « Vérification » (elle avait du mal à voir si un test était inclus).
La conclusion : On ne peut pas simplement laisser un robot noter toutes ces demandes. Il faut un humain pour revérifier les parties délicates, en particulier le contexte de fond.

4. Le résultat final (La PR a-t-elle été fusionnée ?)

Il est intéressant de noter que la qualité du prompt n'a pas vraiment changé la vitesse à laquelle les gestionnaires de projet décidaient de fusionner ou de fermer la demande. Cela semblait dépendre davantage de la taille de la demande et des règles générales du projet, et non du prompt lui-même.

Résumé

Considérez le travail avec l'IA dans le développement logiciel comme une course de relais :

Départ : Vous avez besoin de Contexte et de Spécificité pour mettre le témoin (le code) en mouvement.
Milieu : Vous avez besoin de Vérification pour prouver que le coureur est sur la bonne voie afin que la personne suivante puisse prendre le témoin.
Arrivée : Vous avez besoin de Contexte à nouveau pour vous assurer que le coureur franchit la ligne d'arrivée dans la bonne voie sans percuter les autres coureurs.

L'article conclut que rédiger un bon prompt ne consiste pas seulement à obtenir du code ; il s'agit de préparer tout le flux de travail pour le succès. Si vous sautez les étapes de « Contexte » ou de « Vérification », le code sera peut-être écrit, mais il pourrait être rejeté ou nécessiter beaucoup de travail supplémentaire pour être corrigé plus tard.

Résumé technique : Qualité des prompts et issues des pull requests : une étude empirique par étapes du développement assisté par LLM

Énoncé du problème
Bien que les outils alimentés par les grands modèles de langage (LLM) soient de plus en plus intégrés dans les flux de travail de génie logiciel collaboratif, particulièrement au sein des processus de pull request (PR) en open-source, l'influence spécifique de la structure du prompt sur les résultats d'intégration en aval reste insuffisamment comprise. Les recherches antérieures se sont largement concentrées sur l'utilité conversationnelle, les mesures d'adoption globale ou la qualité du code à un niveau macroscopique. Cependant, les développeurs affinent, adaptent ou rejettent fréquemment le code généré par le LLM en fonction de la manière dont la requête initiale a été formulée. Il existe un manque de preuves empiriques concernant la manière dont les différentes dimensions de la qualité d'un prompt — spécifiquement sa capacité à ancrer les tâches dans un contexte, à définir une spécificité et à fournir des indices de vérification — impactent la progression du code, de la génération à l'adoption et à l'intégration profonde. De plus, la fiabilité de l'utilisation des LLM eux-mêmes pour annoter ces structures de prompts à grande échelle, une étape nécessaire pour les études empiriques de grande envergure, demeure une question méthodologique ouverte.

Méthodologie
L'étude emploie une approche par méthodes mixtes analysant 265 interactions développeur–ChatGPT validées manuellement, liées à des pull requests open-source. Ces cas ont été extraits du corpus PatchTrack, qui suit l'usage auto-déclaré de ChatGPT (SACU) dans les dépôts open-source.

Opérationnalisation de la structure du prompt : Les auteurs définissent la qualité du prompt à travers trois dimensions fondées sur la recherche préalable en génie logiciel sur les rapports de bugs et l'évaluation des PR :
- Contexte (C) : La mesure dans laquelle le prompt est ancré dans des artefacts techniques concrets (ex. : extraits de code, journaux, messages d'erreur).
- Spécificité (S) : La clarté et la précision de la tâche visée, incluant les objectifs, le périmètre et les contraintes.
- Vérification (V) : La présence de signaux permettant aux développeurs d'évaluer la correction (ex. : tests, comportements attendus, exemples entrée-sortie).
- Chaque dimension est évaluée sur une échelle ordinale de 0 à 2.
Stratégie d'annotation (RQ1) : Pour répondre à la question de la scalabilité de l'annotation manuelle, l'étude évalue d'abord la fiabilité de l'annotation assistée par LLM par rapport à un étalon de référence humain. Un sous-ensemble stratifié de prompts a été annoté par des chercheurs humains et un LLM (ChatGPT 5.1/5.2). L'accord a été mesuré via le Kappa de Cohen pondéré ( $\kappa_w$ ), l'erreur absolue moyenne (MAE) et le biais directionnel. Cette analyse a permis de définir une politique d'annotation hybride sensible à la classe, où l'annotation par LLM n'est appliquée sélectivement qu'aux dimensions et contextes de flux de travail présentant un accord suffisant, tandis que la supervision humaine est conservée pour les dimensions instables.
Modélisation du flux de travail par étapes (RQ2) : Le processus de développement est modélisé comme une séquence de barrières (gates) :
- Barrière 0 (Génération de code) : Le prompt produit-il un code actionnable ? (NE vs. PA/PN)
- Barrière 1 (Adoption du code) : Le code généré est-il incorporé dans la PR ? (PA vs. PN)
- Barrière 2 (Profondeur d'intégration) : Quelle fraction du code généré est conservée dans l'implémentation finale ? (Variable continue pour les cas PA)
- Axe B (Résultats du cycle de vie) : Fusion (merge) vs fermeture et délai de résolution.
- Des modèles statistiques (régression logistique, logit fractionnaire et modèle à risques proportionnels de Cox) ont été utilisés pour estimer les effets du Contexte, de la Spécificité et de la Vérification sur ces étapes, en contrôlant la taille de la PR.

Résultats clés
L'étude révèle que les caractéristiques des prompts exercent des effets distincts et dépendants des étapes à travers le flux de travail collaboratif :

Fiabilité de l'annotation : L'annotation basée sur le LLM montre un accord modéré avec les jugements humains pour le Contexte et la Spécificité, mais présente un biais de sous-évaluation systématique pour le Contexte et une faible fiabilité pour la Vérification, particulièrement lorsque les indices de correction sont implicites. La concordance de la Vérification varie considérablement selon la classe de résultat (ex. : accord élevé dans les cas de "Patch non appliqué", faible dans les cas de "Patch appliqué"). Cela nécessite une stratégie d'annotation hybride humain-LLM plutôt qu'une automatisation uniforme.
Barrière 0 (Génération de code) : La Spécificité et le Contexte sont les prédicteurs les plus forts d'une génération de code actionnable. Les prompts possédant des objectifs clairs et un ancrage technique sont nettement plus susceptibles de produire du code exécutable. La Vérification n'influence pas significativement la génération du code.
Barrière 1 (Adoption du code) : La Vérification émerge comme le principal prédicteur de l'adoption du code. Les prompts contenant des attentes explicites de correction ou des critères de validation sont significativement plus susceptibles de résulter en des correctifs adoptés. La Spécificité et le Contexte perdent leur pouvoir prédictif une fois le code généré.
Barrière 2 (Profondeur d'intégration) : Le Contexte devient le facteur dominant pour une intégration plus profonde. Les prompts qui inscrivent les tâches dans un contexte d'implémentation riche (code environnant, API, logique du dépôt) conduisent à des fractions plus élevées de code conservé. La Spécificité et la Vérification n'influencent pas significativement l'étendue de la réutilisation une fois le code accepté.
Résultats du cycle de vie : La structure du prompt n'influence pas significativement le taux de fusion des PR. Cependant, une Vérification plus élevée est associée à une fermeture plus rapide sans fusion, suggérant que les contraintes de correction explicites peuvent aider les mainteneurs à identifier rapidement les décalages.

Signification et affirmations
L'article affirme que la construction de prompts fonctionne comme un facteur amont critique dans le génie logiciel assisté par l'IA, influençant non seulement la génération initiale de code, mais aussi les résultats d'adoption et d'intégration en aval. Les conclusions suggèrent qu'une collaboration efficace dépend de l'alignement des caractéristiques du prompt avec l'étape spécifique du flux de travail :

Définition de la tâche : Le Contexte et la Spécificité sont essentiels pour générer du code actionnable.
Évaluation : Les indices de Vérification sont cruciaux pour gagner la confiance du développeur et l'adoption.
Alignement : L'ancrage contextuel est vital pour une intégration profonde et pour minimiser l'adaptation en aval.

Sur le plan méthodologique, l'étude démontre que l'opérationnalisation fiable de la structure des prompts nécessite des stratégies d'annotation hybrides adaptatives et sensibles au contexte. Elle soutient que la structure du prompt doit être traitée comme un "artefact logiciel de premier rang" qui façonne l'ensemble du cycle de vie du développement assisté par l'IA, et non simplement comme un intrant pour la génération de code. Les résultats indiquent que les défis d'intégration en aval trouvent souvent leur origine en amont, lors de la construction du prompt, soulignant la nécessité pour les développeurs de traiter la conception de prompts comme une partie intégrante du processus de développement logiciel.