Почему код от AI проходит демо, но ломается на следующем релизе

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

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

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

Позже команда перешла на SCSS-mixins и отдельные пути сборки для каждого бренда. Это помогло поставить границу для кастомизации, но уже после запуска такой переход оказался заметно дороже, чем если бы архитектурную модель выбрали сразу. Главный вывод простой: если изменения можно вносить куда угодно, каждый следующий релиз становится сложнее и дороже.

Что важно дописать в задачу до генерации кода

На старте AI может сгенерировать почти всё: интерфейс, backend и рабочий сценарий. Но опытный инженер просит не только сделать функцию, а ещё описывает, где именно можно менять систему, что должно остаться неизменным и как проверить, что результат не сломался при следующем обновлении.

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

На примере платежей и чатов видно, где кроются риски

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

Отдельный риск — повторные события. Если webhook придёт дважды, платёж может быть зачислен повторно; если сообщение в чате не учитывать как часть общей логики, оно может не дойти до собеседника в соседней реплике. Поэтому в задаче полезно заранее уточнить, что будет при повторе, задержке, рестарте или смене формата, и какие сигналы говорят, что сценарий действительно завершён успешно.