REAgent -- Requirement-Driven LLM Agents fuer automatische Issue Resolution
Shiqi Kuang et al. (u.a. Huawei) praesentieren REAgent, einen LLM-Agenten-Ansatz, der Software Requirements Engineering auf die automatische Patch-Generierung anwendet. Die zentrale Beobachtung: Issue-Beschreibungen in der Praxis sind haeufig unvollstaendig, mehrdeutig oder schlecht strukturiert -- und genau diese Unschaerfe pflanzt sich direkt in die Qualitaet der generierten Patches fort. REAgent konstruiert deshalb aus rohen Issue-Beschreibungen strukturierte, informationsreiche Requirements und nutzt diese als Grundlage fuer die Patch-Generierung. Der Ansatz erzielt durchschnittlich 17.4% mehr erfolgreich geloeste Issues gegenueber fuenf Baselines auf drei Benchmarks.
Kernaussagen
Bestehende Ansaetze zur automatischen Issue Resolution behandeln die Issue-Beschreibung als rohen Input und versuchen direkt, daraus Patches abzuleiten. Das funktioniert bei praezisen Bug Reports, versagt aber bei vagen Feature Requests, unvollstaendigen Fehlerbeschreibungen oder Issues ohne Reproduktionsschritte. REAgent fuehrt einen expliziten Requirements-Engineering-Schritt ein, der diese Luecke schliesst.
Strukturierte Requirements statt roher Issues. REAgent extrahiert aus Issue-Beschreibungen strukturierte Requirements, die funktionale Anforderungen, betroffene Komponenten, erwartetes Verhalten und Randbedingungen explizit benennen. Diese Requirements dienen als praezise Spezifikation fuer die nachgelagerte Patch-Generierung.
Iterative Verfeinerung. Nicht jede Issue-Beschreibung liefert auf Anhieb genug Information fuer ein vollstaendiges Requirement. REAgent erkennt unzureichende Requirements und verfeinert sie iterativ -- durch Analyse des Codebase-Kontexts, Ableitung impliziter Anforderungen und Aufloesung von Mehrdeutigkeiten.
Konsistente Verbesserung ueber Modelle und Benchmarks. Die Evaluation auf drei Benchmarks mit zwei verschiedenen LLMs zeigt durchschnittlich 17.4% hoehere Resolve-Raten gegenueber fuenf Baselines. Der Zugewinn ist nicht auf ein bestimmtes Modell oder einen bestimmten Benchmark-Typ beschraenkt, was auf die Robustheit des Ansatzes hindeutet.
Methodik
REAgent implementiert eine mehrstufige Pipeline. Im ersten Schritt wird die rohe Issue-Beschreibung analysiert und in ein strukturiertes Requirement-Format ueberfuehrt. Dieses Format umfasst die Problemdefinition, betroffene Code-Bereiche, erwartetes Verhalten und Akzeptanzkriterien. Im zweiten Schritt bewertet ein Qualitaetspruefungsmodul, ob das generierte Requirement ausreichend spezifisch und vollstaendig ist. Falls nicht, durchlaeuft es eine Verfeinerungsschleife, die zusaetzlichen Kontext aus dem Repository einbezieht. Erst wenn das Requirement eine definierte Qualitaetsschwelle erreicht, wird es an den Patch-Generierungsagenten uebergeben.
Die Evaluation erfolgt auf drei etablierten Benchmarks fuer automatische Software-Wartung. Zwei verschiedene LLMs dienen als Backend, um modellspezifische Effekte auszuschliessen. Als Baselines dienen fuenf existierende Ansaetze, die Issues direkt ohne expliziten Requirements-Schritt verarbeiten.
Relevanz fuer die Praxis
Issue-Qualitaet bestimmt Patch-Qualitaet. REAgent liefert den empirischen Beleg fuer etwas, das erfahrene Entwickler intuitiv wissen: Die Qualitaet des Outputs haengt massgeblich von der Qualitaet der Aufgabenstellung ab. Fuer Teams, die mit Coding-Agents arbeiten -- sei es SWE-Agent, Devin, Claude Code oder aehnliche Tools -- ist die direkte Konsequenz: Investition in praezise, strukturierte Issue-Beschreibungen zahlt sich messbar aus.
Requirements Engineering ist keine Legacy-Disziplin. In einer Welt, in der LLM-Agenten zunehmend Code generieren und Issues bearbeiten, wird Requirements Engineering nicht obsolet -- im Gegenteil. Die Faehigkeit, Anforderungen praezise zu formulieren, wird zu einer Kernkompetenz im Umgang mit AI-gestuetzter Softwareentwicklung. REAgent zeigt, dass ein formaler Requirements-Schritt auch fuer automatisierte Systeme den Unterschied macht.
Uebertragbar auf eigene Workflows. Auch ohne REAgent direkt einzusetzen, laesst sich die Kernidee sofort anwenden: Bevor ein Coding-Agent auf ein Issue losgelassen wird, die Beschreibung in ein strukturiertes Format mit klarem erwarteten Verhalten, betroffenen Dateien und Akzeptanzkriterien uebersetzen. Das ist kein Overhead -- es ist die Voraussetzung fuer zuverlaessige Ergebnisse.