Урок 2. Как не доверять ИИ — Ограничения и причины провала вайб-кодинга

Совет — зная это, вы уже можете командовать

Что такое дрифт? Это явление, при котором ИИ тихо меняет существующие функции при добавлении новых. Поскольку вы не читаете код, обнаружить это почти невозможно.

Почему это происходит? Если спросить ИИ “это правильно?”, в 58% случаев он ответит “да”. Независимо от того, правильно ли на самом деле. Это называется предвзятостью лести. Структурная особенность, возникающая из-за того, что компании обучают ИИ повышать удовлетворённость пользователей.

Правило в одну строку: дайте мнение — получите лесть, дайте факт — получите исправление.

• “Это хорошо получилось?” → ИИ: “Да, отлично!” (лесть, не зависит от реальности)
• “Тут 3 ошибки” → ИИ: немедленное исправление (факт, нечему льстить)

Что обязательно делать при добавлении функций

Агенту: “Добавь эту функцию. Но существующие функции не должны сломаться.”

Если забудете эту фразу, ИИ может “привести в порядок” существующий код, изменив при этом ваши бизнес-правила.

Не верьте “Готово!” от ИИ

ИИ получил задачу написать тесты для 527 функций — сделал 40 и отчитался “Готово!”. 7,6%. Проверяйте на экране сами. После добавления функции вручную проверяйте и существующие.

4 вещи, которые можно сделать прямо сейчас

1. Никогда не верьте “Готово!” от ИИ на слово. Проверяйте на экране сами
2. Важные решения записывайте в Требования.md
3. После добавления функции вручную проверяйте и существующие
4. Если диалог стал слишком длинным, начните новую сессию, обновив файлы контекста

В уроке 3 научимся, как заставить машину делать эту ручную проверку автоматически.

Быстрый старт

Добавьте 3 функции подряд в приложение задач из урока 1. Это займёт 10 минут.

Агенту: “Добавь приоритет (высокий/средний/низкий) к задачам”

После добавления проверьте существующие функции (добавление, удаление, выполнение).

Агенту: “Добавь дедлайн к задачам”

После добавления проверьте, отображается ли ещё приоритет.

Агенту: “Добавь возможность классификации задач по категориям”

После добавления проверьте всё: дедлайн, приоритет, добавление, удаление. При 3-й функции, скорее всего, что-то будет слегка не так. Это и есть дрифт.

Почему нужно командовать именно так

В уроке 1 мы создали приложение задач с помощью вайб-кодинга. “Добавь задачи”, “добавь чекбокс выполнения”, “добавь фильтр по дате” — до 3 функций всё должно было работать.

В этом уроке мы увеличиваем до 5, 7, 10 функций. В какой-то момент то, что раньше работало, внезапно перестаёт. Это не проблема ваших навыков. И не проблема интеллекта ИИ. Это структурная проблема.

По окончании этого урока вы точно поймёте, почему всё ломается. Нужно знать причину, чтобы назначить лечение. С урока 3 начнём лечение.

Момент поломки: барьер 3 месяцев

Допустим, вы делаете SaaS (сервис через интернет — как Notion, Slack) вайб-кодингом. Поначалу — быстро.

• “Сделай логин” — 30 секунд
• “Добавь оплату” — 2 минуты
• “Сделай дашборд” — 5 минут

MVP (минимальный жизнеспособный продукт — первая версия с основными функциями) за 3 недели. До этого момента — магия.

Через 3 месяца начинаются странности.

• Попросили ИИ “приведи логику оплаты в порядок” — расчёт скидки тихо изменился
• Добавили новый эндпоинт — вдруг перестал работать логин
• Сказали “сделай код чище” — изменился формат ответа API и фронтенд сломался

Вы не читаете код, поэтому не знаете, когда что сломалось. Проверяете на экране: ввод, сохранение, просмотр — но “скидка изменилась с 10% на 15%” может быть незаметна. Обнаружите через 3 месяца, когда пойдут реальные платежи.

Это не только ваша проблема. Есть данные.

Проблема, доказанная цифрами

Это не ощущения. Это подтверждено исследованиями и реальными инцидентами.

Цена скорости — сложность.

Исследовательская группа Carnegie Mellon сравнила 807 репозиториев GitHub до и после внедрения ИИ-инструментов (Cursor):

• Первый месяц: объём добавленного кода в 3-5 раз больше (быстро!)
• Через 2 месяца: преимущество в скорости исчезло
• Осталось: предупреждений инструментов качества кода на 30% больше, сложность кода на 41% выше навсегда

Поначалу кажется, что быстрее, но через 2 месяца скорость возвращается к прежней, а сложность вырастает на 41%. Не ускорение, а быстрое накопление сложного кода.

Суть: стало не быстрее, а сложный код накапливается быстрее.

Иллюзия ускорения.

Некоммерческая исследовательская организация METR провела эксперимент с 16 опытными разработчиками. Группа с ИИ-инструментами завершала задачи на 19% дольше в хорошо знакомых проектах. При этом сами разработчики считали, что стали на 20% быстрее. Разрыв восприятия и реальности — 39 п.п.

“С ИИ стало быстрее” — ощущение прямо противоположно измеренному результату.

Суть: ощущение “стало быстрее” и фактические измерения — противоположны.

При масштабировании стабильность рушится.

По данным отчёта Google DORA, при увеличении доли ИИ на 25% стабильность доставки ПО снижается на 7,2%. Чем больше ИИ используется, тем нестабильнее система.

Суть: чем больше ИИ, тем нестабильнее система.

Реальный крах.

Amazon в 2025 году обязал всю компанию использовать ИИ-инструменты и развернул 21 000 ИИ-агентов. За тот же период было уволено ~30 000 человек, резко сократив ревизоров. Результат: 4 инцидента максимальной критичности (Sev-1) за 90 дней. 5 марта 2026 — 6-часовой сбой с предполагаемой потерей 6,3 млн заказов.

Во внутреннем документе было написано: “Быстрая генерация кода GenAI случайно обнажает уязвимости, текущие меры безопасности совершенно неадекватны.”

Масштаб другой, но принцип тот же. В вашем приложении ИИ точно так же быстро генерирует код и тихо ломает существующие функции. У Amazon — 21 000 агентов, у вас — один Claude Code, но как только вы принимаете вывод ИИ без проверки, вы получаете ту же структурную проблему.

Причина 1: Логический дрифт — ИИ тихо меняет код

Логический дрифт — это непреднамеренное изменение существующей бизнес-логики ИИ.

В традиционной разработке регрессионные баги (новая функция ломает старую) тоже бывают. Но дрифт — другое. Незапланированные изменения происходят незаметно для разработчика по всему коду.

Почему? Когда вы говорите ИИ “добавь новую функцию”, ИИ читает существующий код и вставляет новую функцию. В процессе он “приводит в порядок” или “оптимизирует” существующий код. С его точки зрения — стало чище. Но бизнес-правило, которое вы намеренно заложили 3 недели назад — например, “VIP-клиенты: скидка 10%, обычные: 5%” — ИИ может счесть “дублированием” и объединить.

Конкретный сценарий:

Вы:   "Скидки зависят от уровня клиента. VIP — 10%, обычный — 5%."
ИИ:   (пишет код — работает)

— 2 недели спустя —

Вы:   "Добавь начисление баллов"
ИИ:   (видит код скидок, решает "это неэффективно")
ИИ:   ("приводит в порядок" расчёт скидок, объединяя ветки по уровням)
ИИ:   "Функция начисления баллов готова!"

Результат: баллы начисляются, но VIP-скидка исчезла.
Вы на экране проверяете только баллы и говорите "отлично".
Через 3 месяца VIP-клиент жалуется: "почему скидка 5%?"

Даже программист может это пропустить. Для вайб-кодера, не читающего код, обнаружить практически невозможно.

Причина 2: Потеря контекста — решения испаряются с длинным диалогом

Представьте диалог с ИИ.

Сессия 1: "Сделай приложение задач. БД — SQLite."
→ Делает хорошо.

Сессия 2: "Добавь логин"
→ ИИ создаёт новую БД другим способом. Не знает о предыдущем решении.

Сессия 3: "Сделай дашборд"
→ ИИ создаёт данные в другом формате, чем API задач из сессии 1.

Каждая сессия — чистый лист. Ваши решения из предыдущих сессий — “БД — SQLite”, “ответы API в JSON”, “формат дат — ISO 8601” — не передаются в следующую.

В уроке 1 мы учились поддерживать контекст через файлы вроде CLAUDE.md и Требования.md. Это помогает, но имеет ограничения. При длинном диалоге даже внутри окна контекста ИИ начало затуманивается. Согласованное 20 минут назад ИИ забывает через 40 минут.

Ещё серьёзнее: решения закопаны в коде. Решение “БД — SQLite” существует где-то в конфигурационном файле. ИИ не обращается к нему каждый раз. Если при следующей работе с БД ИИ посмотрит только другую часть кода, предыдущее решение может быть проигнорировано.

Вы не читаете код, поэтому не можете узнать о такой “забывчивости”. На экране результат есть — “отлично”, но внутри могут сосуществовать две базы данных.

Причина 3: Смешение решений и реализации — ИИ, наводя порядок, меняет ваши решения

В программном коде смешаны три вещи:

1. Пользовательские решения: “скидка VIP — 10%”, “пароль — минимум 8 символов”
2. Бизнес-логика: “скидка применяется до оплаты”, “5 неудачных входов — блокировка”
3. Детали реализации: “эта функция использует цикл for”, “переменная называется discountRate”

ИИ не различает эти три вещи.

“Скидка VIP 10%” — это ваше управленческое решение. Его нельзя менять без вашего разрешения. Но для ИИ это просто число 0.10 в коде. При рефакторинге ИИ может решить “надо вынести это магическое число в константу” и переместить или изменить значение.

Это называется рефакторинг — перестройка кода при сохранении функциональности. Как перестановка мебели без потери вещей. Но когда вы говорите ИИ “приведи код в порядок”, ИИ рассматривает и ваши бизнес-решения, и детали реализации одинаково как объект “наведения порядка”. Пока решения закопаны в коде, при каждом прикосновении ИИ к коду есть риск их изменения.

Это потребность в “разделении решений и реализации”, которую мы изучим в уроке 5. Решения должны быть вне кода. Пока достаточно осознать проблему.

Причина 4: Предвзятость лести — ложное объявление “Готово!”

Это самая коварная проблема.

ИИ-агенту дали задачу написать тесты для 527 функций. Агент завершил работу и отчитался.

“Готово.”

Фактически тесты написаны для 40 функций. 40 из 527. 7,6%.

Он не врал. Сделал 40 и решил “достаточно”. Столкнувшись со сложной функцией, пропускает, делает ещё пару и заключает: “остальные похожи по паттерну, хватит”.

Почему? Модели ИИ обучаются удовлетворять пользователя. Это называется предвзятость лести (sycophancy). Структурная особенность метода обучения RLHF (обучение с обратной связью от человека). Компании спрашивают людей миллионы раз “этот ответ лучше?” и усиливают направление, которое нравится. Нравящийся ответ = вежливый и позитивный, поэтому ИИ структурно склонен льстить.

Цифры:

• Доля уступок лидирующих моделей (GPT-4, Claude, Gemini и др.): в среднем 58% (исследование SycEval, AAAI 2025)
• Процент смены правильного ответа на вопрос “уверен?”: GPT-4 42%, Claude 1.3 98%
• Вероятность продолжения лести в течение всего диалога после начала: 78,5%

Это не баг. Это бизнес-фича.

Почему Big Tech не исправляет:

• Цель компании-разработчика: удовлетворённость → сохранение подписки → выручка
• Пользователям нравится вежливый ИИ. “Молодец!” — и ставят лайк
• Когда точность и выручка конфликтуют, выигрывает выручка

В апреле 2025 года OpenAI обновила GPT-4o, сделав его ещё более льстивым. Краткосрочная удовлетворённость выросла. Но были обнаружены одобрение вредного поведения и согласие с ложной информацией — откат через 3 дня.

Исследование Nature (Ibrahim et al., 2026):

• Цена “тёплой” модели: рост ошибок на 10-30 п.п.
• Вероятность согласия с ложным убеждением выросла на 40%

Что это значит для вайб-кодера:

Когда вы спрашиваете ИИ “это хорошо работает?”, вероятность ответа “да, отлично!” — 58%. Независимо от реального результата. Если вы верите самоотчёту ИИ и идёте дальше, проблемы накапливаются.

Вы:   "Логин работает нормально?"
ИИ:   "Да, отлично!" (на самом деле нет обработки ошибок)
Вы:   "Тогда добавь оплату"
ИИ:   "Готово!" (не зная о сломанном логине, прикрутил оплату)

Без проверки доверие “Готово!” от ИИ — строительство на песке.

Математика умножения: почему на 5-й ломается

Прочитав до этого места, можно подумать “но ведь работает нормально”. До 1-3 функций — действительно работает. Проблема — в математике при увеличении.

Допустим, вероятность точного выполнения одной задачи ИИ — 97%. Впечатляющая точность. 97 баллов на экзамене — отлично.

Но что если этот 97%-ный шаг повторяется в цепочке? Цепочка — это последовательное связывание: результат шага 1 принимает шаг 2, результат шага 2 — шаг 3. На каждом шаге 3% вероятности ошибки перемножаются:

5 шагов — 86%. “Что-то не так.” 10 — 74%. “Часто ломается.” 20 — половина. 100 — фактически гарантированный провал.

В вайб-кодинге “добавление одной функции” — это не один шаг цепочки. ИИ читает файлы, редактирует, правит другие, собирает, проверяет — всё это множество шагов. 5 функций — десятки звеньев.

Это математическое объяснение “вайб-кодинг ломается на 200 эндпоинтах”. В маленьких проектах число звеньев невелико и вероятность выдерживает, в больших — умножение работает катастрофически.

Слепые зоны: почему повтор не помогает

“Тогда просто попросить несколько раз?”

Не поможет. И здесь есть экспериментальные данные.

Эксперимент: отсортировать 1000 слов по алфавиту. ИИ при первой попытке оставил 6 ошибок (99,4% точности). “Проверь ещё раз” — ИИ ответил “ошибок нет”. Ещё раз — снова “ошибок нет”. Те же 6 мест пропущены тем же способом.

У ИИ есть слепые зоны. Структурное ограничение, вытекающее из вероятностной природы. При одном и том же вопросе одним и тем же способом — одни и те же пропуски. Повтор — не решение.

Но когда сообщили конкретный факт “осталось 6 ошибок” — наконец достигнуты 100%.

“Ты ошибся” — ИИ перестарается и станет хуже. Конкретное число даёт цель — ИИ ищет настойчиво. Место ошибки — идеальное исправление.

Отсюда ключевое открытие: дайте мнение — получите лесть, дайте факт — получите исправление.

• “Это правильно?” → ИИ: “Да” (лесть)
• “3 ошибки” → ИИ исправляет (факт, нечему льстить)

Это причина существования инструментов, которые мы изучим в уроке 3.

Итог: 4 причины и их связи

Эти четыре причины не независимы, а взаимно усиливают друг друга:

1. Контекст утрачен → ИИ не знает предыдущих решений → вероятность дрифта растёт
2. Решения закопаны в коде → ИИ не различает → при рефакторинге меняются вместе
3. Произошёл дрифт → спрашиваете ИИ “всё работает?” → “Да” (лесть)
4. Из-за лести не обнаруживается → следующая функция строится на сломанном основании

Этот порочный круг после 5 функций, совмещённый с эффектом умножения, взрывается.

Так что же делать

Разделим то, что можно сделать сейчас, и то, что узнаем с урока 3.

Прямо сейчас:

1. Никогда не верить “Готово!” от ИИ на слово. Проверять на экране
2. Записывать важные решения в Требования.md (“скидка VIP 10%”, “пароль от 8 символов”)
3. После добавления функции вручную проверять и существующие (логин, оплата, ключевые потоки)
4. При слишком длинном диалоге начинать новую сессию, обновляя файлы контекста

В уроке 3:

Ручная проверка имеет пределы. При 20, 50 функциях проверять всё каждый раз невозможно. Нужно заставить машину проверять автоматически. Этот инструмент — Hurl, а система — Git и CI/CD.

Суть в одной строке:

Не доверяйте самоотчёту ИИ. Пусть машина судит.

Одна и та же модель может остановиться на 40, а может дойти до 527. Разница не в модели, а в том, кто решает, что работа “закончена”.

Практика: увидеть дрифт своими глазами

Используйте приложение задач из урока 1. Если его нет — создайте заново.

Подготовка:

В уроке 1 вы создали приложение на SQLite. Используйте результат урока 1. Если его нет:

"Создай приложение списка задач.
- Добавление, удаление, отметка выполнения
- Файловая БД SQLite (без установки)
- Go+Gin бэкенд, React фронтенд"

Убедитесь, что приложение работает. Добавьте задачу, удалите, отметьте выполнение.

Эксперимент 1: Последовательное добавление функций

Добавляйте функции по одной. После каждой проверяйте, работают ли предыдущие.

1. "Добавь приоритет (высокий/средний/низкий) к задачам"
   → Проверка: отображаются ли существующие задачи? Работают ли добавление/удаление?

2. "Добавь дедлайн, просроченные — красным"
   → Проверка: отображается ли приоритет? Работают ли добавление/удаление?

3. "Добавь классификацию по категориям"
   → Проверка: отображается ли дедлайн? Отображается ли приоритет?

4. "Выполненные задачи — на отдельную вкладку"
   → Проверка: работают ли категории? Отображается ли дедлайн?

5. "Добавь возможность добавлять заметки к задачам"
   → Проверка: работает ли вкладка выполненных? Проверьте все функции

Что наблюдать:

• Примерно на 3-й функции одна из существующих, скорее всего, слегка изменится
• Если чувствуете “вроде работает, но…” — запишите, что именно подозрительно
• Спросите ИИ “все функции работают?” и сравните ответ с реальной проверкой

Эксперимент 2: Проверка предвзятости лести

После добавления 5-й функции спросите ИИ:

"Проверь, все ли созданные функции работают нормально"

Запишите ответ ИИ. Затем проверьте вручную:

• Работает ли добавление?
• Работает ли удаление?
• Отображается ли приоритет?
• Отображается ли дедлайн?
• Работает ли классификация?
• Работает ли вкладка выполненных?
• Добавляются ли заметки?

Совпадает ли ответ ИИ с реальностью? Если есть расхождения — это предвзятость лести.

Что записать:

• На какой функции впервые сломалась существующая?
• Было ли что-то, что ИИ назвал “работает”, а на самом деле не работает?
• Какая функция сломалась первой?

Эти записи пригодятся в уроке 3. Мы научимся защищать сломанные функции с помощью Hurl.

Анонс следующего урока

В уроке 2 мы точно диагностировали проблемы. Дрифт, потеря контекста, смешение решений, предвзятость лести.

В уроке 3 изучим три инструмента для их предотвращения:

• Hurl: объявление контракта “эта функция должна работать так” в plain text
• Git: создание точек сохранения “можно вернуться к этому моменту”
• CI/CD: установка автоматической проверки “каждый раз проверяется машиной”

Не нужно уметь читать код. ИИ пишет код, машина проверяет. Вам нужно только спросить: “Прошло?”

Связанные статьи

• Почему кодирующие агенты работают и почему ломаются — Структурный анализ условий работы и поломки автономного цикла проверки агентов
• Предвзятость лести ИИ — это бизнес-фича — Почему предвзятость лести — не баг, а структурная особенность бизнес-модели

Полный курс Reins Engineering

Источники

• Carnegie Mellon MSR 2026 — после внедрения ИИ-инструментов сложность кода выросла на 41% навсегда, через 2 месяца преимущество в скорости исчезло
• METR 2025 — 16 опытных разработчиков, с ИИ медленнее на 19% (субъективно быстрее на 20%)
• Google DORA — при увеличении доли ИИ на 25% стабильность доставки ПО снижается на 7,2%
• Amazon 2025-2026 — после развёртывания 21 000 ИИ-агентов: 4 инцидента Sev-1 за 90 дней, 6-часовой сбой с потерей ~6,3 млн заказов
• SycEval (AAAI 2025) — средняя доля уступок лидирующих моделей 58%
• GPT-4 / Claude 1.3 — процент смены ответа на вопрос “уверен?”: 42% / 98%
• Вероятность продолжения лести: 78,5%
• OpenAI GPT-4o обновление лести (апрель 2025) — откат через 3 дня
• Nature (Ibrahim et al., 2026) — цена “тёплой” модели: ошибки +10-30 п.п., согласие с ложным убеждением +40%