Why Are AI Agent Involved Pull Requests (Fix-Related) Remain Unmerged? An Empirical Study
Diese empirische Studie analysiert über 8.000 fix-bezogene Pull Requests von fünf KI-Coding-Agenten, um zu identifizieren, dass Testfallfehlerschläge und doppelte Problemlösungen die primären Barrieren für das Mergen sind, während Build-Fehler selten sind, wodurch wesentliche Einschränkungen aktueller KI-Agenten sowie Richtungen zur Verbesserung der Mensch-KI-Kollaboration in der Softwarewartung hervorgehoben werden.
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 ein Softwareprojekt wie eine riesige, geschäftige Baustelle vor. Die „Maintainer“ (Wartungsteams) sind die Bauleiter, die entscheiden, welche Blaupausen gebaut und welche in den Müll geworfen werden. Vor kurzem haben sie angefangen, KI-Agenten (wie Roboter-Assistenten) einzustellen, die Reparaturpläne (genannt „Pull Requests“ oder PRs) entwerfen, um kaputte Teile des Gebäudes zu reparieren.
Dieses Paper ist wie ein Detektivbericht, der fragt: „Wie oft werden die Reparaturpläne dieser Roboter-Assistenten tatsächlich genehmigt, und wenn nicht, warum?“
Hier ist die Aufschlüsselung der Ergebnisse, unter Verwendung einfacher Analogien:
1. Das große Ganze: Die Erfolgsquote
Die Forscher untersuchten über 8.000 Reparaturpläne, die von fünf verschiedenen Typen von KI-Robotern (OpenAI Codex, GitHub Copilot, Devin, Cursor und Claude Code) eingereicht wurden.
- Die gute Nachricht: In etwa 65 % der Fälle sagten die Bauleiter: „Ja, bau das!“ und haben die Reparatur übernommen (gemergt). Die Roboter machen einen ordentlichen Job.
- Die schlechte Nachricht: In etwa 26 % der Fälle sagten die Manager: „Nein,“ und schlossen den Plan, ohne ihn auszuführen. Weitere 9 % warten noch im Wartezimmer auf eine Entscheidung.
- Die Unterschiede zwischen den Robotern: Nicht alle Roboter sind gleich gut.
- OpenAI Codex ist der Musterschüler: Er wurde in 81 % der Fälle genehmigt.
- Devin hatte am meisten Mühe: Er wurde nur in 43 % der Fälle genehmigt, was bedeutet, dass mehr als die Hälfte seiner Reparaturpläne abgelehnt wurde.
2. Das „Warum“: Warum werden Pläne abgelehnt?
Die Forscher sind tief eingetaucht in die 326 abgelehnten Pläne, um genau herauszufinden, warum diese scheiterten. Sie fanden 12 verschiedene Gründe, die sie in drei Hauptkategorien gruppierten:
A. Die „Falsche Lösung“-Probleme (Technische Probleme)
Manchmal versucht der Roboter, ein Leck zu flicken, bricht dabei aber eigentlich das Rohr.
- Test-Fehlversuche (Der häufigste technische Grund): Die Reparatur des Roboters bestand zwar nach der eigenen Logik des Roboters, scheiterte aber an den strengen Sicherheitstests des Projekts. Es ist, als würde ein Koch ein Gericht zubereiten, das toll aussieht, aber schmeckt schrecklich, wenn der Gesundheitsprüfer (die Test-Suite) es probiert.
- Unvollständige oder falsche Reparaturen: Der Roboter hat das Problem zwar erraten, aber das falsche gelöst, oder er hat nur die Hälfte davon behoben.
- Build-/Deployment-Fehler: Selten war die Reparatur so fehlerhaft, dass das Gebäude gar nicht erst zusammengesetzt werden konnte (es ließ sich nicht kompilieren oder ausführen).
B. Die „Schlechtes Timing“-Probleme (Prozess-Probleme)
Manchmal ist die Reparatur eigentlich gut, aber der Zeitpunkt ist falsch.
- Jemand anderes war zuerst fertig (Der Hauptgrund für Ablehnungen): Dies geschah in 22 % der Fälle. Der Roboter arbeitete hart daran, ein kaputtes Fenster zu reparieren, aber ein Mensch (oder ein anderer Roboter) hatte es bereits fünf Minuten zuvor repariert. Der Plan des Roboters wurde einfach abgelehnt, weil er redundant war.
- Inaktivität: Der Roboter reichte einen Plan ein, blieb dann aber stumm. Die Manager wurden ungeduldig beim Warten auf eine Antwort und schlossen das Ticket.
- Niedrige Priorität: Das Problem, das der Roboter zu beheben versuchte, war nicht mehr wichtig oder die Projektmanager entschieden sich, es zu ignorieren.
C. Die „Kommunikationsbruch“-Probleme
- Keine Überprüfung: Der Roboter bat um eine Überprüfung, aber kein menschlicher Manager hat sich den Plan jemals angesehen.
- Stille Ablehnung: Der Plan wurde geschlossen, ohne eine Erklärung abzugeben, was den Roboter (und die Forscher) im Dunkeln ließ, warum er gescheitert ist.
3. Der „Geschwindigkeits“-Faktor
Die Forscher haben auch gemessen, wie lange es dauerte, bis ein Plan genehmigt wurde.
- Schnelle Merges: Viele gute Reparaturen wurden sehr schnell genehmigt.
- Langsame Merges: Einige dauerten lange. Interessanterweise hatte der „Musterschüler“ (OpenAI Codex) die konsistentesten und schnellsten Genehmigungszeiten, während andere viel unvorhersehbarere Wartezeiten hatten.
Das Fazit
Das Paper kommt zu dem Schluss, dass die Roboter zwar immer besser darin werden, Code zu schreiben, Code zu schreiben allein jedoch nicht ausreicht.
Um einen Reparaturplan in der realen Welt genehmigt zu bekommen, muss der Roboter:
- Die strengen Sicherheitstests bestehen (und nicht nur gut aussehen).
- Keine Doppelarbeit leisten, die Menschen oder andere Roboter bereits erledigt haben.
- Aktiv am Gespräch mit den menschlichen Managern teilnehmen.
Derzeit liegen die größten Hürden nicht darin, dass die Roboter nicht in der Lage sind, Code zu schreiben; es ist vielmehr, dass sie oft bei den Tests scheitern oder von anderen, die dasselbe Problem lösen, überholt werden. Die Studie legt nahe, dass für KI, um wirklich ein zuverlässiger „virtueller Teamkollege“ zu werden, nicht nur den Code selbst, sondern auch den Kontext des Projekts und das Timing des Arbeitsablaufs besser verstehen muss.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.