Quality Assurance of LLM-generated Code: Addressing Non-Functional Quality Characteristics

Diese Studie identifiziert eine Diskrepanz zwischen akademischem Fokus, industriellen Prioritäten und dem tatsächlichen Verhalten von LLMs hinsichtlich nicht-funktionaler Code-Qualität und fordert die Integration von Qualitätssicherungsmechanismen in Generierungs-Pipelines, um technische Schulden zu vermeiden.

Das Wesentliche

Stellen Sie sich vor, Sie haben einen extrem talentierten, aber etwas naiven Koch namens Künstliche Intelligenz (KI). Dieser Koch kann unglaublich schnell und kreativ Rezepte (Code) für Sie schreiben. Wenn Sie ihm sagen: „Mach mir ein Omelett," liefert er Ihnen eines, das funktioniert – die Eier sind gebraten, es schmeckt. Das ist der funktionale Erfolg: Der Code läuft, die Tests bestehen.

Aber dieser neue Koch hat ein Problem: Er denkt nur an das Ergebnis, nicht an die Qualität des Gerichts für die Zukunft.

Dieser wissenschaftliche Artikel untersucht genau dieses Problem. Die Forscher von der Universität Linköping in Schweden wollten herausfinden: Ist der Code, den diese KI-Köche produzieren, wirklich gut für den langfristigen Betrieb, oder baut er uns eine Falle?

Hier ist die einfache Erklärung der Studie, aufgeteilt in drei Teile:

1. Was sagen die Bücher? (Die Literaturrecherche)

Die Forscher haben sich 109 andere Studien angesehen.

• Das Problem: Die meisten Forscher schauen nur darauf, ob das Omelett funktioniert. Sie prüfen aber selten, ob das Omelett gesund ist (Sicherheit), ob es leicht zu verderben ist (Wartbarkeit) oder ob es zu viel Energie verbraucht (Performance).
• Die Metapher: Es ist, als würden wir nur prüfen, ob das Auto fährt, aber nicht, ob die Bremsen rosten oder der Motor überhitzt. Die Studien konzentrieren sich stark auf „Sicherheit" (wie gut ist der Schutz?), aber vernachlässigen oft, wie schwer es sein wird, den Code später zu verstehen oder zu ändern.

2. Was sagen die Profis? (Die Workshops mit Entwicklern)

Die Forscher haben dann echte Software-Entwickler (die „Chefköche" der Branche) gefragt, was sie wirklich stört.

• Die Erkenntnis: Die Entwickler sind weniger besorgt darüber, ob der Code jetzt funktioniert. Sie haben Angst vor der Zukunft.
• Die Metapher: Stellen Sie sich vor, die KI baut ein Haus. Der Chef-Koch (der Entwickler) sagt: „Ja, das Haus steht und hat ein Dach. Aber die Wände sind aus Pappe, die Leitungen sind chaotisch verlegt und ich verstehe nicht, wie ich später ein Fenster einbauen soll."
• Das Risiko: Wenn wir zu viel Code von der KI produzieren lassen, ohne ihn zu prüfen, häufen wir „technische Schulden" an. Das ist wie ein Kredit, den wir heute aufnehmen, um schnell zu bauen, aber in fünf Jahren müssen wir mit Zinsen (viel mehr Arbeit) zurückzahlen, weil das Gebäude instabil ist. Für die Entwickler ist Lesbarkeit (kann ich das verstehen?) und Wartbarkeit (kann ich das reparieren?) wichtiger als alles andere.

3. Der große Test (Die Experimente)

Die Forscher haben einen echten Test durchgeführt. Sie gaben der KI echte Probleme in großen Software-Projekten (wie Django oder SymPy) und ließen sie Lösungen (Patches) finden. Sie haben drei verschiedene KI-Modelle getestet (wie Claude, GPT-4o und DeepSeek).

Was passierte?

• Der „Pass-oder-Scheitern"-Effekt: Die KI konnte oft Lösungen finden, die die Tests bestanden. Aber wenn man sie bat, den Code besser zu machen (z. B. sicherer oder schneller), ging oft etwas anderes schief.
• Die Metapher: Es ist, als würde man dem Koch sagen: „Mach das Omelett schneller!" Der Koch wirft dann alle Eier in die Pfanne, ohne sie zu schlagen. Es ist schnell, aber es schmeckt nicht mehr und ist ungesund.
• Der Trade-off (Das Dilemma): Wenn man die KI anwies, den Code sicherer zu machen, wurde er oft langsamer oder schwerer zu warten. Wenn man ihn anwies, ihn schneller zu machen, wurde er unsicherer.
• Die überraschende Entdeckung: Die KI wusste nicht, dass sie „guten" Code schreiben sollte. Sie wusste nur, wie man den Test besteht. Ohne menschliche Anleitung oder spezielle Werkzeuge, die auf Qualität achten, produziert die KI oft Code, der funktioniert, aber technisch „schmutzig" und riskant ist.

Das Fazit in einem Satz

Die KI ist ein genialer Assistent, der uns schnell Code liefern kann, aber sie ist wie ein ungeduldiger Lehrling: Sie macht die Arbeit schnell fertig, baut aber oft Brücken, die später einstürzen, oder Wände, die man nicht streichen kann.

Was müssen wir tun?
Wir können uns nicht darauf verlassen, dass die KI von selbst „guten" Code schreibt. Wir müssen neue Werkzeuge und Prozesse entwickeln, die den Code nicht nur auf „Funktioniert?" prüfen, sondern auch auf „Ist er sicher?", „Ist er sauber?" und „Kann ich ihn in fünf Jahren noch verstehen?". Nur so vermeiden wir, dass unsere Software-Systeme in Zukunft zu einem undurchdringlichen Dschungel aus technischem Müll werden.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Quality Assurance of LLM-generated Code: Addressing Non-Functional Quality Characteristics" auf Deutsch:

1. Problemstellung

Die Integration von Large Language Models (LLMs) in Software-Engineering-Workflows hat die Code-Generierung revolutioniert. Bisherige Evaluierungen konzentrieren sich jedoch fast ausschließlich auf die funktionale Korrektheit (d. h., ob der Code die Tests besteht). Es fehlt ein tiefgreifendes Verständnis der nicht-funktionalen Qualitätsmerkmale (NFQCs) wie Sicherheit, Wartbarkeit und Leistungseffizienz.

Das Paper identifiziert folgende Kernprobleme:

• Fehlende Systematik: Es gibt keine einheitlichen Rahmenwerke zur Bewertung von NFQCs in generiertem Code.
• Diskrepanz zwischen Forschung und Praxis: Die akademische Forschung priorisiert oft Sicherheit und Leistung, während Praktiker in der Industrie vor allem Wartbarkeit und Lesbarkeit als kritisch erachten, da generierter Code sonst technische Schulden (Technical Debt) akkumuliert.
• Instabilität bei der Optimierung: Es ist unklar, ob NFQCs durch Prompt-Engineering gezielt verbessert werden können, ohne andere Qualitätsmerkmale zu verschlechtrade (Trade-offs).

2. Methodik

Die Studie verfolgt einen Mixed-Methods-Ansatz, der drei komplementäre Elemente kombiniert, um NFQCs aus verschiedenen Perspektiven zu untersuchen:

1. Literaturübersicht (Systematic Literature Review):

   • Analyse von 109 wissenschaftlichen Arbeiten (2022–2025).
   • Mapping der untersuchten Qualitätsmerkmale auf das ISO/IEC 25010-Modell.
   • Ziel: Identifikation von Forschungslücken und Trends.

2. Industrie-Workshops:

   • Durchführung von zwei Workshops mit 15 Praktikern aus sieben verschiedenen Organisationen (u. a. Mitglieder des Software Center).
   • Ziel: Erfassung der realen Erwartungen, Schmerzpunkte und Prioritäten von Entwicklern bei der Integration von LLM-Code.

3. Empirische Studie (Experimentelle Evaluation):

   • Datensatz: Nutzung von SWE-bench Lite (300 reale GitHub-Issues aus Python-Repositories wie Django und SymPy).
   • Modelle: Drei führende LLMs: Claude 4 Sonnet, DeepSeek-Reasoner und GPT-4o.
   • Framework: Einsatz von SWE-agent zur automatisierten Patch-Generierung und -Verifikation.
   • Experimentdesign (3 Stufen):
     1. Baseline: Generierung von Patches und Evaluation von Funktionalität, Laufzeit, Speichernutzung sowie statische Analyse (Security/Maintainability) mittels CodeQL.
     2. Filter & Prompt-Design: Identifikation von Instanzen, die von allen Modellen erfolgreich gelöst wurden. Design von optimierten Prompts basierend auf CodeQL-Feedback (z. B. „Verbessere Sicherheit basierend auf diesem Report").
     3. Regeneration & Trade-off-Analyse: Erneute Generierung der Patches mit den optimierten Prompts und Vergleich der Ergebnisse, um Trade-offs zwischen den NFQCs zu messen.

3. Wichtige Beiträge

• Multidimensionale Perspektive: Erste umfassende Studie, die akademische Forschung, industrielle Praxis und empirische Daten zusammenführt, um NFQCs zu bewerten.
• Identifikation von Diskrepanzen: Nachweis einer signifikanten Lücke zwischen dem, was die Forschung misst (oft Sicherheit/Performance), und dem, was die Industrie benötigt (Wartbarkeit/Lesbarkeit).
• Trade-off-Analyse: Systematische Untersuchung, wie die Optimierung eines Qualitätsmerkmals (z. B. Sicherheit) andere Merkmale (z. B. Wartbarkeit oder Funktionalität) beeinflusst.
• Rahmenwerk für Evaluation: Nutzung von CodeQL und SWE-bench für eine reproduzierbare, repository-level Bewertung von NFQCs.

4. Ergebnisse

A. Literatur und Workshops

• Forschungstrends: Die Forschung konzentriert sich stark auf Sicherheit (33,6 %), Performance (23,3 %) und Wartbarkeit (17,2 %). Andere Merkmale wie Zuverlässigkeit werden kaum untersucht.
• Industrieprioritäten: Praktiker betonen Wartbarkeit und Lesbarkeit als kritischste Faktoren. Sie warnen, dass generierter Code ohne menschliche Aufsicht technische Schulden beschleunigt, da LLMs oft den Kontext großer Codebasen nicht vollständig verstehen (z. B. zyklische Importe).
• Messbarkeit: Ein Großteil der Forschung beschränkt sich auf code-level Metriken, die leicht automatisiert werden können, während systemweite Merkmale (z. B. Usability) vernachlässigt werden.

B. Empirische Ergebnisse

• Funktionale Korrektheit: LLMs erreichen deutlich geringere Raten als menschliche Referenzpatches (Gold Patches). GPT-4o hatte die höchste syntaktische Erfolgsrate (75 %), aber die niedrigste funktionale Lösungsrate (16 %).
• Qualität der Baseline: Generierte Patches triggern signifikant mehr CodeQL-Regeln als menschliche Patches.
  • Wartbarkeit: Generierter Code enthält viele zyklische Importe (cyclic-import), während menschliche Patches eher lokale Probleme wie ungenutzte Variablen aufweisen.
  • Sicherheit: Generierter Code enthält mehr Fehler auf „Error"-Level, oft durch unverschlüsselte Speicherung sensibler Daten.
• Effekt von Prompt-Optimierung:
  • Das gezielte Optimieren eines NFQC durch Prompts führt oft zu einem Rückgang der funktionalen Korrektheit.
  • Beispiel: Bei Sicherheits-Optimierung sank die Lösungsrate von GPT-4o auf 12 %.
• Trade-offs:
  • Die Optimierung eines Merkmals führt häufig zu Verschlechterungen bei anderen.
  • Beispiel: Laufzeit-Optimierung führte bei einigen Instanzen zu einem massiven Anstieg des Speicherverbrauchs (z. B. von 20 MB auf 177 MB).
  • Es gibt keine stabilen, universellen Optimierungen; Ergebnisse sind instabil und kontextabhängig.

5. Bedeutung und Implikationen

Die Studie zeigt, dass die aktuelle Generation von Code durch LLMs zwar funktional korrekt sein kann, aber oft strukturell fragil ist und technische Schulden akkumuliert.

• Warnung vor blindem Vertrauen: Das bloße Bestehen von Tests reicht nicht aus. Ohne integrierte Qualitätsmechanismen riskieren Unternehmen die Einführung von Code, der schwer wartbar oder unsicher ist.
• Notwendigkeit neuer Pipelines: Es besteht ein dringender Bedarf, Qualitätsassurance-Mechanismen (wie statische Analyse-Feedback-Schleifen) direkt in die Generierungs-Pipelines zu integrieren, um NFQCs in Echtzeit zu überwachen und zu steuern.
• Zukünftige Forschung: Die Forschung muss sich von der reinen Bewertung der Modelle hin zur Bewertung der Ausgaben (Outputs) und deren Interaktion in komplexen, realen Umgebungen bewegen. Die Entwicklung von Strategien zum Management von Trade-offs zwischen verschiedenen Qualitätsmerkmalen ist essenziell.

Fazit: LLMs generieren Code, der „Tests besteht", aber nicht unbedingt „mit Qualität besteht". Um dies zu ändern, müssen Evaluierungsrahmen, Optimierungsstrategien und Validierungspraktiken an die realen Qualitätsanforderungen der Softwareentwicklung angepasst werden.