Faros AI в новом отчёте предлагает признать неприятный для инженеров факт: ревью ИИ-кода уже перестало быть внимательным чтением каждой строки в pull request. Чем больше изменений генерируют ассистенты и агентные инструменты, тем важнее проверить, какое решение принято, какие риски оно создаёт и как это подтверждено тестами. Для русскоязычных команд это не повод отменять code review, а сигнал пересобрать его правила до того, как поток машинных диффов превратит ревью в формальный ритуал.
Как сообщает The New Stack, автор материала Анкит Джайн связывает этот сдвиг с выводами нового отчёта Faros AI. Главная мысль проста: спор о том, должны ли разработчики перестать читать весь код вручную, в значительной степени уже решён практикой. Изменения стали слишком объёмными и слишком быстрыми, особенно там, где ИИ генерирует заготовки, тесты, миграции и правки сразу в нескольких файлах. Рецензент физически не успевает одинаково глубоко разобрать каждый дифф — зато всё ещё отвечает за то, что попадёт в продакшен.
В такой ситуации опаснее всего сделать вид, что старый процесс работает без изменений. Если сотрудник открывает большой pull request, бегло смотрит на синтаксис и нажимает approve, команда получает иллюзию контроля. Автоматически сгенерированный код может быть аккуратным на вид, проходить локальные тесты и при этом неверно трактовать бизнес-правило, расширять права доступа, ломать обратную совместимость или создавать дорогой запрос к базе. Проблема не в том, что машина пишет «плохие строки», а в том, что она способна уверенно реализовать плохое решение.
Поэтому ревью ИИ-кода разумно начинать не с диффа, а с намерения. Рецензенту нужны ответ на вопрос «какую проблему решаем», ограничения, затронутые контракты, план отката и признаки успешного результата. Если автор PR не может коротко объяснить выбор подхода, количество сгенерированных строк ситуацию не улучшит. Для ИИ-агента это означает ещё одно требование: его работу нужно представлять как проверяемую гипотезу, а не как готовый результат, которому человек должен довериться из-за скорости появления.
Меняется и ценность автоматизации. Линтер, статический анализатор, тесты, проверка зависимостей и политики безопасности лучше человека ловят повторяемые нарушения: форматирование, известные уязвимости, несогласованные типы, утечки секретов. Человеческое внимание стоит оставлять для мест, где нужна предметная экспертиза: корректности расчётов, границ доступа, влияния на пользователей, архитектурных компромиссов. Это не отказ от инженерной ответственности, а более жёсткое распределение ролей между инструментами и людьми.
Для руководителей разработки вывод тоже вполне прикладной. Метрика «сколько PR прошло ревью» почти ничего не говорит о качестве процесса, если в неё не входят размер и риск изменения, покрытие критичных сценариев, число откатов и инцидентов после релиза. Полезнее требовать от автора или агента структурированное описание: что изменилось, почему выбран именно этот путь, какие альтернативы отброшены и чем подтверждена безопасность. Тогда ревьюер оценивает решение в контексте, а не занимается археологией по сотням строк.
У российских команд есть дополнительная причина не откладывать эту настройку. ИИ-инструменты уже встраиваются в редакторы, CI/CD и внутренние платформы независимо от того, закреплены ли они в регламенте. Запретить их одним сообщением в корпоративном чате обычно проще, чем проконтролировать. Гораздо практичнее определить классы изменений, которые можно принимать с усиленной автоматической проверкой, и классы, где обязательны владелец домена, ручная проверка модели угроз или дополнительное тестирование. Например, правки документации и типовые тесты не равны изменениям платежей, персональных данных или авторизации.
При этом читать код совсем не перестанут. В сложной части системы именно реализация часто раскрывает неочевидную ошибку в замысле. Но роль чтения меняется: оно становится выборочной глубокой проверкой самых рискованных участков, а не попыткой вручную заверить весь машинный выпуск. Следующий спор будет не о том, может ли ИИ писать код, а о том, умеют ли компании фиксировать и проверять решения до того, как они растворятся в красивом диффе. Исходный разбор The New Stack доступен здесь: .
