Vibe coding нарушил своё обещание

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

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

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

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

Ошибочный диагноз

Самое частое объяснение, которое я вижу, винит модель. ИИ ещё недостаточно умён. Он галлюцинирует. Он выбирает не те библиотеки. Он пишет код, который старший инженер поймал бы и переписал.

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

Я в это не верю. И не верю потому, что режим отказа, который я вижу снова и снова, вообще не связан с качеством кода.

Microsoft сообщила на отчётном звонке за 2025 год, что примерно 46% всего кода, который коммитят активные пользователи GitHub Copilot, теперь сгенерировано ИИ. Примерно тогда же компания Veracode, занимающаяся безопасностью приложений, опубликовала исследование: сгенерированный ИИ код вносил уязвимости примерно в 45% протестированных образцов. Эти цифры станут хуже, прежде чем станут лучше, и более умная модель их не исправит.

Проблема не в модели. Проблема в процессе.

Чего на самом деле не хватает

Проведите меня по тому, как строится приложение на vibe coding, и скажите, в какой момент принимается архитектурное решение.

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

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

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

Это не провал интеллекта. Это провал определения. И никакое количество дополнительного интеллекта, приложенного к неопределённой задаче, не даст определённого результата. Оно даст лишь более убедительную версию тех же лесов.

Три решения, которые так и не были приняты

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

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

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

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

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

У проблемы 70% теперь есть имя

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

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

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

Строители в сообществе Lovable дали этому имя — проблема 70%. Вы добираетесь до чего-то, что кажется почти готовым, и затем прогресс останавливается. Каждое исправление ломает что-то ещё. Оставшаяся работа — не та, через которую можно пропромптить путь, потому что вас блокирует не отсутствующий код. Это отсутствующее решение, принятое молча, несколько сотен генераций назад.

Грязный секрет этой категории в том, что легкой частью были первые 90%. Следующие 9% — заставить это действительно работать больше чем для одного пользователя, больше чем на одном устройстве, в условиях, которых вы не предвидели, — сложнее, чем первые 90% вместе. А последний 1%, часть, которая отличает работающее приложение от хрупкого, — та, что требует, чтобы вы знали, что строите, до того как начали.

Правило, которое ИИ не изменил

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

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

ИИ не изменил это правило. ИИ сделал его важнее, а не менее важным.

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

Она же — часть, которую пропустило текущее поколение инструментов.

Куда это действительно ведёт

Я не думаю, что ответ — замедлиться. Я не думаю, что ответ — вернуться к написанию всего вручную. Скачок был настоящим, и скачок остаётся.

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

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

Что почитать дальше

Что пришло на замену: разработка по спецификации. Как сейчас соотносятся инструменты: лучшие ИИ-конструкторы приложений в 2026 году.

Часто задаваемые вопросы

Что значит «vibe coding»? Vibe coding — это написание софта путём описания того, что вы хотите, обычным языком и принятия того, что генерирует ИИ, без указания архитектуры, модели данных или контрактов под ними. Андрей Карпатый ввёл термин в начале 2025 года. Он описывает рабочий процесс, а не категорию инструментов — заниматься vibe coding можно почти в любом ИИ-конструкторе.

Почему приложения на vibe coding ломаются в продакшене? Потому что отказ структурный, а не проблема качества кода. Цикл генерации никогда не производит схему, определённый набор корректных состояний или контракт между фронтендом и бэкендом. Приложение работает на том пути, на котором его демонстрировали, и рассыпается вне него. Более умная модель, приложенная к неопределённой задаче, всё равно даёт неопределённый результат.

Что такое проблема 70%? Это шаблон, при котором приложение, собранное ИИ, доходит примерно до 70% готовности и перестаёт продвигаться: каждое исправление ломает что-то ещё, и никакое количество дополнительных промптов не закрывает разрыв. Блокирующим фактором обычно оказывается архитектурное решение, принятое неявно, сотнями генераций ранее, которое больше нельзя изменить без переписывания.

Менее ли безопасен код, сгенерированный ИИ? Текущие данные говорят, что он требует проверки. Исследование Veracode обнаружило, что сгенерированный ИИ код вносил уязвимости примерно в 45% протестированных образцов — в момент, когда Microsoft сообщила, что около 46% кода, коммитимого активными пользователями GitHub Copilot, было сгенерировано ИИ. Объём растёт быстрее, чем верификация.

Значит ли это, что ИИ-конструкторами приложений не стоит пользоваться? Нет. Для прототипов, демо и внутренних инструментов они по-настоящему превосходны, и скорость реальна. Аргумент здесь более узкий: работающий экран — это не работающая система, и инструменты, которые пропускают фазу определения, не могут произвести второе, каким бы хорошим ни стала модель.