Как сгенерированный код проходит ревью, мержится с зелёными тестами - и превращается в ночной инцидент
Tech Lead и преподаватель OTUS Сергей Прощаев разобрал восемь антипаттернов работы с AI-ассистентами кода, которые индустрия пока не научилась ловить на этапе ревью. Проблема не в инструменте. Проблема в том, что команды не перестроили процесс под него.
Цифры, которые объясняют масштаб
84% разработчиков уже используют или планируют использовать AI-инструменты - это данные масштабного опроса сообщества за 2025 год. Рост по сравнению с предыдущим годом составил восемь процентных пунктов. Но 46% из той же выборки признаются: они не доверяют точности AI-вывода. А 45% говорят, что отлаживать сгенерированный код дольше, чем написать самому. Эквадор - Германия прямая трансляция
Анализ 470 открытых pull request'ов - 320 с участием AI и 150 человеческих - показал: в AI-коде примерно в 1,7 раза больше проблем. Ошибки логики встречаются на 75% чаще. При этом количество PR на разработчика выросло на 20%, а инцидентов на PR - уже на 23,5%. Change failure rate прибавил около 30%. Больше кода быстрее. И больше поломок быстрее. AI не разбирает, хорошие у вас практики или плохие, - он масштабирует те, что есть.
Automation bias: «AI писал - значит, нормально»
Первый и, пожалуй, самый коварный антипаттерн - когда PR с пометкой AI-assisted ревьюится быстрее человеческого. Ревьюер скользит по diff'у, видит аккуратные отступы и названия переменных по гайдлайну - и ставит апрув за пять минут. Срабатывает automation bias: аккуратный синтаксис подсознательно считывается как «безопасно».
Это ловушка. Модель оптимизирует под «выглядит правдоподобно», а не под «корректно в вашем контексте». Слабый контроль доступа, ленивая валидация, неочевидная работа с секретами - всё это прячется за ровными отступами. Прощаев предлагает жёсткое командное правило: AI-assisted PR ревьюится не быстрее, а внимательнее человеческого. Особенно в трёх местах - бизнес-логика, работа с данными, безопасность. И отдельно проговаривается на онбординге: ответственность несёт тот, кто открыл PR, а не модель. «AI написал» - не аргумент на разборе инцидента.
Галлюцинированные зависимости: атака через несуществующий пакет
Второй антипаттерн - из разряда тех, что одновременно технические и про безопасность. Модели выдумывают имена пакетов. Около 20% сгенерированных фрагментов кода содержат хотя бы один несуществующий пакет, и больше 58% таких имён повторяются от запроса к запросу. Раз имена предсказуемы - их можно занять заранее. Атакующий регистрирует пакет с галлюцинированным именем и кладёт туда payload. Этот вектор получил название slopsquatting.
Реальный пример: есть легитимный плагин eslint-plugin-unused-imports. Модели стабильно галлюцинировали имя unused-imports - и кто-то его занял. Вредоносный пакет собирал около 233 загрузок в неделю даже после того, как реестр пометил его как security-hold. Разброс по моделям большой: open source галлюцинируют пакеты в среднем в 21,7% случаев, коммерческие - около 5,2%, отдельные конфигурации переваливали за 33%. «У нас хорошая модель» не спасает. Спасает процесс.
- Пиннинг в lockfile и проверка хешей пакетов в CI/CD - обязательны
- AI-агентам нельзя ставить зависимости без человеческого ревью или allowlist-гейта
- Каждый новый пакет от AI проверяется по совокупности сигналов: подписи, verified-publisher, история версий, число загрузок
- SBOM для любого кода, написанного с участием AI
Правильная рамка для работы с инструментом
Прощаев формулирует это коротко: AI-ассистент - не джун, которого отправляют писать код и потом «просто проверяют». Это очень быстрый стажёр с доступом ко всему на чтение и полным отсутствием понимания вашего продакшена, истории инцидентов и модели угроз. Именно так и надо к нему относиться - с соответствующим уровнем надзора. Отключать инструмент бессмысленно. Но и делегировать ему ответственность - опасно. Команды, которые это поняли и перестроили процесс, уже получают выгоду без ночных алертов. Остальные пока платят за скорость инцидентами.
