Анализ Codeflash: 118 проблем с производительностью обнаружено в двух Pull Request'ах, написанных с помощью Claude Code

Анализ производительности кода, сгенерированного ИИ

Codeflash использовал собственный инструмент оптимизации для анализа двух пул-реквестов, написанных с помощью Claude Code. Анализировались функции поддержки языка Java (52 000 строк в парсерах, извлекателях контекста, инструментах инструментирования, тестовых раннерах, преобразователях утверждений) и поддержки фреймворка React (24 000 строк, охватывающих обнаружение компонентов, профилирование, бенчмаркинг и замену кода).

Ключевые выводы

Только в этих двух пул-реквестах Codeflash выявил 118 функций, работающих значительно хуже, чем необходимо. Это не были редкие случаи — это были функции на критическом пути их оптимизатора, выполняемые при каждой задаче оптимизации для каждого пользователя.

Шаблоны неэффективности

• Катастрофически неэффективные алгоритмы: Функция извлечения типов в модуле контекста Java работала в 446 раз медленнее, чем нужно, будучи реализованной с помощью наивного сканирования строк вместо извлечения на основе tree-sitter. Похожие причины замедляли функцию поиска вспомогательных функций в 74 раза.
• Избыточные вычисления: Функции повторно парсили уже распарсенные данные, повторно обходили уже пройденные деревья, заново собирали строки посимвольно. Построитель вызовов целей утверждений работал в 19 раз медленнее из-за пересчёта преобразований байтов исходного кода при каждом вызове вместо кэширования. Утилита вставки импортов в пул-реквесте React работала в 36 раз медленнее из-за избыточных обходов дерева.
• Отсутствие кэширования: Функции, вызываемые многократно с одинаковыми входными данными, вычисляли результаты с нуля каждый раз. Извлекатель определений типов в пул-реквесте React работал в 16 раз медленнее без мемоизации промежуточных результатов, а проверщик экспортов — в 9 раз медленнее по той же причине.
• Неоптимальные структуры данных: Списки там, где нужны были множества, линейный поиск там, где подошли бы хэш-таблицы, конкатенация строк в циклах вместо объединения. Парсер баланса скобок работал в 3 раза медленнее из-за неэффективного выбора структур данных.

Конкретный пример: улучшение производительности в 19 раз

Claude Code написал эту функцию для преобразования смещений в байтах в позиции символов:

# Вызывается для каждого AST-узла, найденного в файле
start_char = len(content_bytes[:start_byte].decode("utf8"))
end_char = len(content_bytes[:end_byte].decode("utf8"))

Codeflash заменил её на:

# Создаём таблицу поиска один раз, затем используем двоичный поиск для каждого узла
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

Исходный код декодирует весь префикс байтов с начала файла при каждом вызове — O(n) на каждый поиск. Для файла с сотнями AST-узлов это означает повторное декодирование одних и тех же байтов сотни раз. Оптимизированная версия создаёт таблицу поиска один раз и использует двоичный поиск — O(n) один раз, затем O(log n) на каждый поиск.

В статье подчёркивается, что речь не о том, использовать ли ИИ-агентов для программирования (они рекомендуют их использовать), а о том, что происходит с кодом после этого. Эти проблемы с производительностью представляют собой новую категорию технического долга, который ИИ-агенты систематически создают, фокусируясь на корректности и читаемости в ущерб оптимизации производительности.