Где AI-ревью в Copilot всё ещё проваливается: разбор реальных продакшн-кейсов

Работаю с event-driven пайплайнами, дата-инженерными системами и интеграциями между сервисами. Copilot стоит у меня в продакшен-среде уже не первый месяц, и накопилось достаточно конкретных наблюдений по тому, как он ведёт себя на реальных задачах — хорошо ли делает то, для чего инженеры его покупают.

Что Copilot умеет хорошо. Рутинные задачи, простые автозамены, типовые паттерны кода — здесь он стабильно помогает. Если задача шаблонная и предсказуемая, ускорение реальное. Это базовый уровень, на который можно рассчитывать.

Дальше начинаются проблемы, которые я регулярно вижу на код-ревью моих PR. Первое — слишком длинные комментарии. Вместо конкретного действенного замечания вроде «вот тут SQL-инъекция, пофиксить так-то», получаешь три абзаца общих рассуждений о том, почему вообще важна безопасность. На реальном ревью у разработчика нет времени читать эссе на каждый комментарий.

Второе — отсутствие глобального контекста. Copilot смотрит на файл, в который вставлен diff, но не видит, что это часть большой системы, где есть свои конвенции и установленная архитектура. Когда я добавляю модуль в проект на 50 файлов, Copilot не подскажет «у вас уже есть utility-функция на соседней папке, которая делает то же самое». Дублирование проходит мимо.

Третье — чрезмерный nitpicking форматирования. Половина комментариев AI-ревью — про пустые строки, отступы, именование переменных в стиле «возможно стоит назвать понятнее». Это шум, а не польза. Хороший ревьюер фокусируется на архитектуре и логике; Copilot пока — на запятых. Часть команды на это перестаёт реагировать совсем — фильтрация AI-комментариев становится отдельной задачей в их workflow, и инструмент, который ради этой фильтрации куплен, начинает восприниматься как раздражитель.

Четвёртое — слабые логические выводы. На код, где две функции делают почти одно и то же, человек скажет «давай вынести в общий хелпер». Copilot пропустит дублирование, потому что функции называются по-разному, и для модели они выглядят как разные сущности. Метрики качества здесь у AI заметно проседают.

Пятое — тестирование. Mocking и verification в моих тестах Copilot просто не видит как отдельный класс задач. Вместо проверки поведения он начинает предлагать чисто стилистические правки в asserts. На сложных интеграционных тестах это особенно бросается в глаза.

Шестое — мета-уровень фидбэка. Когда PR разрастается до 30, 300 или 3000 строк, Copilot ведёт себя одинаково: комментирует фрагменты по отдельности, не отмечая, что сам PR стоит разбить на несколько. У хорошего человека-ревьюера первый комментарий на огромном PR обычно «пожалуйста, разделите на части, я не могу нормально это посмотреть»; у Copilot — никогда. Это означает, что качество ревью на больших PR не просто хуже, а структурно ущербно: обзор по фрагментам никогда не заменит обзор всего изменения как единого целого, и AI этого пробела не закрывает.

Самый болезненный кейс. На одном из моих PR была рекурсивная ошибка в event-driven системе с папкой /errors: обработчик ошибки сам вызывал событие, которое в свою очередь триггерило тот же обработчик. Бесконечный цикл, потенциальный downstream-сбой. Copilot прошёл мимо. Любой опытный инженер на ревью увидел бы это в первую секунду — это типичный класс ошибок event-driven систем. AI-ревью его не поймал. Это и есть граница: Copilot работает как автоматический инспектор синтаксиса, без архитектурного понимания того, что система делает.

Главный вывод — AI не заменяет инженерное мышление, а дополняет его. Copilot снимает значительную часть рутинных задач code review: простые опечатки, мелкая стилистика, пропущенные null-проверки. Но архитектурные решения, проверка на дублирование функциональности, ловля редких рекурсивных багов и метаоценка размера и структуры PR — это всё остаётся на человеке. По крайней мере на текущем уровне развития инструмента.