ИИ написал рабочий код для игры — и добавил лишний перебор на каждом кадре
ИИ-агент может корректно выполнить задачу, пройти тесты и всё же выбрать неоптимальный способ обработки данных. С такой ситуацией столкнулся Петер Томан, сооснователь студии PH3, известный в сети под ником DuranteA. Он поручил агенту реализовать проверку последовательности действий для нового игрового достижения.
Функционально решение оказалось правильным: агент реализовал требования и проверил их тестами. Однако при просмотре изменений разработчик обнаружил, что новая логика на каждом кадре симуляции перебирала до 11 000 игровых сущностей. По оценке Томана, ту же задачу можно было решить небольшим расширением уже существующего этапа обработки и временным хранилищем максимум для пяти элементов.
Отдельно взятый участок, вероятно, не привёл бы к заметному падению производительности. Но, по оценке разработчика, он мог потреблять как минимум в сто раз больше процессорного времени, чем необходимо. После короткого объяснения агент смог реализовать более экономичный вариант.
При этом речь не идёт о независимом бенчмарке. В публикации не указаны модель, игра, исходный код и воспроизводимые замеры, а также не описано, как именно агент проверял требования. История важна не точными показателями производительности, а вопросом, который она поднимает: сколько работы выполняет программа, когда выдаёт правильный результат?
Функциональный тест не измеряет стоимость решения
Если тест проверяет выдачу достижения после нужной последовательности действий, успешный результат подтверждает только одно: игра правильно распознала сценарий. Дополнительная проверка может убедиться, что достижение не выдают при неполной последовательности. Но ни один из этих тестов сам по себе не показывает, сколько раз программа перебирала данные и какие ресурсы тратила на проверку.
Поэтому при ревью сгенерированного кода нужно смотреть не только на изменённую функцию. Важно понять, откуда поступают данные, кто уже обработал их ранее, что изменилось с прошлого вызова и можно ли использовать накопленное состояние после загрузки сохранения. Небольшой цикл, запущенный 60 раз в секунду для 5 000 объектов, означает 300 000 посещений объектов в секунду. Это ещё не позволяет вычислить потерю кадров, но показывает, почему место вызова важнее одного лишь размера функции.
Полный перебор не всегда является ошибкой. Для редкой операции он может быть самым простым и надёжным решением. Замена его системой событий тоже требует затрат: нужно обрабатывать повторы, восстанавливать состояние, следить за порядком событий и жизненным циклом объектов. Поэтому хорошее замечание на ревью должно объяснять, почему выбранный подход не подходит в конкретном месте, а не ограничиваться советом «переписать на события».
Коэффициент ускорения не равен ускорению всей игры
Фраза «в сто раз быстрее» описывает только конкретный участок. Если вся обработка обновления занимает 10 миллисекунд, а проверка — 0,1 миллисекунды, ускорение проверки до 0,001 миллисекунды сократит общее время лишь с 10 до 9,901 миллисекунды — примерно на 0,99%. Если же проверка занимала половину исходного времени, эффект был бы почти двукратным.
Поэтому производительность следует оценивать в абсолютных значениях и в контексте нагрузки: на каком устройстве проводился замер, в какой сцене, при каком количестве объектов и сколько раз вызывается функция. При частоте 60 обновлений в секунду между ними проходит около 16,67 миллисекунды, но это не универсальный лимит для отдельного участка: работа может распределяться между потоками, процессором и видеокартой, а частота симуляции — отличаться от частоты вывода изображения.
Одного среднего значения также недостаточно. Профилировщик может показать приемлемое среднее время, скрыв редкие длинные обновления. Для осмысленного сравнения стоит сохранить воспроизводимую сцену, зафиксировать число вызовов и проверить обычную и тяжёлую нагрузку в одинаковых условиях. Тогда вместо предположения о «подозрительном цикле» появится проверяемое утверждение о времени работы при конкретных параметрах.
Оптимизация переносит ответственность за состояние
Если отказаться от полного перебора и хранить промежуточные данные, система действительно может выполнять меньше работы. Но ей придётся поддерживать корректность этой памяти. Например, при достижении за подбор трёх разных предметов нужно учитывать повторные уведомления, загрузку сохранений, восстановление прогресса и правила отката после возвращения к старому состоянию.
Нужно также проверить, не регистрируются ли обработчики событий повторно при перезапуске уровня и сохраняется ли прогресс в рамках одной попытки, кампании или всей игры. Эти вопросы нельзя решить с помощью более быстрого алгоритма или успешной компиляции. Сокращение процессорных затрат иногда оказывается простой частью задачи, а доказательство того, что новая логика ничего не потеряла, требует гораздо большего знания проекта.
Та же проблема влияет на оценку пользы ИИ-агентов. Быстро полученный патч не означает, что команда быстрее выпустила изменение: к времени генерации нужно прибавить ревью, исправления, повторные тесты и разбор неочевидных допущений. Если разработка вручную занимала два часа, а проверка — ещё полчаса, то получасовая генерация с последующим часовым ревью действительно экономит время. Но при двух часах проверки преимущество исчезает.
Исследование METR от 10 июля 2025 года показывает, почему субъективное ощущение ускорения стоит проверять замерами. В нём участвовали 16 опытных разработчиков, работавших в знакомых open-source-проектах, а выборка включала 246 задач. При разрешённом использовании ИИ задачи заняли на 19% больше времени, хотя после эксперимента участники оценивали эффект как ускорение примерно на 20%.
Эти результаты нельзя напрямую переносить на все команды, современные модели или историю PH3: выборка небольшая, а условия ограничены знакомыми проектами и инструментами начала 2025 года. В обновлении от 24 февраля 2026 года METR сообщила, что повторный эксперимент даёт ненадёжный сигнал о текущем влиянии ИИ на производительность, в том числе из-за нежелания всё большего числа разработчиков участвовать в сравнении, где часть задач нужно выполнять без ИИ. Практический вывод остаётся прежним: эффективность агента нужно оценивать по полному циклу — от постановки задачи до принятого и поддерживаемого изменения.
