LLM-Assisted Repository-Level Generation with Structured Spec-Driven Engineering

Dieser Artikel schlägt Strukturierte Spezifikationsgetriebene Entwicklung (SSDE) vor, ein Paradigma, das strukturierte Spezifikationen nutzt, um die Mehrdeutigkeit und Qualitätsbeschränkungen von Prompts in natürlicher Sprache zu überwinden und dadurch eine hochwertige, verifizierbare Codegenerierung auf Repository-Ebene zu ermöglichen.

Das Wesentliche

Stellen Sie sich vor, Sie versuchen, einem sehr talentierten, aber leicht zerstreuten Lehrling im Kochhandwerk beizubringen, ein riesiges, komplexes Bankett für eine ganze Stadt zu kochen.

Das Problem: Der „vage Auftrag"
Wenn Sie derzeit ein hochleistungsfähiges KI-Modell (den Lehrling) bitten, Code für ein komplettes Softwaresystem zu schreiben, geben Sie ihm normalerweise nur eine lange Beschreibung in natürlicher Sprache, wie etwa: „Erstellen Sie eine Website, auf der Menschen Meetings buchen können." Das ist, als würden Sie dem Koch sagen: „Kochen Sie ein leckeres Essen."

Die Arbeit argumentiert, dass die KI zwar hervorragend darin ist, eine einzelne Zwiebel zu hacken (eine kleine Funktion zu schreiben), aber den Überblick verliert, wenn sie gebeten wird, das gesamte Bankett zu kochen (ein komplettes Software-Repository). Natürliche Sprache ist zu ungenau. Die KI könnte falsch raten, einen Schritt vergessen oder ein Gericht zubereiten, das gut aussieht, aber nicht richtig schmeckt. Schlimmer noch: Da die Anweisungen vage waren, ist es schwer zu beweisen, warum das Essen gescheitert ist.

Die Lösung: Das „strukturierte Rezeptbuch"
Die Autoren schlagen eine neue Arbeitsweise vor, die als Strukturierte Spezifikationsgetriebene Entwicklung (SSDE) bezeichnet wird. Anstelle eines vagen Gesprächs schlagen sie vor, der KI ein strenges, strukturiertes „Rezeptbuch" zu geben.

In dieser Arbeit verwenden sie zwei Arten von strukturierten Rezepten:

1. Gherkin-Spezifikationen: Denken Sie an diese als „Wenn-Dann"-Testfälle. Anstatt zu sagen „Lassen Sie es funktionieren", schreiben Sie: „WENN ein Benutzer auf 'Buchen' klickt, DANN muss der Raum als 'Belegt' markiert sein." Es ist eine Checkliste exakter Verhaltensweisen.
2. Domänenmodelle: Diese sind wie architektonische Baupläne oder eine Landkarte der Zutaten. Sie zeigen, wie verschiedene Teile des Systems (wie „Benutzer", „Räume" und „Daten") miteinander verbunden sind.

Das Experiment: Der Geschmackstest
Die Forscher richteten eine Pilotstudie ein. Sie agierten als Küchenchefs und gaben fünf verschiedenen KI-Modellen (den Lehrlingen) die Aufgabe, die „Geschäftslogik" (die Kochregeln) für drei verschiedene Softwaresysteme zu erstellen.

Sie testeten verschiedene Kombinationen:

• Die Kontrollgruppe: Nur die vage Beschreibung in natürlicher Sprache.
• Die Testgruppen: Die vage Beschreibung ZUSÄTZLICH zum strukturierten „Rezeptbuch" (die Baupläne und die „Wenn-Dann"-Checklisten).

Die Ergebnisse: Struktur gewinnt
Die Ergebnisse waren klar:

• Bessere Genauigkeit: Wenn die KI das strukturierte „Rezeptbuch" (die Baupläne und Checklisten) hatte, machte sie weit weniger Fehler als nur mit der vagen Beschreibung.
• Der „Bauplan"-Boost: Die KI wurde am meisten unterstützt, wenn sie neben den Bauplänen auch die spezifischen Code-Signaturen (die genaue Liste der Zutaten und Werkzeuge) erhielt. Das war, als würde man dem Koch nicht nur das Rezept geben, sondern auch die exakte Marke des Mehls und die spezifische Größe der Pfanne, die zu verwenden ist.
• Noch Luft nach oben: Obwohl der strukturierte Ansatz viel besser war, machte die KI immer noch einige Fehler. Die Forscher stellten jedoch fest, dass über 70 % dieser Fehler einfache, erkennbare Irrtümer waren – Dinge wie das Referenzieren einer nicht existierenden Variable oder ein Python-Syntaxfehler. Diese benötigen nicht einmal einen Test-Oracle (d. h. das Ausführen des Codes mit Beispielen, um das Ergebnis zu prüfen): Ein Standard-Compiler oder Linter würde sie erkennen.

Die Zukunfts-Roadmap
Die Arbeit schlägt vor, dass wir, um dies perfekt funktionieren zu lassen, Folgendes tun müssen:

1. Eine Feedback-Schleife hinzufügen: Anstatt die KI nur einmal zu bitten, sollten wir ihr erlauben, den Code zu schreiben, ihn gegen das „Rezeptbuch" zu prüfen und seine eigenen Fehler automatisch zu korrigieren.
2. Bessere Datensätze aufbauen: Wir benötigen mehr Beispiele dieser strukturierten Rezeptbücher, um die KI besser zu trainieren.
3. Änderungen bewältigen: Echte Software ändert sich ständig. Wir müssen der KI beibringen, wie sie nur einen Teil des Banketts aktualisiert (wie das Dessert austauscht), ohne das gesamte Essen zu ruinieren.

Das Fazit
Die Arbeit kommt zu dem Schluss, dass wir, wenn wir aufhören, KI wie einen Zauberstab zu behandeln, der auf vage Wünsche reagiert, und beginnen, sie wie einen geschulten Arbeiter zu behandeln, der einem strengen, strukturierten Bauplan folgt, wir sie dazu bringen können, ganze Softwaresysteme zuverlässig zu erstellen. Sie verwandelt die KI von einem „kreativen Rater" in einen „präzisen Baumeister".

Technische Zusammenfassung

Technischer Zusammenfassung: LLM-gestützte Generierung auf Repository-Ebene mit strukturierter spezifikationsgetriebener Entwicklung

Problemstellung

Während Large Language Models (LLMs) eine hohe Kompetenz bei der Generierung von Code auf Funktions- oder Dateiebene demonstrieren, verschlechtert sich ihre Zuverlässigkeit erheblich, wenn sie auf Systeme auf Repository-Ebene skaliert werden. Aktuelle Workflows, die sich ausschließlich auf natürliche Sprachprompts verlassen, leiden unter inhärenter Mehrdeutigkeit, was die Kommunikation „verlustbehaftet" macht und die Generierung überprüfbarer Ausgaben (z. B. Softwaretests) behindert. Eine einfache Erhöhung der Ausführlichkeit natürlicher Sprachanweisungen behebt das grundlegende Fehlen an Präzision nicht, das für eine zuverlässige, großskalige Codegenerierung und -verifizierung erforderlich ist. Die Autoren gehen davon aus, dass ein Wechsel von unstrukturierter natürlicher Sprache zu strukturierten Spezifikationen notwendig ist, um eine zuverlässige, überprüfbare und hochwertige Generierung auf Repository-Ebene zu ermöglichen.

Methodik: Strukturierte spezifikationsgetriebene Entwicklung (SSDE)

Die Arbeit schlägt die Strukturierte spezifikationsgetriebene Entwicklung (SSDE) vor, ein Paradigma, bei dem strukturierte Artefakte (anstatt freier natürlicher Sprache) als primäre Eingabe dienen, um LLM-Agenten zu steuern. Die Autoren führten eine Pilotstudie durch, um die Machbarkeit dieser Vision zu untersuchen.

Experimenteller Aufbau

• Aufgabe: Generierung von Model-View-Controller (MVC)-Geschäftslogik (insbesondere Python-Controller) für drei bestehende Softwaresysteme: Symboleo, CheECSEManager und MeetingGroups.
• Modelle: Fünf LLMs wurden evaluiert, darunter Open-Source-Modelle (Qwen 3, Llama 3.2) und Closed-Source-Modelle (Claude Sonnet 4.5, GPT 5.1, GPT 5 Nano) unterschiedlicher Größen.
• Eingabekonfigurationen: Die Studie verglich vier Arten von kontextuellen Eingaben, die dem LLM zusammen mit einem Controller-Template bereitgestellt wurden:
  1. Natürliche Sprachspezifikation: Freiform-Beschreibungen des Systemzwecks und der Einschränkungen.
  2. Gherkin-Spezifikation: Strukturierte, ausführbare Szenarien, die das Systemverhalten definieren.
  3. Domänenmodell: Abstrakte Softwaremodelle (Umple oder Ecore), die Domänenkonzepte und -beziehungen erfassen.
  4. Signaturmodell: Die generierten Klassen- und Funktionssignaturen (API), die aus den Domänenmodellen abgeleitet wurden.
• Auswertung:
  • Quantitativ: Ein von Menschen verifizierter Python-Unit-Test-Suite (abgebildet auf Gherkin-Szenarien) wurde gegen die generierten Controller ausgeführt. Die Hauptmetrik war die Test-Pass-Rate (TPR).
  • Qualitativ: Manuelle Inspektion des generierten Codes zur Identifizierung wiederkehrender Fehlermuster und Codequalitätsmerkmale.
  • Wiederholung: Jede Konfiguration wurde pro LLM 10-mal ausgeführt, um stochastische Verzerrungen zu berücksichtigen.

Wichtige Ergebnisse

Die Pilotstudie lieferte mehrere kritische Erkenntnisse bezüglich der Wirksamkeit strukturierter Eingaben:

1. Überlegenheit strukturierter Eingaben: Das Hinzufügen irgendeiner Form strukturierter Spezifikation (Gherkin, Domänenmodell oder Signaturen) verbesserte die Ausgabequalität im Vergleich zur Baseline, bei der nur natürliche Sprachspezifikationen verwendet wurden, erheblich.
2. Potenzial von Gherkin: Obwohl Gherkin-Spezifikationen in Kombination mit Modellen zunächst eine etwas niedrigere durchschnittliche TPR (6,8 % niedriger) und eine höhere Varianz als Kombinationen mit natürlicher Sprache zeigten, schnitten sie in 14 von 30 spezifischen Kombinationen besser ab als natürliche Sprache. Die Autoren verweisen auf das Potenzial dieses Ansatzes, natürliche Sprache bei weiterer Verfeinerung zu übertreffen.
3. Wert von Signaturen: Die Bereitstellung der Signaturen (API) der Modellebene, die aus Domänenmodellen generiert wurden, erwies sich als hochwirksam. Diese Konfiguration verbesserte die durchschnittliche TPR um +7,82 % und reduzierte die Standardabweichung um -2,47 % im Vergleich zur Verwendung roher Domänenmodelle. Dies deutet darauf hin, dass LLMs von expliziten API-Definitionen mehr profitieren als von abstrakter Modelsyntax.
4. Fehleranalyse: Über 70 % der Testfehler wurden durch Fehler verursacht, die mittels statischer Codeanalyse erkennbar sind (z. B. Aufruf nicht existierender APIs, Datentyp-Mismatches, nicht validierte Einschränkungen). Dies zeigt, dass ein erheblicher Teil der Generierungsfehler struktureller und nicht logischer Natur ist, was sie für eine automatische Korrektur zugänglich macht.
5. Modellleistung: Claude Sonnet 4.5 erwies sich als bestes Modell und erreichte in mehreren Konfigurationen TPRs von über 80 %. Hohe Standardabweichungen über die Durchläufe hinweg unterstrichen jedoch die stochastische Natur von LLMs, bei der bestimmte Fehlertypen konsistent durch generierte Controller propagieren.

Wichtige Beiträge

• Vorschlag von SSDE: Die Arbeit führt die Strukturierte spezifikationsgetriebene Entwicklung als ein gangbares Paradigma ein, um die Lücke zwischen hohen Anforderungen und der Codegenerierung auf Repository-Ebene zu schließen, wobei die Überprüfbarkeit strukturierter Artefakte genutzt wird.
• Empirische Machbarkeitsstudie: Die Autoren liefern die erste Pilotstudie, die zeigt, dass strukturierte Eingaben (Gherkin, Domänenmodelle, Signaturen) die Qualität von von LLMs generiertem Code auf Repository-Ebene im Vergleich zu Prompts in natürlicher Sprache spürbar verbessern können.
• Identifizierung von Fehlermustern: Die Studie kategorisiert Fehlermodi und zeigt, dass die Mehrheit der Fehler struktureller und erkennbarer Natur ist, was auf einen klaren Weg für automatisierte Feedbackschleifen hinweist.
• Forschungsroadmap: Die Arbeit skizziert einen konkreten Weg für das Feld, der sich auf drei Säulen konzentriert:
  1. Verbesserung der Ausgabequalität: Implementierung von Feedbackschleifen mittels statischer Analyse und dynamischem Testen, um LLMs die Selbstkorrektur struktureller Fehler zu ermöglichen.
  2. Evaluierung der realen Auswirkungen: Überwindung der einmaligen Generierung hin zur Evaluierung von Agenten-Workflows, Token-Kosteneffektivität und Netto-Produktivitätsgewinnen (unter Berücksichtigung des Aufwands zur Pflege strukturierter Spezifikationen).
  3. Anwendbarkeit: Entwicklung von Techniken für partielle Repository-Aktualisierungen zur Bewältigung kontinuierlicher Evolution und Integration von SSDE mit diversen Modellierungswerkzeugen und Darstellungen der physischen Welt.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass SSDE einen greifbaren Weg hin zu hochwertiger, überprüfbarer Codegenerierung auf Repository-Ebene bietet. Durch den Wechsel von mehrdeutiger natürlicher Sprache zu strukturierten Spezifikationen nutzt der Ansatz jahrzehntelanges Wissen aus dem Softwareengineering (z. B. Modellgetriebene Entwicklung, Gherkin), um LLMs zu steuern.

Die Autoren argumentieren, dass LLMs zwar derzeit mit Systemen großer Skalierung Schwierigkeiten haben, die Integration strukturierter Spezifikationen jedoch die Codegenerierung von einem „Black-Box"-Prozess in einen überprüfbaren und wartbaren Prozess verwandelt. Die Studie legt nahe, dass die Mehrheit der aktuellen Generierungsfehler keine unüberwindbaren logischen Lücken, sondern vielmehr strukturelle Inkonsistenzen sind, die durch automatisierte Feedbackmechanismen behoben werden können. Letztendlich zielt SSDE darauf ab, den manuellen Engineering-Aufwand zu reduzieren, indem sie eine effektive Mensch-Computer-Kollaboration fördert, bei der Ingenieure als Architekten der Spezifikationen agieren und LLMs die Übersetzung in die Implementierung übernehmen.