Der blinde Fleck bei der Performance: KI-Agenten schreiben langsamen Code

Der Code bestand jeden Test. Der Linter war sauber. Der Type-Checker war zufrieden. Das Code-Review genehmigte ihn. Die Funktion war 446-mal langsamer als nötig.¹

Codeflash, ein Tool zur Code-Performance-Optimierung, analysierte zwei Pull Requests, die vollständig von Claude Code generiert wurden: 76.000 Zeilen über ein Java-Sprachunterstützungsmodul und eine React-Framework-Integration.¹ Sie fanden 118 Funktionen mit erheblichen Performance-Problemen. Die Verlangsamungen reichten von 3x bis 446x. Der schlimmste Fall: eine Typextraktionsfunktion, die bei jedem Aufruf den gesamten AST neu durchsuchte, anstatt die Traversierung zu cachen. Korrektes Verhalten. Katastrophale Performance.

Der Befund ist kein Einzelfall. SWE-fficiency, ein Benchmark mit 498 Optimierungsaufgaben aus Repositories wie NumPy, Pandas und SciPy, ergab, dass die leistungsstärksten LLM-Agenten weniger als 0,15x des Speedups erreichten, den ein erfahrener Entwickler bei denselben Aufgaben erzielte.² Eine separate Studie, die Claude 3.5, OpenAI o1 und Llama 3.2 an 26 High-Performance-Computing-Codes testete, ergab, dass Claude 3.5 einen Speedup von 1,02x bei serieller Optimierung erzielte (praktisch null Verbesserung), während in 30 % der Fälle fehlerhafter Code produziert wurde.³ Codeflashs eigene Analyse von 100.000 Open-Source-Funktionen ergab, dass 90 % der KI-vorgeschlagenen Optimierungen entweder fehlerhaft sind oder keinen messbaren Nutzen bringen, und unter den korrekten lieferten 73 % Verbesserungen unter 5 %.⁴

Performance ist die Dimension, die KI-Coding-Tools nicht sehen. Jedes standardmäßige Qualitäts-Gate (Linter, Type-Checker, Test-Suites, Code-Review) validiert Korrektheit. Keines validiert Effizienz. Das Ergebnis: eine unsichtbare Steuer auf jede Zeile KI-generierten Codes, die jede Prüfung besteht und jedes System verschlechtert, in das sie gelangt.

TL;DR

KI-Agenten schreiben korrekten, aber langsamen Code. Codeflash fand 118 Performance-Probleme in 76.000 Zeilen Claude Code-Output, mit Verlangsamungen von 3x bis 446x.¹ Akademische Benchmarks bestätigen das Muster: LLMs erreichen weniger als 0,15x des Experten-Speedups bei Optimierungsaufgaben.² Die Ursache ist strukturell: Trainingsdaten belohnen Korrektheit, und standardmäßige Qualitäts-Gates messen keine Performance. Ein Durchbruch erfordert Performance-Infrastruktur: Benchmarks neben Unit-Tests, AST-basierte Mustererkennung in Hooks und Profiling als standardmäßigen Workflow-Schritt.

Kernpunkte

Für einzelne Entwickler. Fügen Sie time oder einen Profiler zum Verifikationsschritt nach jeder KI-generierten Funktion in einem Hot Path hinzu. Die 446x-Verlangsamung bestand jeden Test und jeden Linter. Das einzige Gate, das sie erkannt hätte, ist ein Benchmark. Behandeln Sie „es funktioniert” als notwendig, aber nicht hinreichend. Stellen Sie „wie schnell funktioniert es?” als Standard-Folgefrage.

Für Teamleiter. Performance-Regression ist die unsichtbare Form des Good-Enough-Plateaus. KI-generierter Code, der alle funktionalen Tests besteht, erzeugt ein falsches Gefühl der Vollständigkeit. Fügen Sie Performance-Benchmarks neben Unit-Tests in die CI ein. Die Daten von Faros AI zeigen, dass KI-unterstützte Teams 21 % mehr Aufgaben erledigen und gleichzeitig 9 % mehr Bugs generieren.⁵ Performance-Bugs werden in diesen 9 % nicht gezählt, weil sie niemand misst.

Für Platform-Engineers. Bauen Sie das fehlende Gate. Linter prüfen Stil. Type-Checker prüfen Verträge. Test-Suites prüfen Verhalten. Nichts prüft algorithmische Komplexität oder Laufzeiteigenschaften in der Standard-CI-Pipeline. AST-basierte Mustererkennung (Semgrep-Regeln, ast-grep-Patterns oder benutzerdefinierte Hooks) kann die häufigsten Performance-Anti-Patterns erkennen: redundante Traversierungen, fehlende Memoization und unnötige Kopien.

Wie 118 Bugs aussehen

Codeflashs Analyse zweier Claude Code-PRs liefert den detailliertesten öffentlichen Datensatz zu KI-generierten Performance-Problemen.¹ Die beiden PRs umfassten insgesamt 76.000 Zeilen: 52.000 für Java-Sprachunterstützung und 24.000 für React-Framework-Support. Beide waren funktional. Beide bestanden ihre Test-Suites. Beide enthielten Code, der unter realer Last degradieren würde.

Die Ursachen gruppieren sich in vier Kategorien:

Ineffiziente Algorithmen. Die dominierende Kategorie. Eine Funktion, die Byte-Offsets in Zeilenpositionen umrechnet, verwendete O(n)-Scanning statt O(log n)-binärer Suche mit einer vorberechneten Lookup-Tabelle. Der Code war lesbar. Die Variablennamen waren aussagekräftig. Die Logik war korrekt. Die Komplexitätsklasse war falsch.

Redundante Berechnung. Funktionen, die Werte neu parsten, neu traversierten oder neu berechneten, die hätten gecacht werden können. Der Hilfsfunktionsfinder parste bei jedem Aufruf dieselbe Quelldatei erneut. Ein Memoization-Decorator hätte den 74x-Overhead nach dem ersten Aufruf auf null reduziert.

Fehlendes Caching und Memoization. Eng verwandt mit redundanter Berechnung, aber insofern verschieden, als die Daten in einem breiteren Scope verfügbar waren. Der Typdefinitionsextraktor traversierte jedes Mal den vollständigen AST, anstatt beim ersten Zugriff einen Index aufzubauen. Das Muster: Der Agent schreibt jede Funktion isoliert, ohne zu berücksichtigen, wie sie in einer Schleife aufgerufen wird.

Suboptimale Datenstrukturen. Listenscan dort, wo Sets oder Dictionaries O(1)-Lookup bieten würden. Der Export-Checker iterierte durch eine Liste, um Zugehörigkeit zu prüfen. Eine Konvertierung zu einem Set hätte den 9x-Overhead vollständig eliminiert.

Warum Agenten langsamen Code produzieren

Der blinde Fleck bei der Performance ist kein Bug in einem bestimmten Modell. Die Ursache ist strukturell und wirkt auf drei Ebenen: Trainingsdaten, Bewertungskriterien und Workflow-Annahmen.

Trainingsdaten belohnen Lesbarkeit

LLMs lernen aus der Verteilung von Code in ihren Trainingsdaten. Die häufigste Implementierung jedes Algorithmus ist die naive. Tutorial-Code priorisiert Klarheit. Stack-Overflow-Antworten priorisieren Korrektheit. Open-Source-Code enthält performance-optimierte Versionen, aber diese sind den einfachen Implementierungen zahlenmäßig um Größenordnungen unterlegen.

Das Muster geht über Performance hinaus. Stanford stellte fest, dass KI-unterstützte Entwickler in vier von fünf Sicherheitsaufgaben häufiger unsicheren Code schrieben, und dieselben Entwickler eher glaubten, ihr Code sei sicher.⁸ Die Vertrauenslücke gilt gleichermaßen für Performance: Der Code sieht sauber aus, liest sich gut und produziert korrekte Ausgaben, also vertraut der Entwickler ihm. Die SWE-fficiency-Forscher stellten fest, dass Agenten Schwierigkeiten haben, Optimierungsmöglichkeiten zu lokalisieren und über Funktionsgrenzen hinweg über die Ausführung nachzudenken.² LLMs machen kleine, eingabespezifische Änderungen statt algorithmischer Verbesserungen. Wenn nach Optimierung gefragt, greift das Modell zur nächstliegenden korrekten Transformation (einen Cache hinzufügen, eine Funktion inlinen), anstatt den algorithmischen Ansatz zu überdenken. Das Ergebnis sind Mikro-Optimierungen, die auf fundamental ineffiziente Strukturen aufgeschichtet werden.

Kein Bewertungs-Gate misst Performance

Standardmäßige Qualitäts-Gates validieren das, wofür sie konzipiert sind:

Jedes Gate, das die Branche standardisiert hat, operiert auf Korrektheit. Performance-Testing existiert (Profiler, Benchmarking-Frameworks, Lasttesttools), aber es nimmt einen separaten Workflow ein, den die meisten Teams nicht in ihre CI-Pipeline integrieren und den KI-Agenten nie unaufgefordert aufrufen.

Das Verifikationsvakuum, das die 10%-Produktivitätswand erklärt, reicht tiefer als funktionale Korrektheit. Das Vakuum betrifft nicht nur „funktioniert der Code?”, sondern auch „performt der Code?” – und kein Standard-Gate stellt die zweite Frage.

Agenten schreiben Funktionen, keine Systeme

Die tiefste Ursache ist architektonischer Natur. Ein KI-Agent generiert Code eine Funktion, eine Datei, eine Aufgabe nach der anderen. Der Scope jeder Generierung ist die unmittelbare Anforderung. Performance-Probleme entstehen an den Grenzen: wenn eine für Einzelaufrufe geschriebene Funktion in einer Schleife aufgerufen wird, wenn ein für kleine Eingaben geschriebener Parser große Dateien erhält, wenn ein auf Korrektheit geschriebener Lookup bei jeder Anfrage aufgerufen wird.

Der Failure-Mode Tunnel Vision aus der Agenten-Fehler-Taxonomie beschreibt dieses Muster auf funktionaler Ebene: Der Agent perfektioniert eine Komponente, ohne Integrationspunkte zu prüfen. Der blinde Fleck bei der Performance ist Tunnel Vision angewendet auf Laufzeiteigenschaften. Die Funktion ist isoliert perfekt. Das System degradiert, weil die Performance-Eigenschaften der Funktion nie im Kontext evaluiert wurden.

Die unsichtbare Steuer

Der blinde Fleck bei der Performance wäre ein geringfügiges Problem, wenn KI-generierter Code einen kleinen Anteil an Produktionssystemen ausmachen würde. Die aktuellen Zahlen machen ihn zu einem systemischen Risiko.

DX misst KI-generierten Code bei 26,9 % des gemergten Produktionscodes mit steigender Tendenz.⁶ Faros AI (ein DevOps-Analytics-Anbieter) stellte fest, dass KI-unterstützte Teams PRs mergen, die 154 % größer sind als vor der KI-Ära, 21 % mehr Aufgaben erledigen und 9 % mehr Bugs pro Entwickler generieren.⁵ Die 9-%-Zahl zählt funktionale Fehler. Performance-Regressionen fehlen in der Metrik vollständig, weil die meisten Teams keine Performance-Baseline haben, gegen die eine Regression gemessen werden könnte.

Die Zinseszins-Mathematik ist entscheidend. METRs randomisierte kontrollierte Studie ergab, dass erfahrene Entwickler mit KI-Tools 19 % länger brauchten, aber glaubten, die KI beschleunige sie um 20 %.⁹ Wenn die Entwickler selbst die Auswirkungen nicht korrekt einschätzen können, akkumuliert sich Performance-Schuld unbemerkt. Bei 26,9 % gemergtem Code mit potenzieller Performance-Schuld und ohne Performance-Gate in der Organisation wächst die Schuld mit jedem Sprint. Der DORA-Bericht 2025 ergab, dass KI-Adoption mit erhöhter Delivery-Instabilität korreliert, selbst wenn der Durchsatz stieg.⁷ Der Bericht schreibt die Instabilität nicht spezifisch der Performance zu, aber der Mechanismus passt: mehr Code, schneller gemergt, mit Performance-Eigenschaften, die nie gemessen wurden.

52 % der von Codeflash befragten Engineering-Leader berichteten, dass erhöhte KI-Nutzung zu Performance-Problemen in ihren Codebasen führt.⁴ Die Zahl ist selbstberichtet und stammt von einem Anbieter (Codeflash verkauft Performance-Optimierungstools), aber die Richtung stimmt mit jedem unabhängigen Datensatz überein. Mehr KI-generierter Code, gemergt mit Standard-Qualitäts-Gates, produziert Systeme, die korrekt funktionieren und langsam laufen.

Die 10%-Produktivitätswand hat eine Performance-Dimension, die die Originaldaten nicht sichtbar machen. Wenn KI die Code-Generierung um 10 % beschleunigt, der generierte Code aber Performance-Schulden trägt, die Wochen oder Monate später als Produktionsvorfälle auftreten, schrumpft der Netto-Produktivitätsgewinn weiter. Die Wand ist nicht nur „KI macht Entwickler nicht schneller.” Die Wand schließt ein: „KI macht Code langsamer auf Weisen, die niemand misst.”

Wie Erkennung aussieht

Performance-Erkennung für KI-generierten Code erfordert Infrastruktur, die die meisten Organisationen nicht haben. Die Tools existieren. Die Integration nicht.

Benchmark-Gates in CI

Die direkteste Lösung: Benchmarks für kritische Pfade erstellen und den Build bei Regressionen fehlschlagen lassen. Frameworks existieren für jede gängige Sprache: pytest-benchmark für Python, JMH für Java, criterion für Rust, benchmark.js für JavaScript. Die Herausforderung ist nicht das Tooling, sondern die Praxis. Benchmarks erfordern Baselines, und Baselines erfordern, dass jemand den initialen Benchmark schreibt, bevor KI-generierter Code dagegen regressieren kann.

Die minimal umsetzbare Implementierung: Identifizieren Sie die 10–20 Funktionen im Hot Path, schreiben Sie Benchmarks dafür und fügen Sie sie zur CI hinzu. Die 118 Bugs, die Codeflash fand, konzentrierten sich auf Parser und AST-Traversierungsfunktionen: den Rechenkern, nicht den Verbindungscode. Performance-Probleme häufen sich jedes Mal an denselben Stellen.

AST-basierte Mustererkennung

Statische Analyse kann die eklatantesten Muster erkennen, ohne den Code auszuführen. Semgrep und ast-grep unterstützen benutzerdefinierte Regeln, die Folgendes erkennen:

• List Comprehensions oder Schleifen innerhalb anderer Schleifen, bei denen sich die innere Collection nicht ändert (Cache-Kandidat)
• .index()- oder in-Prüfungen gegen Listen, die Sets sein könnten
• Datei-I/O oder Netzwerkaufrufe innerhalb von Schleifen ohne Batching
• Wiederholte Funktionsaufrufe mit denselben Argumenten (Memoization-Kandidat)

Diese Regeln ersetzen kein Profiling. Sie erkennen die Muster, die für die Mehrheit der 118 Bugs verantwortlich sind: redundante Berechnung, fehlendes Caching, falsche Datenstrukturen.

Hook-basierte Performance-Awareness

Für Claude Code-Nutzer kann ein PreToolUse-Hook Performance-Awareness in den Workflow des Agenten injizieren. Der Ansatz ist parallel zum Evidence-Gate-Muster, das für Korrektheit verwendet wird:

check_performance_patterns() {
    local file_path="$1"
    local ext="${file_path##*.}"

    case "$ext" in
        py)
            # Detect nested loops with repeated computation
            if grep -Pn 'for .+ in .+:\n.*for .+ in .+:' "$file_path" 2>/dev/null; then
                echo "WARNING: Nested loops detected in $file_path"
                echo "Verify inner loop does not recompute invariant values."
            fi
            # Detect list membership checks that should be sets
            if grep -n '\bin\b.*\[' "$file_path" 2>/dev/null | grep -v '#'; then
                echo "WARNING: List membership check in $file_path"
                echo "Consider converting to a set for O(1) lookup."
            fi
            ;;
        js|ts)
            # Detect Array.includes or indexOf in loops
            if grep -n '\.includes\|\.indexOf' "$file_path" 2>/dev/null; then
                echo "NOTE: Array search detected in $file_path"
                echo "If called in a loop, consider a Set or Map."
            fi
            ;;
    esac
}

Der Hook ist kein Profiler. Er schärft das Bewusstsein. Das Ziel ist dasselbe wie bei jedem anderen Qualitäts-Gate: das Unsichtbare sichtbar machen, damit der Entwickler (oder der Agent in einer nachfolgenden Iteration) es beheben kann, bevor der Code ausgeliefert wird.

Die fehlende Infrastruktur

Das Muster über alle Datenpunkte hinweg ist dasselbe, das die 10%-Produktivitätswand und die sieben Failure-Modes erklärt: KI verstärkt jede vorhandene Infrastruktur – einschließlich der Abwesenheit von Infrastruktur.

Organisationen mit Performance-Benchmarks in der CI werden KI-generierte Performance-Regressionen genauso erkennen wie menschlich generierte. Organisationen ohne sie werden unsichtbar Performance-Schulden anhäufen. DORAs „Verstärker”-Erkenntnis gilt direkt: KI erzeugt den blinden Fleck bei der Performance nicht. KI skaliert ihn.⁷

Drei Mindestinvestitionen schließen die Lücke:

1. Benchmarks für kritische Pfade erstellen, bevor KI Code um sie herum generiert. Der Benchmark ist die Baseline. Ohne ihn ist keine Regression erkennbar. Identifizieren Sie die 10–20 Funktionen, die den Großteil der Rechenzeit ausmachen, und schreiben Sie zuerst Benchmarks für diese.

2. AST-basiertes Performance-Linting zur CI-Pipeline hinzufügen. Semgrep- oder ast-grep-Regeln, die die vier dominierenden Anti-Patterns erkennen (redundante Berechnung, fehlendes Caching, falsche Datenstrukturen, unnötige Komplexität). Die Regeln sind leichtgewichtig und mit bestehenden Linting-Schritten kombinierbar.

3. Performance-Awareness in Agenten-Workflows injizieren. Für Claude Code: ein Hook, der performance-relevante Muster in geänderten Dateien markiert. Für andere Tools: ein Prompt, der „algorithmische Komplexität verifizieren” als Standardanweisung enthält. Das Ziel ist nicht automatisierte Optimierung, sondern Bewusstsein: die Frage „ist das schnell genug?” in einem Workflow sichtbar machen, der sie derzeit nicht stellt.

Der blinde Fleck ist nicht die KI. Der blinde Fleck ist die Abwesenheit von Performance-Infrastruktur. Jedes standardmäßige Qualitäts-Gate, das die Branche gebaut hat, validiert Korrektheit. Keines validiert Effizienz. Die Lücke existierte vor der KI. Die KI machte sie zu einem 26,9-%-des-Produktionscodes-Problem.

Quellen