Faster Code, Deeper Debt? A Multivocal Literature Review on Technical Debt and Its Early Signs in LLM-Assisted Software Development

Diese multivokale Literaturübersicht von 104 Quellen zeigt auf, dass die LLM-gestützte Softwareentwicklung traditionelle technische Schulden verstärkt und gleichzeitig neuartige, LLM-spezifische Kategorien wie Prompt- und Provenienzschulden einführt, was die dringende Notwendigkeit standardisierter Metriken und Minderungsstrategien verdeutlicht, um den Kompromiss zwischen beschleunigter Kodierung und langfristigen Wartungskosten zu bewältigen.

Das Wesentliche

Stellen Sie sich die Softwareentwicklung wie den Bau eines massiven, komplizierten Hauses vor. Seit Jahrzehnten wissen die Bauarbeiter (Entwickler), dass sie „technische Schulden“ verursachen, wenn sie Abkürzungen nehmen, um Zeit zu sparen – etwa durch die Verwendung von billiger Farbe, das Ignorieren von Bauplänen oder das Vernachlässigen des Fundaments. Diese Schulden sind kein Geld, das man einer Bank schuldet; es ist eine versteckte Rechnung, die man später in Form von Mehrarbeit, Reparaturen und Kopfschmerzen bezahlen muss, wenn das Haus zu lecken beginnt oder die Wände Risse bekommen.

Stellen Sie sich nun vor, ein neuer, unglaublich schneller Roboter-Assistent (das Large Language Model oder LLM) ist der Baustelle beigetreten. Dieser Roboter kann in Sekundenschnelle den Bauplan für ein ganzes Zimmer entwerfen. Er ist erstaunlich schnell, aber dieses Papier stellt eine beängstigende Frage: Baut der Roboter das Haus so schnell, dass wir einen Berg versteckter Schulden anhäufen, die wir noch gar nicht sehen können?

Die Autoren dieses Papiers haben sich wie Detektive verhalten und 104 verschiedene Berichte gelesen (31 von akademischen Forschern und 73 von Branchen-Blogs und Nachrichten), um herauszufinden, welche Art von „Schulden“ dieser Roboter verursacht. Hier ist das, was sie herausgefunden haben, einfach erklärt:

1. Der Roboter macht alte Probleme schlimmer

Der Roboter erfindet nicht nur neue Probleme; er macht die alten viel lauter.

• Das „Copy-Paste“-Chaos: Genau wie ein Mensch vielleicht einen unordentlichen Absatz aus einem Buch kopiert, ohne ihn zu verstehen, generiert der Roboter oft Code, der richtig aussieht, aber eigentlich unordentlich, dupliziert oder voller Fehler ist.
• Der „blinde“ Bauarbeiter: Der Roboter kennt Ihr spezifisches Hausdesign nicht. Er könnte eine Tür bauen, die zwar in die Nachbarschaft passt, aber nicht mit Ihrem Flur verbunden ist. Dies führt zu Design-Schulden (das Layout des Hauses ist verwirrend) und Dokumentations-Schulden (niemand weiß, wie der Roboter diese Wand gebaut hat, also weiß auch niemand, wie man sie später repariert).

2. Der Roboter schafft völlig neue Arten von Schulden

Das ist der überraschendste Teil. Der Roboter bringt Schulden mit sich, die es vorher nicht gab:

• Die „Schnell-Integration“-Schulden: Das ist so, als würde man eine Pizza bestellen und sie so schnell essen, dass man erst merkt, dass sie kalt ist, wenn man schon satt ist. Entwickler sind so begeistert von der Geschwindigkeit des Roboters, dass sie den Code einfach akzeptieren, ohne ihn zu prüfen. Dies führt zu einem „Domino-Effekt“, bei dem sich kleine, unüberprüfte Fehler anhäufen und das gesamte System instabil machen.
• Die „Prompt“-Schulden: Stellen Sie sich vor, der Roboter funktioniert nur, wenn Sie ihm genau die richtigen magischen Worte zuflüstern. Wenn Sie diese Worte (den Prompt) vergessen oder schlecht aufschreiben, baut der Roboter beim nächsten Mal etwas anderes. Wenn Sie diese magischen Worte nicht speichern, wird der Code unmöglich zu reproduzieren. Es ist, als würde man ein Haus bauen, bei dem die Bauanleitung in einem Sturm verloren gegangen ist.
• Die „Governance“-Schulden: Da der Roboter manchmal „halluziniert“ (Dinge erfindet, wie etwa eine Datei, die gar nicht existiert), müssen Menschen mehr Zeit aufwenden, um seine Arbeit zu kontrollen. Der Roboter versprach, Zeit zu sparen, aber jetzt benötigen Sie ein ganzes Team von Inspektoren, nur um sicherzustellen, dass der Roboter nicht gelogen hat.
• Die „Provenienz“-Schulden: Wenn der Roboter eine Wand mit Ziegeln baut, die er sich von einem Nachbarn „gestohlen“ hat (Code aus dem Internet verwendet, ohne die Lizenz zu kennen), könnten Sie später verklagt werden. Es ist unklar, wem die Arbeit des Roboters gehört.

3. Wie lösen wir das? (Die Werkzeuge, die wir haben)

Das Papier untersuchte, was Menschen tun, um zu verhindern, dass die Schulden sich anhäufen:

• Die „Human-in-the-Loop“-Regel: Der am häufigsten gehörte Rat lautet: Vertrauen Sie dem Roboter nicht; überprüfen Sie ihn. Behandeln Sie den Roboter wie einen sehr enthusiastischen, aber unerfahrenen Praktikanten. Sie müssen seine Arbeit überprüfen, testen und korrigieren, bevor Sie sie in das fertige Haus lassen.
• Bessere „magische Worte“ (Prompt Engineering): Wenn Sie klare, strikte Anweisungen geben, macht der Roboter weniger Fehler. Es ist, als würde man einem Koch ein detailliertes Rezept geben, anstatt nur zu sagen: „Mach Abendessen.“
• Die Werkzeuge: Menschen nutzen Standardwerkzeuge (wie SonarQube), die wie Metalldetektoren wirken, um „Code Smells“ (schlechte Praktiken) zu finden. Einige neue Tools versuchen bereits, „KI-bewusst“ zu sein, aber sie stecken noch in den Kinderschuhen.

4. Das große fehlende Teil: Wir haben kein Lineal

Hier ist die größte Warnung des Papiers: Wir haben keine Möglichkeit, diese Schulden genau zu messen.

• Wir haben Lineale, um zu messen, wie lang eine Wand ist (Standard-Code-Metriken).
• Aber wir haben kein Lineal, um zu messen: „Wie sehr hat der Roboter das Fundament vermasselt?“ oder „Wie wahrscheinlich ist es, dass dieser Code in zwei Jahren kaputt geht?“
• Es gibt keine Standardtests oder Benchmarks, um zu sehen, ob ein Roboter ein „sauberes“ Haus baut oder ein „schuldenbelastetes“ eines. Wir fliegen mit verbundenen Augen.

Das Faz-it

Das Papier kommt zu dem Schluss, dass LLMs uns zwar helfen, schneller Software zu bauen, aber gleichzeitig auch ein tieferes Loch an Schulden graben. Wir tauschen kurzfristige Geschwindigkeit gegen langfristige Schmerzen ein.

Um dies zu beheben, müssen wir aufhören, den Roboter als „Zauberstab“ zu betrachten, der alles löst. Wir müssen:

1. Langsamer werden: Überprüfen Sie die Arbeit des Roboters sorgfältig.
2. Die Regeln aufschreiben: Speichern Sie die Prompts und Anweisungen.
3. Neue Messwerkzeuge entwickeln: Wege finden, um zu testen, ob der Code des Roboters tatsächlich langfristig gut ist oder nur für den heutigen Tag.

Bis wir dies tun, riskieren wir, ein Software-Haus zu bauen, das am ersten Tag großartig aussieht, aber ein Jahr später unter seinem eigenen Gewicht zusammenbricht.

Technische Zusammenfassung

Technischer Überblick: Schnellerer Code, Tiefergehende Schulden? Ein multivokaler Literaturüberblick über technische Schulden und deren Frühwarnzeichen in der LLM-gestützten Softwareentwicklung

Problemstellung

Die rasante Integration von Large Language Models (LLMs) in Software-Engineering-Workflows verspricht gesteigerte Produktivität, führt jedoch zu signifikanten, oft übersehenen langfristigen Risiken hinsichtlich technischer Schulden. Während die bisherige Forschung die funktionale Korrektheit und die unmittelbare Qualität von LLM-generiertem Code untersucht hat, besteht eine kritische Lücke im Verständnis darüber, wie diese Artefakte zu langfristigen technischen Schulden akkumulieren. Erste Anzeichen deuten auf einen Trade-off hin, bei dem kurzfristige Geschwindigkeitsgewinne (z. B. erhöhter Code-Churn, reduzierte Wiederverwendbarkeit) die Akkumulation von Schulden beschleunigen können, was sich in hallucinierten Referenzen, unsicheren Konfigurationen und nicht-deterministischem Verhalten manifestiert. Darüber hinaus mangelt es der Literatur an einer ganzheitlichen Sicht darauf, wie traditionelle Schuldenarten (Code, Design, Dokumentation) durch LLMs verstärkt werden und welche neuartigen, LLM-spezifischen Schuldenkategorien entstehen. Zudem gibt es ein deutliches Defizit an standardisierten Benchmarks, LLM-spezifischen Metriken und dedizierten Werkzeugen zur Erkennung und Messung dieser Schulden.

Methodik

Diese Studie verwendet eine multivokale Literaturrecherche (Multivocal Literature Review, MLR), um Evidenz aus sowohl akademischer Forschung als auch aus der „Grauen Literatur“ von Praktikern zu synthetisieren. Der Review-Prozess folgte den Richtlinien von Garousi et al. und dem SEGRESS-Framework.

• Datenquellen: Die Autoren analysierten insgesamt 104 Quellen:
  • 31 formale Quellen: Peer-Review-Veröffentlichungen aus erstklassigen Foren (z. B. ICSE, FSE, TSE, ASE), die über IEEE Xplore, ACM Digital Library, Springer Link und Elsevier ScienceDirect abgerufen wurden.
  • 73 Graue Literaturquellen: Branchenberichte, Unternehmensblogs (z. B. IBM, Salesforce), Entwicklerforen und Medienberichte, die via Google Search (unter Verwendung von SerpAPI) abgerufen und nach Qualität und Relevanz gefiltert wurden.
• Suchstrategie: Eine umfassende Suchzeichenkette kombinierte 13 etablierte Kategorien technischer Schulden (z. B. Code-, Design-, Architektur-Schulden) mit LLM-spezifischen Begriffen (z. B. „LLM“, „Copilot“, „AI-generated code“).
• Selektionskriterien: Die Aufnahme erforderte eine explizite Diskussion technischer Schulden im Kontext von LLMs oder KI-gestütztem Code. Ausschlusskriterien entfernten Arbeiten, die sich ausschließlich auf die funktionale Qualität ohne Berücksichtigung von Schulden konzentrierten, oder solche, die sich auf den Einsatz von LLMs zur Erkennung von Schulden statt zu deren Entstehung konzentrierten.
• Analyse: Die Autoren verwendeten einen hybriden Kodierungsansatz:
  • Deduktive Kodierung: Anwendung der bestehenden Taxonomie technischer Schulden nach Alves et al. (13 Typen).
  • Induktive Kodierung: Identifizierung aufkommender, LLM-spezifischer Schuldenkategorien, die nicht durch traditionelle Taxonomien abgedeckt sind.
  • Reliabilität: Zwei Autoren extrahierten unabhängig Daten und kodierten die Quellen, wobei eine hohe Inter-Rater-Reliabilität (Cohen's Kappa > 0,90 für die meisten Kategorien) erreicht wurde.

Zentrale Beiträge

1. Erste multivokale Perspektive: Dies ist die erste Übersicht, die akademische und praktische Perspektiven integriert, um die Landschaft der technischen Schulden in der LLM-gestützten Entwicklung abzubilden.
2. Erweiterung der Taxonomie: Die Studie bestätigt, dass traditionelle Schuldenarten (Code, Design, Dokumentation) präsent sind, identifiziert jedoch sechs aufkommende, LLM-spezifische Schuldenkategorien:
   • Governance-Schulden (Governance Debt): Langfristige Aufsichtsbelastungen aufgrund von Halluzinationen und Nicht-Determinismus.
   • Fast-Integration-Schulden (Fast-Integration Debt): Risiken, die durch die Priorisierung von Geschwindigkeit gegenüber Validierung („Vibe Coding“) entstehen, was zu instabilen Fundamenten führt.
   • Prompt-Schulden (Prompt Debt): Verbindlichkeiten, die durch unklare, undokumentierte oder fragile Prompts verursacht werden, welche die Reproduzierbarkeit behindern.
   • Daten-Schulden (Data Debt): Verborgene Verbindlichkeiten durch verrauschte oder opake Trainings-/Retrieval-Daten, die Fehler in den generierten Code propagieren.
   • Ethische Schulden (Ethical Debt): Akkumulierte Risiken von Bias und Fairness-Fehlern im generierten Code, die Endnutzer betreffen.
   • Provenienz-Schulden (Provenance Debt): Unklare Eigentümerschaft oder Attribuierung von KI-generierter Logik.
3. Synthese von Strategien: Der Review bildet bestehende Minderungsstrategien ab und hebt die starke Abhängigkeit von Human-in-the-Loop (HITL)-Frameworks, Prompt Engineering und der Abstimmung der Datenqualität hervor.
4. Identifikation von Forschungslücken: Das Paper benennt das Fehlen von standardisierten Benchmarks und LLM-spezifischen Metriken als kritisches Hindernis für eine systematische Evaluierung und Verwaltung dieser Schulden.

Ergebnisse

RQ1: Formen technischer Schulden

• Traditionelle Schulden: Code-Schulden waren das am häufigsten genannte Problem (56 graue Quellen, 14 formale), getrieben durch Entwickler, die Code ohne vollständiges Verständnis der Logik integrieren, was zu Duplikation und Komplexität führt. Design-Schulden (30 Quellen) und Dokumentations-Schulden (17 Quellen) waren ebenfalls prominent, da LLMs oft die Systemarchitektur ignorieren und die Dokumentation nicht aktualisieren.
• Aufkommende Schulden:
  • Governance-Schulden (19 Quellen) war die am häufigsten diskutierte neue Kategorie, was die Notwendigkeit einer kontinuierlichen Aufsicht über nicht-deterministische Outputs widerspiegelt.
  • Fast-Integration-Schulden (13 Quellen) verdeutlichen die „Geschwindigkeitsfalle“, bei der eine schnelle Adoption die Fähigkeit zur Validierung der Wartbarkeit überholt.
  • Prompt-, Ethical- und Provenance-Schulden wurden als einzigartige Herausforderungen identifiziert, die neue Managementansätze erfordern.

RQ2: Minderungsstrategien

• Human-in-the-Loop: Die dominierende Strategie in beiden Literaturbereichen ist die Behandlung von LLMs als „Junior-Entwickler“, was rigorose Code-Reviews, Tests und Validierungen vor der Integration erfordert.
• Prompt Engineering: Strukturierte Prompts, Versionierung und klarer Kontext werden als essenziell angeführt, um Prompt-Schulden zu reduzieren und die Output-Qualität zu verbessern.
• Datenqualität: Die formale Literatur betont die Vorverarbeitung von Trainingsdaten und die Abstimmung mit Standards (z. B. ISO/IEC), um Daten-Schulden zu mindern.
• Tooling: Werkzeuge existieren zwar, werden jedoch oft zweckentfremdet.

RQ3: Werkzeuge und Techniken

• Aktuelle Landschaft: Praktiker verlassen sich stark auf allgemeine statische Analysetools wie SonarQube, ESLint und Pylint, um Code-Smells und Schwachstellen zu erkennen.
• Aufkommende Werkzeuge: Kommerzielle Tools wie Amazon CodeWhisperer, GitHub Copilot (mit Responsible-AI-Funktionen), Snyk und Swimm beginnen, Funktionen für Sicherheit, Erklärbarkeit und Dokumentation anzubieten.
• Forschungsprototypen: Akademische Bemühungen umfassen CodeSmellEval (zur Messung der Neigung zu Code-Smells in LLMs) und QualAI (zur Überwachung der Qualität von KI-Systemen), diese sind jedoch noch nicht standardisiert oder weit verbreitet.

RQ4 & RQ5: Benchmarks und Metriken

• Benchmarks: Der Review fand keine standardisierten Benchmarks oder Datensätze, die spezifisch darauf ausgelegt sind, technische Schulden in LLM-generiertem Code zu evaluieren. Bestehende Benchmarks konzentrieren sich auf binäre Korrektheit (z. B. CodeXGLUE) statt auf langfristige Wartbarkeit oder die Akkumulation von Schulden.
• Metriken: Aktuelle Metriken (z. B. SonarQube-Regeln) sind unzureichend, da sie semantische Genauigkeit, architektonische Passgenauigkeit und LLM-spezifische Risiken wie Prompt-Reliabilität oder Provenienz nicht erfassen.
• Vorgeschlagene Dimensionen: Die Literatur legt nahe, dass neue Metriken für Kontextsensitivität, Adaptierbarkeit, Reviewbarkeit, Prompt-Reliabilität und Data-Smell-Stärke/Dichte benötigt werden.

Signifikanz und Behauptungen

Das Paper behauptet, dass die Integration von LLMs in das Software Engineering nicht nur einen Produktivitätsschub darstellt, sondern einen fundamentalen Wandel bewirkt, der – wenn nicht gemanagt – „tiefergehende Schulden“ einführt. Die Autoren argumentieren:

1. LLMs verstärken traditionelle Schulden, indem sie die Erstellung von Code beschleunigen, der schwer zu warten, zu testen und zu verstehen ist.
2. Neue Schuldenkategorien (Governance, Fast-Integration, Prompt etc.) erfordern distinkte Managementstrategien, die über das traditionelle Code-Review hinausgehen.
3. Das Feld ist derzeit fragmentiert: Während Strategien wie HITL weitgehend konsensfähig sind, verhindert der Mangel an standardisierten Tools, Metriken und Benchmarks die systematische Messung und Minderung dieser Risiken.
4. Zukünftige Richtungen: Die Autoren fordern die Software-Engineering-Community auf, über die bloße Dokumentation von Risiken hinauszugehen und hin zum Aufbau von handlungsorientierten Lösungen zu gelangen, einschließlich der Entwicklung von Open-Source-Tools, gemeinschaftlich getriebenen Benchmarks und longitudinalen Studien zur Verfolgung der Schuldenakkumulation über die Zeit. Sie betonen, dass ohne diese Entwicklungen die „KI-native“ Vision des Software Engineering 3.0 aufgrund unverwalteter technischer Schulden nicht nachhaltig sein wird.