Дал трём ИИ-ассистентам один и тот же пул-реквест, который завернули на ревью. Только один нашёл настоящую причину

Ревьюер завернул мой пул-реквест с комментарием «есть проблема с производительностью, подумай ещё» — без деталей. Вместо того чтобы гадать самому, отдал тот же код трём популярным ИИ-ассистентам для разработки с одинаковым промптом «найди проблему с производительностью в этом коде» и сравнил, кто реально нашёл причину, а кто нафантазировал правдоподобное, но неверное объяснение.

Код и условия теста

Функция обработки списка заказов с фильтрацией и агрегацией, порядка 60 строк, на Python. Проблема была реальной: при росте объёма данных функция начинала работать на порядок медленнее из-за одной конкретной операции внутри цикла. Я уже знал правильный ответ (нашёл его сам через час после ревью), поэтому мог объективно оценить, кто из ассистентов пришёл к тому же выводу, а кто — к правдоподобной, но ошибочной версии.

Ассистент 1: Cursor — нашёл симптом, не причину

Указал на вложенный цикл как источник проблемы в целом — верно на уровне «здесь что-то не так», но предложенное решение (вынести часть логики в отдельную функцию) не меняло асимптотическую сложность и не решило бы реальную проблему производительности, если бы я его применил.

Ассистент 2: GitHub Copilot Chat — предложил переписать половину функции без диагноза

Вместо точечного объяснения сразу выдал переписанную версию функции целиком. Переписанный вариант действительно работал быстрее — но не потому, что исправлял именно ту операцию, что тормозила изначально, а потому, что заодно поменял структуру данных на более быструю в принципе. Полезно как результат, бесполезно как диагностика: я так и не понял бы, в чём была конкретная ошибка, если бы не проверял разницу построчно.

Ассистент 3: Claude (через API в редакторе) — указал точную строку и объяснил механизм

Указал конкретную операцию — поиск элемента в списке внутри цикла вместо использования множества — и объяснил, что при росте количества заказов это превращает линейную операцию в квадратичную. Это в точности совпало с причиной, которую я нашёл сам через час ручного профилирования кода.

Спорный тезис: качество диагностики бага не коррелирует с качеством финального кода, который выдаёт ассистент

Ассистент, предложивший наиболее правильно работающий код (Copilot Chat, переписавший функцию целиком), дал наименее полезное объяснение, почему исходный код был медленным. Ассистент с точным диагнозом (Claude) не переписывал код сам, а объяснил механизм, оставив исправление на меня. Это две разные способности — «предложить рабочий код» и «объяснить, почему было плохо» — и они не идут в комплекте автоматически, хотя маркетинг всех подобных инструментов подаёт их как единую функцию «понимает ваш код».

Как использовать ИИ-ассистентов для поиска багов, а не только для автодополнения

  • Если ревью указывает на проблему без деталей — просите ассистента объяснить механизм, а не сразу переписать код: объяснение легче проверить на здравый смысл, чем корректность целиком переписанной функции.
  • Сверяйте предложенное объяснение с фактическим поведением кода на тестовых данных — правдоподобное объяснение и верное объяснение звучат одинаково уверенно.
  • Не полагайтесь на один инструмент для диагностики производительности — как показал тест, разброс в качестве диагноза между тремя популярными ассистентами оказался больше, чем я ожидал.

Полный код функции до и после, а также дословные объяснения всех трёх ассистентов выложил в канале — можно свериться с механизмом квадратичной сложности на конкретном примере.

Что не поместилось в статью

За кадром остался второй тест — та же тройка ассистентов на баге с утечкой памяти, где расклад по качеству диагностики оказался прямо противоположным этому. Этот разбор выложу отдельно в Telegram.