Technische Schuld durch KI-generierten Code: Wenn schneller gebauter Code später teuer wird
Kurz gesagt
Erste Untersuchungen deuten darauf hin, dass ein Teil der von KI eingeführten Probleme im Code langfristig bestehen bleibt, allerdings ist die Datenlage vorläufig und mit Einschränkungen verbunden. Klarer belegt sind sechs unterscheidbare Formen technischer Schuld, die bei KI-gestützter Entwicklung besonders leicht unbemerkt entstehen, wenn niemand aktiv gegensteuert.
Ein vorläufiger, aber ernstzunehmender Befund
Eine große Mining-Studie hat 304.362 explizit als KI-authentifiziert markierte Commits sowie mehrere hunderttausend statisch erkannte Probleme ausgewertet. Ergebnis: Rund 24,2 Prozent der verfolgten, von KI eingeführten Probleme bestanden am zuletzt untersuchten Stand des jeweiligen Repositorys noch fort. Wichtig für die Einordnung: Es handelt sich um einen Preprint, dessen Attributionsmethodik – also die genaue Zuordnung, welcher Fehler tatsächlich von der KI stammt – Grenzen hat. Der Wert sollte deshalb als Warnsignal gelesen werden, nicht als allgemeingültige Fehlerquote für KI-generierten Code.
Was Benchmark-Audits über Testqualität zeigen
Ein OpenAI-Audit fand bei mindestens 59,4 Prozent von 138 besonders schwierigen, ausführlich geprüften SWE-bench-Verified-Fällen materielle Probleme bei Aufgabenstellung oder Tests. Ein weiterer Audit im Juli 2026 schätzte, dass rund 30 Prozent der öffentlichen SWE-bench-Pro-Aufgaben in einem gewissen Sinn „gebrochen" sind. Diese Zahlen sagen zunächst etwas über die Qualität der verwendeten Prüfverfahren aus – nicht direkt über die generelle Qualität von KI-generiertem Code. Sie zeigen aber, wie vorsichtig man mit vermeintlich objektiven Kennzahlen umgehen sollte, die aus solchen Benchmarks abgeleitet werden.
Sechs Formen technischer Schuld, die aktiv beobachtet werden sollten
Statt einer einzelnen Kennzahl hilft ein differenzierteres Bild mit sechs Schuldarten samt Frühsignalen und Gegenmaßnahmen:
- Code Debt – Duplikate und Code-Smells häufen sich; Gegenmittel sind Linter und ein festes Refactoring-Budget.
- Test Debt – es existieren vor allem Happy-Path-Tests, die den Normalfall abdecken, aber Fehlerfälle auslassen; eine unabhängige Teststrategie wirkt dem entgegen.
- Architecture Debt – Strukturentscheidungen wachsen unkoordiniert; regelmäßige Architekturprüfungen wirken früh dagegen.
- Dependency Debt – erfundene oder unnötige Pakete schleichen sich ein; eine Allowlist und eine Software-Stückliste (SBOM) schaffen Kontrolle.
- Knowledge Debt – niemand im Team versteht mehr genau, warum eine Änderung gemacht wurde; ein Explain-back-Gespräch oder eine kurze Architekturentscheidungs-Notiz schließt die Lücke.
- Operations Debt – es fehlen Runbooks für den Ernstfall; feste Service-Level-Ziele und Monitoring beugen dem vor.
Wissenslücke statt Softwarefehler: das Konzept der Comprehension Debt
Ein besonders unterschätztes Risiko ist die sogenannte Comprehension- oder Epistemic Debt: Die Software funktioniert und existiert, aber die zugrunde liegenden Annahmen, Gründe und Wirkzusammenhänge sind im Team nicht mehr präsent. Sichtbar wird dieses Problem oft erst spät – bei einem Störfall, einem Audit oder einem Wechsel des Anbieters oder Dienstleisters, wenn plötzlich niemand mehr erklären kann, warum eine bestimmte Lösung so und nicht anders aufgebaut wurde.
Ein verbreiteter Trugschluss: Tests vom selben Agenten als Beleg für Qualität
Ein häufiger Denkfehler lautet: Wenn der Agent auch die Tests geschrieben hat, hat er sich damit unabhängig selbst geprüft. Das ist so nicht richtig. Implementierung und Tests, die vom selben Agenten in derselben Sitzung entstehen, können dieselbe falsche Annahme teilen – ein Test bestätigt dann lediglich, dass der Code das tut, was der Agent für richtig hielt, nicht, dass es tatsächlich das Richtige ist. Eine unabhängige Prüfung, sei es durch einen Menschen oder einen anders instruierten zweiten Agenten, bleibt deshalb ein wichtiger zusätzlicher Schritt.