Качество кода в разработке игр больше не является вопросом, связанным только с внешним видом кода или предпочтениями разработчиков. Согласно презентации, которую JetBrains повторно опубликовала после мероприятия Game Development Day 2026, качество включает шесть взаимосвязанных аспектов: корректность результатов, производительность, стабильность, безопасность, сопровождаемость и повторное использование.
Эти аспекты особенно важны для игр, срок поддержки которых может составлять от 10 до 12 лет. Медленный или нестабильный код остаётся не только внутренней проблемой команды разработки, но может проявляться для игроков в виде длительного времени загрузки, сбоев, уязвимостей безопасности, отрицательных отзывов и возвратов средств.
Искусственный интеллект ускоряет разработку и увеличивает объём кода
В материале говорится, что жёсткие сроки побуждают многие команды использовать искусственный интеллект для помощи в программировании. Согласно Unity Game Developer Report 2026, 95% разработчиков Unity используют искусственный интеллект в своей работе для содействия процессу программирования.
Это позволяет создавать прототипы и испытывать новые механики за несколько дней вместо месяцев, а также сокращает время, затрачиваемое на повторяющиеся задачи. Однако такая скорость может означать создание 10 тысяч строк в то время, когда разработчик написал бы лишь несколько сотен, что расширяет область проблем, требующих проверки.
JetBrains приводит исследование CodeRabbit, согласно которому код, сгенерированный искусственным интеллектом, в целом не обязательно хуже человеческого кода, но может давать сбои иным образом. Согласно исследованию, он порождал логические проблемы и ошибки в 1,7 раза чаще, а также вызывал дополнительные опасения в отношении сопровождаемости и безопасности. В материале подчёркивается, что результаты подобных исследований, включая данные поставщиков инструментов искусственного интеллекта, требуют критической проверки.
Что даёт статический анализ?
В презентации предлагается использовать статический анализ в качестве базового уровня проверки кода до его интеграции. Он способен охватывать проверки корректности, границы покрытия тестами, производительность, безопасность памяти и ресурсов, утечки ресурсов, исключения, устаревшие зависимости и анализ потоков для выявления более сложных проблем.
Он также помогает обнаруживать программные запахи, сложность, дублирование кода и соблюдение внутренних стандартов команды. Эти возможности особенно важны для кода, сгенерированного автоматически, поскольку, как говорится в материале, искусственный интеллект склонен создавать дублирование и в меньшей степени склонен выполнять рефакторинг.
Главное преимущество статического анализа — детерминированность: при проверке одного и того же кода инструмент выдаёт одинаковые результаты, и каждый результат можно связать с конкретной проверкой, объясняющей причину проблемы. Кроме того, статический анализ не расходует токены и обычно быстрее и дешевле проверки, полностью основанной на моделях искусственного интеллекта.
Практическая модель: два уровня и цикл проверки
JetBrains не считает статический анализ заменой искусственному интеллекту. Анализ на основе шаблонов не всегда понимает намерение кода или логические связи между файлами и компонентами проекта — это области, в которых искусственный интеллект может быть полезен.
Предлагаемая модель начинается с написания кода — разработчиком или инструментом искусственного интеллекта, — после чего статический анализ запускается в рамках конвейера непрерывной интеграции. Некоторые результаты можно обрабатывать автоматически с помощью быстрых исправлений, а существующие проблемы помещать в базовую линию, чтобы они не препятствовали новым изменениям. Затем искусственный интеллект обрабатывает логические проблемы или задачи рефакторинга, после чего код снова проходит статический анализ для проверки соответствия стандартам качества и безопасности перед интеграцией.
В материале упоминаются два исследования. Одно из них указывает на сокращение использования токенов на 72–92% при объединении статического анализа с вызовами больших языковых моделей, а другое обнаружило возможность сократить количество уязвимостей в коде, сгенерированном языковой моделью, до 33% до его попадания в основную ветку.
Что практически меняется для команд?
Практический смысл заключается не в добавлении длительного этапа проверки, а в распределении работы между инструментами, у каждого из которых есть более чёткая функция. Размещение запросов на слияние в Qodana позволяет проверять только изменённые файлы; согласно материалу, такая проверка занимает примерно одну-две минуты. JetBrains также демонстрирует функцию Hooks в Rider, при использовании которой операции форматирования кода и проверки проблем вызываются с каждым фрагментом кода, сгенерированным агентом, а затем результат возвращается агенту для исправления в соответствии со стандартами команды.
Этот подход по-прежнему требует участия человека в настройке стандартов качества, постоянной проверки конвейеров разработки и независимой верификации исследований и результатов. Однако он предлагает ясное правило: увеличение скорости генерации кода не отменяет необходимости измерять его качество, а делает систематическую проверку ещё более важной.