Разница между проектом, который живёт год, и проектом, который рассыпается на втором разработчике, почти никогда не в синтаксисе. Она в решениях, принятых до первой строки кода. И именно эти решения AI за вас принять не может.
Метафора, которая объясняет больше, чем обещает
В обсуждениях AI-кодинга всплыло сравнение двух строек. Одна конструкция стоит на треснувших мелких фундаментах. Вторая — на полном основании: требования, архитектура, проектирование данных, безопасность, тестирование. И там, и там может стоять рабочий прототип. Разница видна позже.
Метафора простая, но описывает она точную развилку. Последние пару лет доминирующий нарратив вокруг AI-кодинга был про скорость: описываешь, что хочешь, — через минуты получаешь работающий прототип. Это правда работает и никуда не денется. Проблема в том, что «отлично выглядит в демо» и «переживает встречу с реальными пользователями, реальными данными и реальным масштабом» — две совершенно разные планки.
Проекты, собранные на вайбе, первую планку берут легко. Вторая их ломает. Не потому, что AI написал плохой код, а потому, что никто не принял решений выше по течению: какая модель данных, кому что доступно, что происходит при сбое, как этот компонент будет разговаривать с тем через полгода.
Это не проблема AI. Это инженерная проблема, которую AI сделал проще пропустить.
Почему архитектуры станет больше, а не меньше
Логика «модель теперь пишет код, значит архитектура уже не так важна» перевёрнута. Всё наоборот.
AI — множитель направления. Хорошая архитектура плюс AI дают быстрые и связные системы. Отсутствие архитектуры плюс AI дают быстрые и бессвязные. Модель не знает ограничений вашего продукта, пока человек их не продумал.
Узкое место смещается с набора текста на принятие решений. Когда CRUD-эндпоинт генерируется за секунды, дефицитный навык — не «умеешь ли ты это написать», а «знаешь ли ты, какой код вообще должен существовать». А это системный дизайн и суждение.
Дальше — поддерживаемость. Быстрый MVP теперь может выкатить кто угодно. Выигрывают те, чей MVP не рассыпается при второй фиче, втором разработчике и втором порядке величины по трафику.
И вкус. Если модель предлагает пять правдоподобных реализаций, нужен человек, который понимает, какая подходит форме конкретной системы.
Чем на практике отличаются два подхода
| Что сравниваем | Vibe coding | AI-разработка с архитектурой |
|---|---|---|
| Что делают до генерации | Ничего, сразу промпт | Требования, модель данных, доступы |
| Кто принимает решения | Модель по умолчанию | Человек, модель исполняет |
| Скорость первого прототипа | Максимальная | Ниже на старте |
| Приход второго разработчика | Разбирается вслепую | Видит структуру и границы модулей |
| Поведение при сбоях | Как получилось | Продумано заранее |
| Рост нагрузки | Ломается неожиданно | Есть точки, которые можно расширять |
| Стоимость изменений через полгода | Растёт быстро | Предсказуемая |
Что решить до того, как просить у модели код
- Требования. Что система должна делать и чего делать не должна. Без этого модель просто угадывает — и делает это уверенно.
- Модель данных. Сущности, связи, что считается источником правды. Это дороже всего менять потом.
- Доступы. Кто что видит и кто что может изменить.
- Поведение при отказе. Что показываем пользователю, когда упал внешний сервис, отвалилась база, не пришёл ответ.
- Границы между компонентами. Какие модули о чём знают и через какой интерфейс общаются.
- Стратегия тестирования. Что проверяем автоматически, что руками и на каком уровне.
Это не бюрократия ради галочки. Это список того, о чём модель не догадается, потому что у неё нет контекста вашего продукта. Два первых пункта стоит закрыть до генерации — остальные можно уточнять по ходу, но не «потом когда-нибудь».
Где вайб уместен, а где нет
Прототип для демо, внутренний скрипт для себя, одноразовая утилита, эксперимент, который вы готовы выбросить целиком — здесь скорость выигрывает, и архитектура почти не нужна. Критерий простой: сколько стоит выбросить результат. Если ноль — генерируйте на здоровье.
А вот что кончается плохо: продукт с живыми пользователями, платежами, персональными данными или планами на второй год жизни. Пропущенные решения придётся принимать всё равно. Просто позже и дороже.
Типичные грабли выглядят так:
- сгенерировать структуру проекта целиком и ни разу не спросить себя, почему она именно такая;
- наращивать функциональность поверх модели данных, которую никто не проектировал;
- путать «работает у меня» с «работает»;
- откладывать ревью: код есть, понимания нет.
Что учить, если вы только входите в профессию
Соблазн — броситься осваивать «промпт-грамотность» как новый базовый навык. Она дешёвая: подтянуть её можно в любой момент за пару недель. А вот что плохо докупается позже и не устаревает при смене инструментов — сбор требований, продуманный дизайн, моделирование данных, мышление про безопасность, дисциплина тестирования.
AI-ассистирование вознаграждает тех, кто уже знает, как выглядит «хорошо». Заменить это суждение модель пока не может — и, по-хорошему, не должна.
Водораздел проходит по другой линии
Он между структурой и её отсутствием. Vibe coding и AI-ассистированная разработка могут использовать одну и ту же модель и даже одни и те же промпты. Разница в том, вложил ли человек архитектурную мысль до, во время и после вывода модели.
AI поднимает цену отсутствия инженерной дисциплины.
Планка «выглядит как готовое» падает. Планка «живёт долго» остаётся там, где была, — а то и растёт, потому что ожидания растут вместе с возможностями.
Инструменты те же, возможностей больше. Но только у тех команд, которые делают непарадную работу под капотом. Архитектуру AI не заменяет — она становится тем, что через полгода определяет, актив это или обязательство.
Fluxs
Комментарии (2)
Войдите, чтобы комментировать.