Codeflash-Analyse: 118 Performance-Bugs in zwei von Claude Code verfassten PRs gefunden

Leistungsanalyse von KI-generiertem Code

Codeflash nutzte ihr eigenes Optimierungstool, um zwei Pull Requests zu analysieren, die mit Claude Code geschrieben wurden. Die analysierten Funktionen waren Java-Sprachunterstützung (52.000 Zeilen über Parser, Kontextextraktoren, Instrumentierung, Testläufer, Assertion-Transformatoren) und React-Framework-Unterstützung (24.000 Zeilen zur Komponentenerkennung, Profilerstellung, Benchmarking und Code-Ersetzung).

Wichtige Erkenntnisse

Allein in diesen beiden PRs identifizierte Codeflash 118 Funktionen, die deutlich schlechter als nötig abschnitten. Dies waren keine Randfälle – es handelte sich um Funktionen im Hot Path ihres Optimierers, die bei jedem Optimierungsjob für jeden Nutzer liefen.

Muster der Ineffizienz

• Katastrophal ineffiziente Algorithmen: Eine Typenextraktionsfunktion im Java-Kontextmodul war 446-mal langsamer als nötig, implementiert mit naivem String-Scanning anstatt baumbasierter Extraktion. Eine Helferfunktion zur Funktionssuche war aus ähnlichen Gründen 74-mal langsamer.
• Redundante Berechnungen: Funktionen analysierten bereits geparste Daten erneut, durchliefen bereits traversierte Bäume erneut, bauten Strings Zeichen für Zeichen wieder auf. Ein Assertion-Target-Call-Builder war 19-mal langsamer, weil er bei jedem Aufruf Byte-Konvertierungen neu berechnete statt zu cachen. Ein Import-Einfügungs-Tool im React-PR war aufgrund redundanter Baumtraversierungen 36-mal langsamer.
• Fehlende Zwischenspeicherung: Funktionen, die wiederholt mit denselben Eingaben aufgerufen wurden, berechneten Ergebnisse jedes Mal von Grund auf neu. Ein Typdefinitionsextraktor im React-PR war ohne Memoisierung von Zwischenergebnissen 16-mal langsamer, und ein Export-Checker aus demselben Grund 9-mal langsamer.
• Suboptimale Datenstrukturen: Listen, wo Sets geeigneter wären, lineare Suchen, wo Hash-Lookups funktionieren würden, String-Verkettungen in Schleifen anstatt Joins. Ein Klammern-Balancierungs-Parser war aufgrund ineffizienter Datenstrukturauswahl 3-mal langsamer.

Konkretes Beispiel: 19-fache Leistungssteigerung

Claude Code schrieb diese Funktion zur Konvertierung von Byte-Offsets in Zeichenpositionen:

# Called for every AST node found in the file
start_char = len(content_bytes[:start_byte].decode("utf8"))
end_char = len(content_bytes[:end_byte].decode("utf8"))

Codeflash ersetzte sie durch:

# Build a lookup table once, then binary search for every node
from bisect import bisect_right
cum_bytes = [0]
for ch in source.decode("utf8"):
    cum_bytes.append(cum_bytes[-1] + len(ch.encode("utf8")))
start_char = bisect_right(cum_bytes, start_byte) - 1
end_char = bisect_right(cum_bytes, end_byte) - 1

Der ursprüngliche Code dekodiert bei jedem Aufruf das gesamte Byte-Präfix vom Dateianfang – O(n) pro Lookup. Bei einer Datei mit Hunderten von AST-Knoten bedeutet dies, dieselben Bytes hunderte Male neu zu dekodieren. Die optimierte Version baut einmal eine Lookup-Tabelle auf und nutzt binäre Suche – O(n) einmal, dann O(log n) pro Lookup.

Der Artikel betont, dass es nicht darum geht, ob KI-Coding-Agenten genutzt werden sollten (sie empfehlen deren Nutzung), sondern was mit dem Code danach passiert. Diese Leistungsprobleme stellen eine neue Kategorie von technischer Schuld dar, die KI-Agenten systematisch einführen, indem sie sich auf Korrektheit und Lesbarkeit konzentrieren statt auf Leistungsoptimierung.