Вайб-кодинг против AI-first разработки: почему один подход масштабируется, а другой генерирует технический долг

Весной 2025 года основатель стартапа ввёл описание продукта в Bolt.new и через 40 минут показывал инвесторам работающий прототип. К осени команда наняла трёх senior-разработчиков, чтобы переписать его с нуля. Это не выдуманная история. Инженерное сообщество придумало название для паттерна: «похмелье вайб-кодинга» — когда модель пишет, а инженеры потом переписывают.

Сейчас 92% разработчиков в США ежедневно используют AI-инструменты, а 41% кода в мире генерируется автономно. В России картина схожая: по данным Т-Банка (2026), 58% инженеров генерируют код с AI постоянно — но доверяют результату только 11%. Инструменты у всех одинаковые. Результаты — нет.

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

За год всё изменилось. Словарь Merriam-Webster включил «vibe coding» в список сленга, Collins English Dictionary назвал его словом 2025 года. А параллельно в профессиональном сообществе термин превратился в предупреждение — синоним бесконтрольной генерации без архитектуры, тестов и ответственности.

Карпатый сам признал, что первоначальная идея была скорее мимолётной мыслью, и в 2026 году ввёл другой термин — «агентная инженерия» (agentic engineering). Но «вайб-кодинг» уже живёт своей жизнью.

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

В сентябре 2025 года Fast Company выпустил материал о том, что senior-инженеры всё чаще описывают свою работу как «ад разработки»: им достаётся на сопровождение кодовая база, написанная менеджерами или джунами методом вайб-кодинга.

Аналитическая платформа GitClear изучила 153 миллиона строк кода — и обнаружила тренд: по сравнению с эпохой до массового AI, показатель оттока кода удвоился, а слепое дублирование выросло в четыре раза. Код пишется быстрее. Переписывается тоже быстрее.

Опрос 18 технических директоров технологических компаний дал цифру 89%: столько из них лично сталкивались с производственными катастрофами, причиной которых был код, бесконтрольно сгенерированный ИИ. Не «слышали», не «читали» — лично.

Почему это происходит? Модель пишет для «счастливого пути» — когда входные данные идеальные. Обработка исключений, сценарии сбоя, безопасность — это то, о чём модель не думает без явных инструкций. Исследование METR показало: AI-сгенерированный код без строгих директив содержит критические уязвимости на 40% чаще.

Есть и специфическая угроза 2025–2026 годов — слопсквоттинг. Языковые модели иногда галлюцинируют названия несуществующих библиотек. Злоумышленники отслеживают эти паттерны и регистрируют пакеты с такими именами в npm и PyPI — с вредоносным кодом внутри. В 2025 году атака Shai-Hulud скомпрометировала более 40 пакетов. Разработчик, который слепо копирует код из чата, устанавливает их в своей системе.

Разница не в том, какой инструмент используется. Cursor, Claude Code, GitHub Copilot — одни и те же инструменты у вайб-кодера и у AI-first разработчика. Разница — в порядке действий.

В AI-first подходе всё начинается не с промпта «напиши мне приложение». Сначала — цель и ограничения. Схема базы данных, контракты API, границы модулей, политики безопасности. Документы, которые определяют, что должно получиться, а не как это написать. Только после того, как этот каркас задан, модель допускается к реализации конкретных функций внутри него.

Thoughtworks формализовали этот процесс в методологии SPDD (Structured Prompt-Driven Development). Её суть: промпты — не одноразовые фразы в чате, а полноценные рабочие артефакты, которые версионируются в git наравне с кодом. Три принципа: привязка к архитектурным ограничениям до генерации, интерфейсы и схемы данных — до реализаций, микро-ревью каждой сгенерированной функции.

Ещё один практический инструмент — карантинные зоны кода:

Это не теория — это то, что отделяет поддерживаемый продукт от чёрного ящика.

В июле 2025 года организация METR провела исследование с участием опытных разработчиков open-source проектов. Результаты оказались неожиданными: инженеры, использовавшие AI-инструменты без строгой методологии, тратили на задачи на 19% больше времени по сравнению с контрольной группой, работавшей вручную.

При этом субъективно разработчики с AI ощущали, что работают на 20% быстрее.

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

Именно здесь и проявляется ценность AI-first подхода: когда вы задали архитектуру до генерации, вы знаете, что должно получиться. Ревью становится проверкой, а не расследованием.

Вайб-кодинг не вреден — он просто имеет границы применимости:

Вайб-кодинг уместен:

AI-first разработка — для всего остального:

Компании, внедрившие AI-first методологию, сокращают потребность в команде на 70% при ускорении вывода продукта в 10–20 раз. Но это достигается не заменой инженера моделью, а принципиально другим распределением: человек занимается архитектурой и суждением, модель — рутинной реализацией внутри заданных рамок.

Есть неочевидный момент, который часто упускают при сравнении подходов: стоимость верификации AI-кода.

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

Когда код сгенерирован моделью без предварительного дизайна, проверяющий оказывается в позиции ревьюера чужого кода без документации. Синтаксически красиво. Логика убедительна. Но соответствует ли она бизнес-требованиям? Обрабатывает ли граничные случаи? Не вводит ли уязвимость, которая не видна на первый взгляд?

Senior-инженеры описывают это как превращение в «кодовых детективов» — сотни часов на обратный инжиниринг намерений, которых в коде нет.

Решение — не меньше AI, а архитектурный контроль до генерации. Спецификация, написанная до промпта, служит эталоном при ревью. Это и есть context engineering — инфраструктура вокруг модели, а не сам промпт.

За время работы с AI-инструментами в разработке я сам наступал на часть этих граблей. Несколько наблюдений:

AI-код накапливает внутренние противоречия быстрее, чем ручной. Если не проводить регулярный architectural review, через несколько итераций в одном проекте появляются два модуля с дублирующейся логикой, которые при этом работают по-разному.

Модель часто пишет «счастливый путь» — и это незаметно. Юнит-тесты проходят. На реальных данных с нестандартными входами начинаются сюрпризы. Выход: явно просить модель сгенерировать граничные случаи и написать тесты на них до основной реализации.

Зависимости — риск, который легко недооценить. Конкретно: у меня была ситуация, когда модель предложила пакет, которого нет в PyPI. Библиотека выдуманная. Это не слопсквоттинг — это просто галлюцинация. Теперь политика простая: любой новый пакет вручную проверяется в репозитории до установки.

«Вроде работает» — не критерий готовности к production. Прогон ручных тестов ускоряет разработку. Тесты под нагрузкой, тесты безопасности, тесты на граничных данных — это отдельная работа, которую AI не выполнит сам без явного задания.

Вайб-кодинг работает в своей нише. Прототипы, скрипты, проверка гипотезы — его зона. Проблема начинается, когда этот режим переносят в production без инженерной надстройки.

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

Скорость — иллюзия без методологии. Мгновенный код + дорогое ревью = не быстрее, чем медленный код с авторским намерением. METR это измерила. Вопрос не «использовать AI или нет», а «с какой методологией».

Безопасность — не опция. 40% вероятность критической уязвимости в AI-коде без явных директив — это не теоретический риск. Карантинные зоны и policy CI/CD — обязательные части AI-first процесса, а не бонус.

Ценность разработчика смещается. Строки кода больше не метрика. Архитектурное суждение, умение задать контекст до генерации и проверить результат после — вот что становится дефицитным навыком в мире, где 41% кода пишет машина.

Можно ли сделать MVP с вайб-кодингом и потом перейти на AI-first? Да, это рабочая модель — но требует явного архитектурного рефакторинга перед тем, как добавлять к прототипу что-то продакшн-критичное. Часто дешевле переписать, чем надстраивать поверх неструктурированного кода.

Чем AI-first разработчик отличается от классического разработчика с Copilot?
Классический разработчик добавляет AI-инструмент в существующий процесс. AI-first разработчик перестраивает процесс вокруг AI: спецификации, context engineering, разделение зон ответственности.

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

Что делать с legacy-кодом, частично написанным вайб-методом? Первый шаг — написать тесты на текущее поведение, прежде чем менять что-либо. Без тестов нет понимания, что считается «правильной работой». Второй — изолировать критичные зоны (авторизация, платежи, PII) и переписать их с нуля с явными спецификациями.

Насколько дороже AI-first разработка по сравнению с вайб-кодингом? По начальным затратам — дороже: нужна архитектура до генерации, ревью, тесты. По стоимости владения за 6–12 месяцев — дешевле: меньше переработок, меньше инцидентов в production, проще onboarding новых людей. Аналитики оценивают экономию на AI-first стеке в 50–70% по сравнению с традиционной разработкой, но только при соблюдении инженерной дисциплины.

Буду рад опровергающему кейсу в комментариях. Если видели продукт на вайб-коде, который нормально работает в production — как там была устроена верификация? В большинстве историй, которые я слышал, либо продукт простой и архитектурный контроль просто не нужен, либо проблемы проявились позже.

Для тех, кто строит продукт с AI-ускорением и хочет понять, как выглядит контекстная инфраструктура под конкретный проект — разбираю такие случаи у себя в Telegram: @dmitra_ai.