💻 computer science

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

Deze studie analyseert empirisch 265 developer-ChatGPT interacties in open-source pull requests om aan te tonen dat specifieke promptkenmerken — Context, Specificiteit en Verificatie — onderscheidende, fase-afhankelijke effecten hebben op AI-ondersteunde softwareontwikkelingsresultaten, waarbij Specificiteit en Context de generatie van actiecode drijven, Verificatie codadoptie voorspelt, en Context de integratiediepte bepaalt.

Oorspronkelijke auteurs: Richard Sserunjogi, Daniel Ogenrwot, John Businge

Gepubliceerd 2026-06-19

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Richard Sserunjogi, Daniel Ogenrwot, John Businge

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een chef bent (de ontwikkelaar) die probeert een complex gerecht te bereiden, maar je hebt een zeer getalenteerde, maar soms letterlijke sous-chef (de AI). Je roept niet zomaar "Maak het avondeten!" en verwacht een Michelinster-maaltijd. Je moet specifieke instructies geven.

Dit artikel is een studie naar hoe de manier waarop je de sous-chef om hulp vraagt het hele kookproces beïnvloedt, van het eerste ingrediënt tot het uiteindelijke bord dat aan de klant wordt geserveerd.

De onderzoekers keken naar 265 real-world voorbeelden waarbij ontwikkelaars hun gesprekken met een AI (ChatGPT) deelden binnen softwareprojecten. Ze wilden zien of de kwaliteit van de "receptaanvraag" (de prompt) bepaalde of de code van de AI nuttig was, geaccepteerd werd en daadwerkelijk werd gebruikt in het eindproduct.

Hier is de uitsplitsing van hun bevindingen, met behulp van eenvoudige analogieën:

1. De drie ingrediënten van een goede aanvraag

De onderzoekers braken elke aanvraag af in drie delen, alsof ze een receptkaart controleerden:

Context (De omgeving): Legde de ontwikkelaar uit waar deze code in past? (bijv. "Dit is voor het inlogscherm van onze bank-app.")
Specificiteit (De details): Zei de ontwikkelaar precies wat hij wilde? (bijv. "Maak de knop blauw en rond," in plaats van "Maak het mooi.")
Verificatie (De smaaktest): Zei de ontwikkelaar hoe te controleren of het goed is? (bijv. "Als ik hierop klik, moet ik kunnen inloggen zonder een foutmelding.")

2. De drie stadia van de keukenworkflow

De studie toonde aan dat de "perfecte" aanvraag verandert afhankelijk van in welke fase van het kookproces je je bevindt. Het is niet één-op-één toepasbaar.

Fase 1: Het eerste concept krijgen (Code Generatie)

Wat het belangrijkst is: Context en Specificiteit.
De analogie: Als je wilt dat de AI daadwerkelijk een recept schrijft, moet je vertellen wat voor soort eten je maakt en duidelijke stappen geven.
De bevinding: Als de aanvraag vaag was of een gebrek aan achtergrondinformatie had, gaf de AI vaak alleen een generieke uitleg in plaats van daadwerkelijke code. Maar als de ontwikkelaar een duidelijk doel en wat achtergrondinformatie gaf, produceerde de AI bijna altijd bruikbare code.
Wat nog niet belangrijk was: Of de aanvraag een "smaaktest" (Verificatie) bevatte, hield de AI er niet van om de code te schrijven.

Fase 2: Beslissen om het concept te gebruiken (Code Adoptie)

Wat het belangrijkst is: Verificatie.
De analogie: Nu heeft de AI een recept geschreven. De ontwikkelaar moet beslissen: "Kan ik dit vertrouwen?" Als de ontwikkelaar een manier opnam om het resultaat te controleren (zoals "Het moet aan deze specifieke test voldoen"), was de ontwikkelaar veel eerder geneigd om te zeggen: "Ja, gebruik dit!"
De bevinding: Zelfs als de code goed geschreven was, maar de ontwikkelaar geen manier bood om te verifiëren of het correct was, werd de code vaak afgewezen. De "smaaktest" was de sleutel tot het accepteren van de code.
Wat minder belangrijk was: In deze fase was het hebben van een super-specifiek doel of extra achtergrondinformatie niet langer de doorslaggevende factor; het vermogen om te bewijzen dat het werkte, was dat wel.

Fase 3: Het mengen in het definitieve gerecht (Integratiediepte)

Wat het belangrijkst is: Context opnieuw.
De analogie: De code is geaccepteerd, maar nu moet deze worden gemengd in de grote pan van de bestaande software. Als de code van de AI werd geschreven zonder te weten wat het "smaakprofiel" van de rest van het gerecht was, zou het misschien vreemd smaken en moet het zwaar worden herschreven.
De bevinding: Hoe meer achtergrondinformatie (Context) de ontwikkelaar de AI gaf, hoe beter de code van de AI in het bestaande project paste. Als de AI moest gokken hoe het paste, moesten de ontwikkelaars later veel tijd besteden aan het repareren ervan.
De les: Om code te krijgen die naadloos past, moet je de AI vertellen waar het precies thuishoort in het grotere geheel.

3. De "Robot vs. Mens" checker

De onderzoekers probeerden ook te kijken of ze een AI automatisch konden laten beoordelen op deze aanvragen.

Het resultaat: Het was een gemengd beeld. De AI was oké in het herkennen van "Specificiteit" (duidelijke instructies), maar slecht in het herkennen van "Context" (het miste vaak de achtergrondinformatie) en "Verificatie" (het had moeite om te zien of een test was opgenomen).
De les: Je kunt niet zomaar een robot alle aanvragen laten beoordelen. Je hebt een mens nodig om de lastige onderdelen te controleren, vooral de achtergrondcontext.

4. De uiteindelijke uitkomst (Werd de PR gemerged?)

Interessant genoeg veranderde de kwaliteit van de prompt niet echt hoe snel de projectmanagers besloten de aanvraag te mergen of te sluiten. Dat leek meer af te hangen van hoe groot de aanvraag was en de algemene regels van het project, en niet alleen van de prompt zelf.

Samenvatting

Beschouw het werken met AI in softwareontwikkeling als een estafette:

Start: Je hebt Context en Specificiteit nodig om de estafettestok (code) in beweging te krijgen.
Midden: Je hebt Verificatie nodig om te bewijzen dat de loper op de juiste weg zit, zodat de volgende persoon de stok kan overnemen.
Finish: Je hebt Context opnieuw nodig om ervoor te zorgen dat de loper de finishlijn passeert in de juiste baan zonder tegen de andere lopers op te botsen.

Het artikel concludeert dat het schrijven van een goede prompt niet alleen gaat over het krijgen van code; het gaat over het instellen van de gehele workflow voor succes. Als je de stappen "Context" of "Verificatie" overslaat, kan de code weliswa worden geschreven, maar kan deze worden afgewezen of vereist het veel extra werk om het later te herstellen.

Technische Samenvatting: Promptkwaliteit en de Uitkomsten van Pull Requests: Een Stage-gebaseerde Empirische Studie naar LLM-ondersteunde Ontwikkeling

Probleemstelling
Hoewel door Large Language Models (LLM) aangedreven tools steeds vaker worden geïntegreerd in collaboratieve software engineering-workflows, met name binnen open-source pull request (PR) processen, blijft de specifieke invloed van de promptstructuur op downstream integratie-uitkomsten onvoldoende begrepen. Bestaand onderzoek heeft zich grotendeels gericht op conversationele behulpzaamheid, brede adoptiemetrieken of grove coderingskwaliteit. Ontwikkelaars verfijnen, passen echter regelmatig code aan die door een LLM is gegenereerd, of wijzen deze af op basis van hoe de initiële aanvraag werd geformuleerd. Er is een gebrek aan empirisch bewijs over hoe verschillende dimensies van promptkwaliteit—specifiek het vermogen om taken te funderen in context, specificiteit te definiëren en verificatiekenmerken te bieden—de progressie van codegeneratie naar adoptie en diepe integratie beïnvloeden. Bovien blijft de betrouwbaarheid van het gebruik van LLM's zelf om deze promptstructuren op schaal te annoteren, een noodzakelijke stap voor grootschalige empirische studies, een open methodologische vraag.

Methodologie
De studie maakt gebruik van een mixed-methods benadering waarbij 265 handmatig gevalideerde developer–ChatGPT interacties worden geanalyseerd die gekoppeld zijn aan open-source pull requests. Deze gevallen zijn afkomstig uit de PatchTrack corpus, die zelf-geadmitteerd ChatGPT-gebruik (SACU) in open-source repositories bijhoudt.

Operationalisering van Promptstructuur: De auteurs definiëren promptkwaliteit aan de hand van drie dimensies, geworteld in eerder onderzoek naar bugrapporten en PR-evaluatie:
- Context (C): De mate waarin de prompt is gefundeerd in concrete technische artefacten (bijv. codefragmenten, logs, foutmeldingen).
- Specificiteit (S): De helderheid en precisie van de beoogde taak, inclusief doelen, reikwijdte en beperkingen.
- Verificatie (V): De aanwezigheid van signalen waarmee ontwikkelaars de correctheid kunnen beoordelen (bijv. tests, verwacht gedrag, input-output voorbeelden).
- Elke dimensie wordt gescoord op een ordinale schaal van 0–2.
Annotatiestrategie (RQ1): Om de schaalbaarheid van handmatige annotatie aan te pakken, evalueert de studie eerst de betrouwbaarheid van LLM-gestuurde annotatie ten opzichte van een menselijke gouden standaard. Een gestratificeerde subset van prompts werd geannoteerd door menselijke onderzoekers en een LLM (ChatGPT 5.1/5.2). Overeenstemming werd gemeten met behulp van gewogen Cohen's Kappa ( $\kappa_w$ ), Mean Absolute Error (MAE) en directionele bias. Deze analyse vormde de basis voor een class-aware hybride annotatiebeleid, waarbij LLM-scoring selectief wordt toegepast op dimensies en workflow-contexten met voldoende overeenstemming, terwijl menselijk toezicht behouden blijft voor instabiele dimensies.
Stage-gebaseerde Workflowmodellering (RQ2): Het ontwikkelproces wordt gemodelleerd als een sequentie van poorten (gates):
- Gate 0 (Codegeneratie): Produceert de prompt uitvoorbare code? (NE vs. PA/PN)
- Gate 1 (Code-adoptie): Wordt de gegenereerde code opgenomen in de PR? (PA vs. PN)
- Gate 2 (Integratiediepte): Welk deel van de gegenereerde code wordt behouden in de uiteindelijke implementatie? (Continue variabele voor PA-gevallen)
- As B (Lifecycle-uitkomsten): Merge vs. sluiting en tijd tot resolutie.
- Statistische modellen (logistische regressie, fractionele logit en Cox proportional hazards) werden gebruikt om de effecten van Context, Specificiteit en Verificatie op deze stadia te schatten, waarbij voor de grootte van de PR werd gecontroleerd.

Belangrijkste Resultaten
De studie toont aan dat promptkenmerken onderscheidende, stage-afhankelijke effecten uitoefenen over de collaboratieve workflow:

Annotatiebetrouwbaarheid: LLM-gebaseerde annotatie vertoont een matige overeenstemming met menselijke oordelen voor Context en Specificiteit, maar vertoont een systematische onderbeoordelingsbias voor Context en een slechte betrouwbaarheid voor Verificatie, vooral wanneer correctheidscues impliciet zijn. Verificatie-overeenstemming varieert significant per uitkomstklasse (bijv. hoge overeenstemming in "Patch Not Applied" gevallen, lage overeenstemming in "Patch Applied" gevallen). Dit vereist een hybride mens-LLM annotatiestrategie in plaats van uniforme automatisering.
Gate 0 (Codegeneratie): Specificiteit en Context zijn de sterkste voorspellers van uitvoerbare codegeneratie. Prompts met duidelijke doelen en technische fundering zijn aanzienlijk eerder geneigd om uitvoerbare code op te leveren. Verificatie heeft geen significante invloed op het wel of niet genereren van code.
Gate 1 (Code-adoptie): Verificatie verschijnt als de primaire voorspeller van code-adoptie. Prompts die expliciete correctheidsverwachtingen of validatiecriteria bevatten, leiden aanzienlijk vaker tot geadopteerde patches. Specificiteit en Context verliezen hun voorspellende kracht zodra de code is gegenereerd.
Gate 2 (Integratiediepte): Context wordt de dominante factor voor diepere integratie. Prompts die taken inbedden in een rijke implementatiecontext (omringende code, API's, repository-logica) leiden tot een hoger deel van behouden code. Specificiteit en Verificatie beïnvloeden de mate van hergebruik zodra de code is geaccepteerd niet significant.
Lifecycle-uitkomsten: De promptstructuur heeft geen significante invloed op de snelheid waarmee PR's worden gemerged. Echter, hogere Verificatie is geassocieerd met snellere sluiting zonder merge, wat suggereert dat expliciete correctheidsbeperkingen maintainers kunnen helpen om mismatches snel te identificeren.

Betekenis en Claims
Het artikel claimt dat promptconstructie fungeert als een cruciale upstream factor in AI-ondersteunde software engineering, die niet alleen de initiële generatie van code beïnvloedt, maar ook downstream adoptie- en integratie-uitkomsten. De bevindingen suggereren dat effectieve samenwerking afhangt van het afstemmen van promptkenmerken op de specifieke fase van de workflow:

Taakdefinitie: Context en Specificiteit zijn essentieel voor het genereren van uitvoerbare code.
Evaluatie: Verificatiekenmerken zijn cruciaal voor het winnen van vertrouwen en adoptie door de developer.
Afstemming: Contextuele fundering is essentieel voor diepe integratie en het minimaliseren van downstream aanpassingen.

Methodologisch gezien toont de studie aan dat een betrouwbare operationalisering van promptstructuur een adaptieve, contextbewuste hybride annotatiestrategie vereist. Het stelt dat promptstructuur moet worden behandeld als een "first-class software artefact" die de gehele levenscyclus van AI-ondersteunde ontwikkeling vormgeeft, in plaats van louter een input voor codegeneratie. De resultaten geven aan dat problemen met downstream integratie vaak upstream ontstaan tijdens de promptconstructie, wat benadrukt dat ontwikkelaars promptontwerp moeten behandelen als een integraal onderdeel van het softwareontwikkelingsproces.