💻 computer science

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

Diese Studie analysiert empirisch 265 Entwickler-ChatGPT-Interaktionen in Open-Source-Pull-Requests, um zu demonstrieren, dass spezifische Prompt-Charakteristika – Kontext, Spezifität und Verifizierung – distinkte, phasenabhängige Effekte auf KI-gestützte Softwareentwicklungsergebnisse ausüben, wobei Spezifität und Kontext die Erzeugung von ausführbarem Code vorantreiben, Verifizierung die Code-Übernahme vorhersagt und Kontext die Integrationstiefe bestimmt.

Ursprüngliche Autoren: Richard Sserunjogi, Daniel Ogenrwot, John Businge

Veröffentlicht 2026-06-19

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Richard Sserunjogi, Daniel Ogenrwot, John Businge

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Chefkoch (der Entwickler), der versucht, ein komplexes Gericht zuzubereiten, aber Sie haben einen sehr talentierten, wenn auch manchmal etwas wortwörtlich nehmenden Sous-Chef (die KI). Sie können nicht einfach „Mach das Abendessen!“ rufen und ein Michelin-Sterne-Menü erwarten. Sie müssen spezifische Anweisungen geben.

Dieses Paper ist eine Studie darüber, wie die Art und Weise, wie Sie den Sous-Chef um Hilfe bitten, den gesamten Kochprozess beeinflusst – vom ersten Bestandteil bis zum fertigen Teller, der dem Kunden serviert wird.

Die Forscher untersuchten 265 reale Beispiele, in denen Entwickler ihre Gespräche mit einer KI (ChatGPT) innerhalb von Softwareprojekten geteilt haben. Sie wollten sehen, ob die Qualität der „Rezeptanfrage“ (des Prompts) davon abhing, ob der Code der KI nützlich war, akzeptiert wurde und tatsächlich im Endprodukt verwendet wurde.

Hier ist die Aufschlüsselung ihrer Ergebnisse, unter Verwendung einfacher Analogien:

1. Die drei Zutaten einer guten Anfrage

Die Forscher haben jede Anfrage in drei Teile zerlegt, als würde man eine Rezeptkarte prüfen:

Kontext (Das Setting): Hat der Entwickler erklärt, wo dieser Code hingehört? (z. B. „Dies ist für den Login-Bildschirm unserer Banking-App.“)
Spezifität (Die Details): Hat der Entwickler genau gesagt, was er wollte? (z. B. „Mach den Button blau und rund“, nicht nur „Mach ihn hübsch.“)
Verifizierung (Der Geschmackstest): Hat der Entwickler gesagt, wie zu prüfen ist, ob es richtig ist? (z. B. „Wenn ich hier klicke, sollte ich mich ohne Fehlermeldung einloggen können.“)

2. Die drei Phasen des Küchen-Workflows

Die Studie ergab, dass sich die „perfekte“ Anfrage ändert, je nachdem, in welcher Phase des Kochprozesses man sich befindet. Es ist nicht eins nach dem anderen.

Phase 1: Den ersten Entwurf erhalten (Code-Generierung)

Was am wichtigsten ist: Kontext und Spezifität.
Die Analogie: Wenn Sie möchten, dass die KI tatsächlich ein Rezept schreibt, müssen Sie ihr sagen, welche Art von Essen Sie zubereiten und ihr klare Schritte vorgeben.
Das Ergebnis: Wenn die Anfrage vage war oder es an Hintergrundinformationen mangelte, lieferte die KI oft nur eine generische Erklärung anstatt tatsächlichen Code. Aber wenn der Entwickler ein klares Ziel und etwas Hintergrund lieferte, produzierte die KI fast immer nutzbaren Code.
Was noch nicht wichtig war: Ob die Anfrage einen „Geschmackstest“ (Verifizierung) enthielt, verhinderte nicht, dass die KI den Code schrieb.

Phase 2: Den Entwurf verwenden (Code-Adoption)

Was am wichtigsten ist: Verifizierung.
Die Analogie: Jetzt hat die KI ein Rezept geschrieben. Der Entwickler muss entscheiden: „Kann ich dem vertrauen?“ Wenn der Entwickler einen Weg angegeben hat, das Ergebnis zu prüfen (wie „Es muss diesen spezifischen Test bestehen“), war der Entwickler viel eher bereit zu sagen: „Ja, verwende das!“
Das Ergebnis: Selbst wenn der Code gut geschrieben war, wenn der Entwickler keinen Weg angab, um zu verifizieren, ob er korrekt war, lehnte er ihn oft ab. Der „Geschmackstest“ war der Schlüssel dazu, dass der Code akzeptiert wurde.
Was nicht so wichtig war: Zu diesem Zeitpunkt war es kein entscheidender Faktor mehr, ob die Anfrage ein super-spezifisches Ziel oder zusätzliche Hintergrundinfos hatte; die Fähigkeit, den Erfolg zu beweisen, war entscheidend.

Phase 3: In das fertige Gericht mischen (Integrationstiefe)

Was am wichtigsten ist: Wieder der Kontext.
Die Analogie: Der Code ist akzeptiert, aber nun muss er in den großen Topf der bestehenden Software gemischt werden. Wenn der Code der KI ohne Wissen über das „Geschmacksprofil“ des restlichen Gerichts geschrieben wurde, könnte er seltsam schmecken und müsste stark umgeschrieben werden.
Das Ergebnis: Je mehr Hintergrundinformationen (Kontext) der Entwickler der KI gab, desto besser passte der Code der KI in das bestehende Projekt. Wenn die KI raten musste, wie sie hineinpasst, mussten die Entwickler später viel Zeit mit Korrekturen verbringen.
Die Lektion: Um Code zu erhalten, der nahtlos passt, müssen Sie der KI genau sagen, wo er im größeren Gesamtbild hingehört.

3. Der „Roboter vs. Mensch“-Prüfer

Die Forscher versuchten auch zu sehen, ob sie eine KI nutzen könnten, um diese Anfragen automatisch zu bewerten.

Das Ergebnis: Es war ein gemischtes Bild. Die KI war ganz gut darin, „Spezifität“ (klare Anweisungen) zu erkennen, aber schlecht darin, „Kontext“ (sie übersah oft die Hintergrundinformationen) und „Verifizierung“ (sie hatte Schwierigkeiten zu erkennen, ob ein Test enthalten war) zu identifizieren.
Die Erkenntnis: Man kann nicht einfach einen Roboter die Bewertung all dieser Anfragen überlassen. Man braucht einen Menschen, der die schwierigen Teile, insbesondere den Hintergrundkontext, überprüft.

4. Das Endergebnis (Wurde der PR gemerged?)

Interessanterweise änderte die Qualität des Prompts die Geschwindigkeit, mit der die Projektmanager die Anfrage zusammenführten (merged) oder schlossen, kaum. Das schien eher davon abzuhängen, wie groß die Anfrage war und von den allgemeinen Regeln des Projekts, nicht nur vom Prompt selbst.

Zusammenfassung

Betrachten Sie die Arbeit mit KI in der Softwareentwicklung wie einen Staffellauf:

Start: Sie benötigen Kontext und Spezifität, um den Staffelstab (den Code) in Bewegung zu setzen.
Mitte: Sie benötigen Verifizierung, um zu beweisen, dass der Läufer auf dem richtigen Weg ist, damit die nächste Person den Stab übernehmen kann.
Ziel: Sie benötigen erneut Kontext, um sicherzustellen, dass der Läufer die Ziellinie in der richtigen Bahn überquert, ohne mit den anderen Läufern zu kollidieren.

Das Paper kommt zu dem Schluss, dass das Schreiben eines guten Prompts nicht nur dazu dient, Code zu erhalten; es geht darum, den gesamten Workflow auf Erfolg auszurichten. Wenn Sie die Schritte „Kontext“ oder „Verifizierung“ überspringen, wird der Code zwar vielleicht geschrieben, aber er könnte abgelehnt werden oder viel zusätzliche Arbeit bei der Korrektur erfordern.

Technische Zusammenfassung: Prompt-Qualität und Pull-Request-Ergebnisse: Eine stufenbasierte empirische Studie zur LLM-gestützten Entwicklung

Problemstellung
Obwohl durch Large Language Models (LLM) gestützte Werkzeuge zunehmend in kollaborative Software-Engineering-Workflows integriert werden, insbesondere innerhalb von Open-Source-Pull-Request-Prozessen (PR), bleibt der spezifische Einfluss der Prompt-Struktur auf nachgelagerte Integrationsergebnisse unzureichend verstanden. Die bisherige Forschung hat sich weitgehend auf die konversationelle Hilfsbereitschaft, breite Adoptionsmetriken oder grobkörnige Code-Qualität konzentriert. Entwickler verfeinern, adaptieren oder lehnen jedoch häufig den LLM-generierten Code basierend darauf ab, wie die ursprüngliche Anfrage formuliert wurde. Es mangelt an empirischen Belegen darüber, wie unterschiedliche Dimensionen der Prompt-Qualität – insbesondere deren Fähigkeit, Aufgaben in einen Kontext einzubetten, Spezifität zu definieren und Verifikationshinweise bereitzustellen – den Fortschritt von der Generierung bis zur Adoption und tiefen Integration von Code beeinflussen. Zudem bleibt die Zuverlässigkeit der Verwendung von LLMs selbst zur Annotation dieser Prompt-Strukturen im großen Maßstab, ein notwendiger Schritt für groß angelegte empirische Studien, eine offene methodische Frage.

Methodik
Die Studie verwendet einen Mixed-Methods-Ansatz zur Analyse von 265 manuell validierten Entwickler–ChatGPT-Interaktionen, die mit Open-Source-Pull-Requests verknüpft sind. Diese Fälle wurden aus dem PatchTrack-Korpus abgeleitet, der selbstberichtete ChatGPT-Nutzung (SACU) in Open-Source-Repositories verfolgt.

Operationalisierung der Prompt-Struktur: Die Autoren definieren die Prompt-Qualität anhand von drei Dimensionen, die auf vorangegangener Software-Engineering-Forschung zu Bug-Reports und PR-Evaluierungen basieren:
- Kontext (C): Das Ausmaß, in dem der Prompt in konkreten technischen Artefakten (z. B. Code-Snippets, Logs, Fehlermeldungen) fundiert ist.
- Spezifität (S): Die Klarheit und Präzision der beabsichtigten Aufgabe, einschließlich Zielen, Umfang und Einschränkungen.
- Verifikation (V): Das Vorhandensein von Signalen, die es Entwicklern ermöglichen, die Korrektheit zu bewerten (z. B. Tests, erwartetes Verhalten, Input-Output-Beispiele).
- Jede Dimension wird auf einer ordinalen Skala von 0–2 bewertet.
Annotationsstrategie (RQ1): Um die Skalierbarkeit der manuellen Annotation zu adressieren, evaluiert die Studie zunächst die Zuverlässigkeit der LLM-gestützten Annotation gegenüber einem menschlichen Goldstandard. Eine stratifizierte Teilmenge von Prompts wurde von menschlichen Forschern und einem LLM (ChatGPT 5.1/5.2) annotiert. Die Übereinstimmung wurde mittels gewichteter Cohen's Kappa ( $\kappa_w$ ), mittlerer absoluter Abweichung (MAE) und Richtungsbias gemessen. Diese Analyse informierte eine klassenbewusste hybride Annotationspolitik, bei der die LLM-Bewertung selektiv nur auf Dimensionen und Workflow-Kontexte angewendet wird, die eine ausreichende Übereinstimmung aufweisen, während die menschliche Aufsicht für instabile Dimensionen beibehalten wird.
Stufenbasiertes Workflow-Modellierung (RQ2): Der Entwicklungsprozess wird als Sequenz von Gates modelliert:
- Gate 0 (Code-Generierung): Erzeugt der Prompt ausführbaren Code? (NE vs. PA/PN)
- Gate 1 (Code-Adoption): Wird der generierte Code in den PR aufgenommen? (PA vs. PN)
- Gate 2 (Integrationstiefe): Welcher Anteil des generierten Codes wird in der endgültigen Implementierung beibehalten? (Kontinuierliche Variable für PA-Fälle)
- Achse B (Lifecycle-Ergebnisse): Merge vs. Schließung (Closure) und Zeit bis zur Lösung.
- Statistische Modelle (logistische Regression, fraktionale Logit-Regression und Cox-Proportional-Hazards-Modelle) wurden verwendet, um die Effekte von Kontext, Spezifität und Verifikation auf diese Stufen zu schätzen, wobei die PR-Größe kontrolliert wurde.

Kernergebnisse
Die Studie zeigt, dass Prompt-Charakteristika distinkte, stufenabhängige Effekte über den kollaborativen Workflow hinweg ausüben:

Annotationszuverlässigkeit: Die LLM-basierte Annotation zeigt eine moderate Übereinstimmung mit menschlichen Urteilen für Kontext und Spezität, weist jedoch einen systematischen Under-Scoring-Bias für den Kontext und eine schlechte Zuverlässigkeit für die Verifikation auf, insbesondere wenn Korrektheits-Hinweise implizit sind. Die Übereinstimmung bei der Verifikation variiert signifikant nach Ergebnisklasse (z. B. hohe Übereinstimmung in „Patch Not Applied“-Fällen, niedrige in „Patch Applied“). Dies macht eine hybride Mensch-LLM-Annotationsstrategie statt einer einheitlichen Automatisierung erforderlich.
Gate 0 (Code-Generierung): Spezifität und Kontext sind die stärksten Prädiktoren für die Generierung von ausführbarem Code. Prompts mit klaren Zielen und technischer Fundierung führen wesentlich wahrscheinlicher zu ausführbarem Code. Verifikation hat keinen signifikanten Einfluss darauf, ob Code generiert wird.
Gate 1 (Code-Adoption): Verifikation erweist sich als der primäre Prädiktor für die Code-Adoption. Prompts, die explizite Korrektheitserwartungen oder Validierungskriterien enthalten, führen signifikant wahrscheinlicher zu adoptierten Patches. Spezifität und Kontext verlieren ihre prädiktive Kraft, sobald der Code generiert wurde.
Gate 2 (Integrationstiefe): Kontext wird zum dominanten Faktor für eine tiefere Integration. Prompts, die Aufgaben in einen reichhaltigen Implementierungskontext (umgebender Code, APIs, Repository-Logik) einbetten, führen zu einem höheren Anteil an beibehaltenem Code. Spezifität und Verifikation beeinflussen den Umfang der Wiederverwendung, sobald der Code akzeptiert wurde, nicht signifikant.
Lifecycle-Ergebnisse: Die Prompt-Struktur beeinflusst die Rate, mit der PRs gemerget werden, nicht signifikant. Jedoch ist eine höhere Verifikation mit einer schnelleren Schließung ohne Merge assoziiert, was darauf hindeutet, dass explizite Korrektheitsbeschränkungen Maintainern helfen können, Mismatch-Situationen schnell zu identifizieren.

Bedeutung und Ansprüche
Das Paper behauptet, dass die Prompt-Konstruktion als kritischer Upstream-Faktor im KI-gestützten Software-Engineering fungiert, der nicht nur die initiale Code-Generierung, sondern auch nachgelagerte Adoption- und Integrationsergebnisse beeinflusst. Die Ergebnisse legen nahe, dass effektive Kollaboration von der Abstimmung der Prompt-Charakteristika auf die jeweilige Stufe des Workflows abhängt:

Aufgabendefinition: Kontext und Spezifität sind essenziell, um ausführbaren Code zu generieren.
Evaluierung: Verifikationshinweise sind entscheidend, um das Vertrauen der Entwickler und die Adoption zu gewinnen.
Ausrichtung: Kontextuelle Fundierung ist wichtig für eine tiefe Integration und zur Minimierung nachgelagerter Adaptionen.

Methodisch demonstriert die Studie, dass eine zuverlässige Operationalisierung der Prompt-Struktur adaptive, kontextbewusste hybride Annotationsstrategien erfordert. Sie argumentiert, dass die Prompt-Struktur als ein „First-Class Software Artifact“ behandelt werden sollte, das den gesamten Lebenszyklus der KI-gestützten Entwicklung prägt, anstatt lediglich als Input für die Code-Generierung zu dienen. Die Ergebnisse deuten darauf hin, dass Herausforderungen bei der nachgelagerten Integration oft upstream während der Prompt-Konstruktion ihren Ursprung haben, was die Notwendigkeit unterstreicht, Entwickler dazu zu bewegen, das Prompt-Design als integralen Bestandteil des Softwareentwicklungsprozesses zu betrachten.