Всем привет, меня зовут Сергей Прощаев, и в этой статье я расскажу про антипаттерны работы с AI-ассистентом кода — те, из-за которых сгенерированный код спокойно проходит ревью, мёржится с зелёными тестами, а потом превращается в ночной инцидент.

Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E-commerce и преподаю на курсах разработки и архитектуры в OTUS. За последние полтора года я насмотрелся на то, как AI-ассистент из «ускорителя» превращается в источник нового класса багов — не потому что инструмент плохой, а потому что команда не перестроила процесс под него. И знаете, что самое неприятное? Эти баги почти никогда не выглядят как баги на этапе ревью. Код чистый, отступы ровные, переменные названы по гайдлайну. А ломается он там, где живёт настоящий продакшен: на проде, под нагрузкой, на edge-кейсах, которые модель просто не держала в голове.

Ниже — рабочая ситуация, которую вы наверняка узнаете. PR открыт, diff аккуратный, CI зелёный, ревьюер ставит апрув за пять минут, потому что «ну тут же AI писал, оно обычно нормально». Через неделю — алерт. Разберём 8 антипаттернов, которые чаще всего прячутся ровно до этого момента, и на каждый покажу, что делать. Не «избегайте ошибок», а конкретное исправление и практики команд, которые с этим уже разобрались.

Сначала договоримся, почему это вообще проблема

Тут важно не уйти в две крайности. Первая — «AI-кодеры опасны, выключаем». Вторая — «модель пишет код, мы только ревьюим, всё под контролем». Обе нерабочие.

Цифры 2026 года расставляют всё по местам. По Stack Overflow Developer Survey 2025, AI-инструментами пользуется или планирует пользоваться 84% разработчиков (рост с 76% годом ранее) — это уже среда, в которой мы все работаем. Но в той же выборке 46% активно не доверяют точности AI-вывода, а 45% признают, что отладка AI-кода занимает больше времени, чем если бы они написали код сами.

Дальше — уже не на ощущениях, а на разборе реального кода. Отчёт CodeRabbit «State of AI vs Human Code Generation» (декабрь 2025) проанализировал 470 open source pull request'ов — 320 написанных с участием AI и 150 человеческих. В AI-коде примерно в 1,7 раза больше проблем (10,83 на PR против 6,45 у людей) по всем категориям, а ошибки логики и корректности встречаются на 75% чаще.

И эффект двунаправленный. Бенчмарк Cortex «Engineering in the Age of AI: 2026» (50+ инженерных лидеров): pull request'ов на разработчика стало на 20% больше, но инцидентов на pull request — на 23,5%, а change failure rate — примерно на 30%. Больше кода быстрее, больше поломок быстрее. Сами авторы называют AI «неизбирательным усилителем»: он берёт ваши практики, и хорошие, и плохие, и масштабирует их эффект.

Правильная рамка, по-моему, такая: AI-ассистент — это не джун, которого можно отправить писать код и потом «просто проверить». Это очень быстрый стажёр с доступом ко всему на чтение и полным отсутствием понимания вашего продакшена, истории инцидентов и модели угроз. Дальше — про то, где он спотыкается.

Антипаттерн 1. Automation bias: «AI же писал, оно нормально»

Симптом. PR от AI ревьюят быстрее, чем PR от человека. Ревьюер скользит по diff'у, видит привычное оформление и ставит апрув. Появляется фраза-маркер: «ну это AI генерил, там стандартно».

Причина. У этого эффекта есть имя — automation bias, склонность доверять решению автоматической системы сильнее, чем своему суждению. Термин пришёл из авиации и медицины, где операторы переставали перепроверять приборы, и иногда это заканчивалось катастрофой. В разработке триггер тот же: аккуратный синтаксис подсознательно читается как «безопасно». А это ловушка. Опрятный код может прятать слабый контроль доступа, ленивую валидацию, плохую работу с секретами и зависимости, которые никто не собирался тащить в проект. Модель оптимизирует под «выглядит правдоподобно», а не под «корректно в вашем контексте».

Последствия. Помню формулировку из одного разбора, которая мне врезалась: код «почти правильный, но не совсем» — и отлаживать его потом дольше, чем написать с нуля. «Почти» в проде стоит дорого, и обычно платит за него тот, кто дежурит на проде ночью, а не тот, кто принял PR за пять минут.

Исправление. Снять с AI-кода презумпцию невиновности. Я бы сделал простое правило для команды: PR, помеченный как AI-assisted, ревьюится не быстрее, а внимательнее человеческого, особенно в трёх местах — бизнес-логика, работа с данными, безопасность. И отдельный нюанс, который я обычно проговариваю вслух на онбординге: ответственность за PR несёт человек, который его открыл, а не модель. «Это AI написал» — не аргумент на разборе инцидента.

Антипаттерн 2. Галлюцинированные зависимости (slopsquatting)

Это мой любимый антипаттерн в том смысле, что он одновременно технический и про безопасность, и при этом до сих пор недооценён.

Симптом. В сгенерированном коде появляется import или строчка npm install / pip install пакета, которого вы раньше не видели. Название звучит логично — что-то вроде aws-helper-sdk или fastapi-middleware. Разработчик ставит, оно даже ставится.

Причина. Модели выдумывают несуществующие имена пакетов. И это не разовая случайность: около 20% сгенерированных фрагментов кода содержали хотя бы один несуществующий пакет, и больше 58% таких выдуманных имён повторялись от запроса к запросу. Раз имена предсказуемы — их можно занять заранее. Атакующий регистрирует пакет с галлюцинированным именем и кладёт туда payload. Отсюда и термин — slopsquatting.

Последствия. Это уже не теория. Разберу реальный кейс, потому что он показателен. Есть легитимный плагин eslint-plugin-unused-imports. Модели вместо него стабильно галлюцинировали имя unused-imports — и кто-то это имя занял. На начало февраля 2026 года вредоносный пакет всё ещё был доступен и собирал около 233 загрузок в неделю, несмотря на то что npm уже пометил его как security-hold. А самый известный эпизод — когда security-исследователь задокументировал, что Alibaba скопировала рекомендованную AI команду установки с таким фантомным пакетом прямо в свой репозиторий. То есть на эту удочку попадаются не только джуны-одиночки, а крупные команды.

Разброс по моделям, кстати, большой: open source модели галлюцинируют пакеты в среднем в 21,7% случаев, коммерческие — около 5,2%, а отдельные конфигурации переваливали за 33%. Так что «у нас хорошая модель» не спасает, спасает процесс.

Исправление. Здесь есть прямые, проверенные практики, и я их применяю:

Пиннинг в lockfile и проверка хешей пакетов в CI/CD — обязательны. AI-агентам с правами на установку пакетов нельзя ставить зависимости без человеческого ревью или allowlist-гейта.

Каждую новую зависимость, которую предложил AI, проверяем не по дате создания (свежая дата сама по себе ничего не значит — хорошие пакеты тоже выходят каждый день), а по совокупности сигналов: подписи и происхождение через npm audit signatures, verified-publisher, число загрузок, история версий.

SBOM (Software Bill of Materials) для кода, написанного с участием AI.

Простейший внутренний гейт, который мы используем перед добавлением незнакомого пакета:

#!/usr/bin/env bash
# Проверка npm-пакета перед install по совокупности сигналов, а не по одной дате.
# Цель — поймать фантомный/занятый пакет, который мог прийти из галлюцинации AI.
set -euo pipefail

PKG="$1"

# 1. Существует ли пакет вообще
if ! npm view "$PKG" version >/dev/null 2>&1; then
  echo "СТОП: пакета '$PKG' нет в реестре. Возможна галлюцинация AI."
  exit 1
fi

# 2. Происхождение и подписи (provenance/attestations)
npm audit signatures || echo "ВНИМАНИЕ: проблемы с подписями/происхождением — проверьте вручную."

# 3. Контекст для ручной оценки: возраст, сопровождающие, загрузки
npm view "$PKG" time.created maintainers
echo "Сверьте: verified-publisher, число загрузок и историю версий, прежде чем ставить в проект."

Антипаттерн 3. Тесты, которые проверяют, что «не упало», а не поведение

Симптом. Просишь AI «напиши юнит-тесты для этой функции». Получаешь высокий процент покрытия, зелёный прогон, чистый merge. Метрика красивая, на душе спокойно.

Причина. Покрытие меряет, какие строки исполнились, а не какие свойства проверены. И AI промахивается специфически: он особенно охотно генерирует тесты, проверяющие реализацию, а не поведение. Типовые паттерны в AI-тестах: assertion-free tests (ассерты вида «не null» / «не бросило» — тест есть, а утверждения про бизнес-правило нет), overmocking (замокано столько, что проверяется поведение моков, а не код), snapshot abuse (снэпшот принимает текущий вывод за эталон и консервирует баг, если он там уже был). Под всем этим — классическая oracle problem: чтобы проверить, что ответ правильный, нужно знать, каким он должен быть. Этого знания про ваш домен у модели нет, поэтому она подменяет проверку поведения проверкой того, что код «отработал».

Последствия. Зелёное покрытие создаёт ложную уверенность. Команда думает, что код защищён, и снимает с него внимание именно тогда, когда внимание нужнее всего. Баг проезжает в прод не вопреки тестам, а как бы «с их благословения».

Исправление. Я бы предпочёл здесь не гнаться за процентом, а проверять, что тест действительно ловит регрессии. Мой обычный приём — мутационный подход на ключевой логике: ломаешь поведение функции руками и смотришь, покраснел ли хоть один тест. Если после намеренной поломки всё ещё зелено — покрытие декоративное.

Простой пример того, как тест от AI выглядит «покрывающим», но не проверяющим:

# Плохо: тест проходит по ветке, но не проверяет поведение.
def test_calculate_discount_runs():
    result = calculate_discount(price=100, user_tier="gold")
    assert result is not None        # "не упало" — это не проверка

# Лучше: проверяем конкретное бизнес-правило и границу.
def test_gold_tier_gets_15_percent():
    assert calculate_discount(price=100, user_tier="gold") == 85

def test_unknown_tier_has_no_discount():
    assert calculate_discount(price=100, user_tier="unknown") == 100

Разница не в количестве тестов, а в том, что второй вариант сломается, если кто-то (или какая-то модель) поменяет правило скидки. Первый — нет.

Антипаттерн 4. AI там, где цена ошибки выше его проверяемости

Сразу оговорюсь, потому что тут легко уйти в спор. Дело не в том, что модель «одна на всё» — современная модель вполне тянет и SQL, и Java. Дело в том, где вы её применяете и можете ли дёшево проверить результат.

Симптом. AI используют для задач, где ошибку трудно поймать на глаз и дорого пропустить: оптимизация тяжёлого SQL-запроса, конкурентность, работа с деньгами, нетривиальная безопасность, нишевый фреймворк, который модель знает поверхностно. Код выглядит уверенно, ревью проходит, а корректность по-настоящему никто не валидировал — потому что для этого нужна экспертиза, которой у модели нет, а у ревьюера не нашлось времени.

Причина. Модель оптимизирует под правдоподобность ответа, а не под его корректность в вашем контексте. На типовом это совпадает, на сложном и доменно-специфичном — расходится. И чем выше цена ошибки, тем дороже обходится это расхождение.

Последствия. Самые болезненные баги садятся именно сюда: гонки, которые воспроизводятся раз в неделю под нагрузкой; запрос, который кладёт базу на проде, но не на стейдже; тонкая дыра в безопасности, которую видно только при анализе угроз.

Исправление. Сортировать не по принципу «какая модель», а по принципу «насколько дёшево я проверю результат». У меня лично работает простая ментальная развилка: «это типовое и проверяемое за минуту → можно отдать AI; это про производительность, деньги, конкурентность или безопасность → пишу сам или закладываю отдельный, предметный ревью с экспертом». AI в зоне высокой цены ошибки — максимум генератор гипотез, а не источник истины.

Антипаттерн 5. Scope creep и interface drift внутри одной сессии

Симптом. Начинали с правки на 50 строк. Модель по ходу предложила «заодно отрефакторить вот это», потом ещё «слегка поправить интерфейс». Через три итерации diff на 500 строк в 15 файлах, фронт сломан, тесты красные, и непонятно, что именно поехало.

Причина. Модель охотно расширяет задачу — ей «помогает» быть полезной. А разработчик в потоке принимает эти микрорасширения по одному, каждое выглядит безобидно. Это хорошо описанный паттерн: «пока я тут, дай ещё отрефакторю» — и правка на 50 строк превращается в 500 строк по 15 файлам, после чего ничего не работает и невозможно изолировать, что сломалось. Туда же — interface drift: начинаете с чистого контракта API, в середине сессии модель предлагает «небольшое изменение» интерфейса, три изменения спустя фронт сломан и вы потеряли два часа.

Последствия. Разрастается code churn — переписывание только что написанного кода. Исследования GitClear на 211 млн изменённых строк фиксируют, что доля кода, переписанного или откатанного в течение двух недель, почти удвоилась с приходом AI — с 3,1% до 5,7%. А чем больше несвязанных изменений в одном PR, тем хуже он ревьюится и тем легче спрятать в нём настоящий баг.

Исправление. Держать сессию в узких берегах. Я обычно фиксирую перед началом: одна задача — один PR, и явно прошу модель не трогать ничего за пределами scope. Рефакторинг «заодно» — это отдельная задача и отдельный PR. И маленькие диффы — это не вкусовщина, это ревьюабельность.

Антипаттерн 6. Mock-данные, которые дожили до прода

Симптом. В демо всё работает идеально. В проде эндпоинт иногда возвращает странное, потому что внутри остался замоканный ответ или хардкод, который ставился «на время».

Причина. Модели любят мок-данные — с ними код компилируется и демо выглядит отлично. Проблема в том, что мок переживает разработку. По наблюдениям из одного разбора, в сессиях, где мок-данные жили дольше 30 минут, была 84%-я вероятность, что они уедут в прод вместе с фейковыми данными. Сюда же — «ловушка почти готового»: модель сообщает, что фича готова, локальные тесты проходят — а в проде падает, потому что не настроены переменные окружения, обработка ошибок добавлена, но не протестирована, а замоканная зависимость в проде не существует.

Последствия. Самый коварный тип бага: не падает сразу, а тихо отдаёт неверные данные. Такое находят не по алерту, а по жалобе пользователя или по расхождению в отчётах через недели.

Исправление. Запретить мок-данным жить дольше задачи. Линт-правило или grep-гейт в CI на специальные маркеры — но именно на специальные, а не на общий TODO, иначе утонете в ложных срабатываниях (легитимных TODO в любой кодовой базе половина). Договоритесь о выделенных маркерах, которые ставятся только на временные заглушки, например AI-MOCK, TEMP-MOCK, REMOVE-BEFORE-MERGE. И обязательная проверка фичи в окружении, приближенном к проду, а не «у меня локально прошло».

# Пример гейта в CI: блокируем только выделенные маркеры временных заглушек,
# чтобы не ловить легитимные TODO.
- name: Block leftover mock markers
  run: |
    if grep -rnE "AI-MOCK|TEMP-MOCK|REMOVE-BEFORE-MERGE" src/ ; then
      echo "Найдены маркеры временных заглушек. Уберите моки перед мёржем."
      exit 1
    fi

Антипаттерн 7. Context rot: модель в длинной сессии забывает ваши правила

Это, на мой взгляд, самая недооценённая ловушка 2026 года, потому что она появляется не на отдельном PR, а внутри долгой работы с ассистентом.

Симптом. Сессия идёт час-другой. В начале вы дали модели ограничения: версии, контракт API, архитектурные правила. Ближе к концу модель начинает предлагать старые версии контрактов, противоречить решениям, которые сама же приняла двадцать сообщений назад, тащить подход, который вы явно запретили в начале.

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

Последствия. Код перестаёт соответствовать вашим же договорённостям, причём незаметно. Особенно опасно в больших задачах, которые делаются одной длинной сессией: к концу вы получаете решение, которое внутренне рассогласовано с тем, что приняли в начале, и это всплывает уже на ревью или в проде.

Исправление. Не полагаться на память модели как на источник правил. Что работает у меня: ключевые ограничения держать вне диалога — в постоянном файле контекста проекта (CLAUDE.md, .cursorrules и аналоги), который подтягивается в каждую сессию, а не пересказывается голосом. Длинные задачи дробить на короткие сессии с заново зафиксированным контекстом. И периодически явно переспрашивать модель, какие ограничения она сейчас держит, — рассинхрон видно сразу.

Антипаттерн 8. Архитектура, собранная по кускам

Симптом. Каждый отдельный PR выглядит нормально. Каждая функция выглядит нормально. Ревью каждого изменения проходит. А через месяц в сервисе обнаруживается God Service на семь тысяч строк, размытые границы между модулями и дублирующаяся логика в трёх местах.

Причина. LLM оптимизирует локально, а не глобально. Она отвечает на конкретный PR в конкретном контексте и не держит в голове архитектуру системы целиком, ваши bounded context'ы, принятые ранее решения о границах. Каждый шаг локально разумен, а сумма шагов уводит систему в деградацию. И поскольку проблема не видна на уровне отдельного diff'а, обычное ревью её не ловит — оно тоже смотрит локально.

Последствия. Архитектурная деградация, которую дорого разворачивать. Связанность растёт, границы стираются, и в какой-то момент простое изменение начинает задевать пол-системы. Это тот самый технический долг, который копится тихо и предъявляется сразу большим счётом.

Исправление. Архитектурные решения нельзя делегировать на уровень отдельного PR — ни человеку, ни тем более модели. Что помогает: фиксировать значимые решения в ADR (Architecture Decision Records), чтобы у границ был письменный источник истины; держать явные bounded context'ы и проверять PR не только локально, но и на соответствие границам; выносить архитектурное ревью в отдельный регулярный шаг, который смотрит на систему целиком, а не на конкретный diff. AI отлично пишет код внутри заданных границ — но границы должен задавать человек.

Сводка: как поймать каждый антипаттерн на ревью

Чтобы восемь пунктов было удобно держать под рукой во время ревью, собрал их в одну таблицу: по какому признаку узнать и что конкретно проверить.

Таблица 1. Сводка антипаттернов: признак и что проверить:

Как это выглядит как процесс, а не набор советов

Та же логика, но как маршрут: покажу, как ключевые проверки складываются в один путь прохождения AI-кода от генерации до прода. На Рис. 2 — тот же путь, что проходит каждый PR, но с гейтами в тех местах, где обычно и прорывается брак.

Главная мысль этой схемы (несмотря на кажущуюся сложность) простая: ни один гейт сам по себе не спасает, спасает то, что они стоят последовательно. AI-ревью ловит механические вещи — null-риски, пропущенную обработку ошибок, известные уязвимые паттерны, — но AI-ревью должно дополнять человеческое, а не заменять его. Финальный гейт — всегда человек, и он смотрит туда, куда модель смотреть не умеет: бизнес-логика, последствия, модель угроз, границы системы.

Что делают команды, которые с этим уже разобрались

Здесь хочу уйти от абстракций к тому, как отвечают на проблему сильные команды в 2026 году. Вырисовываются три практики, и они мне кажутся самыми здравыми.

Первая — PR-описание с явной ролью AI. Команды добавляют в шаблон PR новые поля: какова была роль модели (полный первый драфт / рефакторинг функции / генерация тест-стабов) и какой промпт использовался. Идея в том, что промпт и роль AI в генерации становятся первоклассными, ревьюабельными артефактами. Ревьюер сразу понимает, насколько внимательно смотреть.

Вторая — «Cautionary Tales» wiki. Это живая база разобранных-и-отклонённых AI-паттернов с объяснением, почему так нельзя. Параллельно ведётся «AI-Prompt Playbook» — живой набор удачных промптов под типовые задачи в вашей кодовой базе. По сути команда формирует свою «ДНК кода» и заодно учит и людей, и инструменты.

Третья — управление через governance, а не через запреты, и тут показателен публичный кейс Amazon начала 2026 года. По материалам Financial Times и CNBC, во внутренней записке топ-менеджмента описывался «тренд инцидентов» с «большим радиусом поражения», связанный с «Gen-AI-ассистированными изменениями», для которых «лучшие практики и предохранители ещё не выработаны»; поводом стал инцидент, когда AI-инструмент Kiro при выполнении задачи удалил и пересоздал окружение.

Важная оговорка: Amazon публично оспорил эту подачу, настаивая, что инцидент был крайне ограниченным, а причина — в неверной конфигурации доступов, а не в самом AI. Спор о причинах оставлю за скобками — показательна реакция: компания ввела «code safety reset», где джуниор- и мидл-инженеры больше не могут пушить AI-ассистированный код без подписи сеньора, а на критичных системах — обязательное ревью в четыре глаза.

При этом, по сообщениям, около 1500 инженеров подписали внутреннюю петицию против самого мандата на инструмент. Для меня вывод такой: governance работает, когда он про процесс и проверку, а не про то, чтобы концентрировать право решать в руках немногих. Мне ближе подход, где гейты автоматизированы и прозрачны для всех, а не превращаются в бутылочное горлышко из людей.

Какой навык на самом деле проверяют эти ошибки

Если собрать все восемь антипаттернов в одну мысль, то проверяют они не знание конкретного инструмента. Они проверяют инженерную зрелость в новой реальности: умение не доверять чистому виду кода, держать ответственность за то, что ты мёржишь, видеть систему целиком за отдельным diff'ом и встраивать проверку туда, где раньше хватало беглого взгляда.

2025-й был годом скорости. Похоже, 2026-й становится годом качества — момент, когда команды смещают фокус с «как быстро мы можем генерировать код» на «насколько мы уверены в коде, который отправляем в прод». И ценность инженера теперь измеряется не тем, как быстро он принимает предложения модели, а тем, насколько хорошо он умеет её перепроверять.

У меня нет позиции «AI-ассистенты — зло». У меня есть позиция «AI-ассистент усиливает и вашу скорость, и вашу неаккуратность одновременно». Какой из множителей победит — зависит не от модели, а от процесса вокруг неё.

Чек-лист ревьюера AI-кода

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

• Проверил незнакомые зависимости по совокупности сигналов: пакет существует, подписи и происхождение в порядке, publisher и история версий не вызывают вопросов.

• Тесты проверяют поведение и границы, а не просто «не упало»; намеренная поломка логики делает хотя бы один тест красным.

• Объём diff'а соответствует задаче; нет незапрошенного рефакторинга и правок интерфейса «заодно».

• В прод-путях не осталось моков, заглушек и хардкода; фича проверена в окружении, близком к проду.

• В длинной сессии модель не растеряла исходные ограничения; ключевые правила вынесены в файл контекста, а не держатся «на памяти».

• Изменение не размывает границы модулей; на значимые архитектурные решения есть ADR.

• Бизнес-логику, работу с данными и безопасность смотрел человек, а не только AI-ревью.

• За PR отвечает человек, который его открыл; «это AI написал» на разборе инцидента не принимается.

Если этот разбор оказался полезным и вы хотите перевести проверку AI-кода из интуиции в системный навык, приходите на открытый урок, где мы разбираем похожие ошибки на реальных PR и собираем рабочий чек-лист ревью под AI-генерацию. А если узнали в каком-то из антипаттернов свою команду — напишите в комментариях, какой из восьми у вас самый болезненный. Подозреваю, что про context rot и архитектуру по кускам будет жарко.

Когда ИИ уже участвует в написании кода, слабое место чаще всего не в самой модели, а в том, как команда формулирует задачу, проверяет результат и фиксирует ограничения. На бесплатных уроках OTUS будем разбирать, как получать от ИИ более предсказуемый результат, применять ИИ-инструменты в разработке и структурировать требования так, чтобы они не превращались в источник скрытых ошибок.

• 22 июня, 20:00. «Продвинутое структурирование промптов: как получать предсказуемый результат». Записаться

• 29 июня, 20:00. «Обзор ИИ-технологий для разработчиков: от идей до рабочих решений». Записаться

• 8 июля, 20:00. «Как писать PRD, ТЗ и user stories с помощью ИИ — быстро, структурно и без мусора». Записаться

Полный список бесплатных уроков июня смотрите в дайджесте.