У меня за плечами шесть лет в IT. Я понимаю, как работает команда разработки, знаю, что такое спринт, DoD и зачем нужен бизнес-аналитик. И всё равно не устояла.
Когда появились первые инструменты для вайбкодинга, я сделала то, что делают все: открыла чат, написала «сделай такой продукт, вот референсы» и нажала Enter. ИИ, конечно, что-то сделал. Но это «что-то» не имело никакого отношения к тому, что я хотела. Я разочаровалась и решила, что вайбкодинг — очередная ИИ-истерия, не больше.
Но потом подумала: а что если я делала это неправильно?
Мой трудный путь: или как не надо, а как надо
- Дизайн:
👎 Делать дизайн с курсором
👍 Отдельно есть ии для генерации дизайна Stich или Cloud disign
- Разработка
👎 Делать монолитом, просто промтами
👍 Делать слоистой архитектурой:
- Дизайн
- Логика
- Модель данных
- Документация
👎 Делать без документации -
👍 Делать документы:
- Продуктовая концепция
- Архитектура
- Контракты с опишками
- Ридми и пр. внутренние доки
- Кросс ревью
👎 Верить курсору, не проверять, не вовлекаться в проблему
👍Кросс ревью с chat gpt gemini
- Пайплан
👎 Потокавая разработка - это сложно дорабатывать и поддерживать
👍 Работа по спринтам
- У спрринта есть цели, скойп, DOD
- Делать приемку спринта
Прежде чем начать заново, я составила карту проблем прошлого опыта. Для каждой проблемы — гипотезу, как делать правильно. Это был первый момент, когда я вспомнила, что я бизнес-аналитик, а не просто пользователь чата:
Имитация настоящей команды
Я решила воспроизвести процесс разработки так, как он происходит в реальной жизни — со всеми ролями, артефактами и приёмками.
Сначала — роль продакта. Я проработала бизнес-контекст, сформулировала цели, описала проблемы и ценностное предложение, собрала CJM. Результат — продуктовая концепция.
Затем — роль бизнес-аналитика. Я описала бизнес-логику, все пользовательские сценарии, доменную модель. Это превратилось в набор пользовательских сценариев.
Дальше — синхронизация с архитектором. Какие сервисы нужны, как они взаимодействуют. Артефакт — ADR. Следом — системный аналитик: контракты взаимодействия, системная логика, модель данных.
Итог — системная спека.
И только после всего этого — разработка. Слоистая, как и в жизни: сначала пользовательский слой (UX, UI, фронт), потом архитектурный, логический (бэк) и доменный (модель данных).
Чат с Cursor был моей таск бордой.
Структура папок в Cursor — моя база знаний проекта.
Спринты и приёмка
Я работала по спринтам. Каждый спринт — чёткая цель и критерии готовности. На каждый спринт — приёмка: авторский контроль и тестирование. Никаких «ну и ладно, потом допилю».
Стек
Для дизайнов — Stitch от Google и Figma. Для написания документации и кросс-ревью — ChatGPT. Для разработки — Cursor.
Зачем так заморачиваться?
Можно попросить ИИ написать всё сразу — и он напишет. Многие так и делают. Проблема начинается потом.
Умный вайбкодинг даёт два принципиальных преимущества перед монолитным подходом.
- Управляемость
Когда что-то идёт не так в монолите, вы начинаете фиксить — и в одном месте исправляется, а в другом падает. Вы не понимаете, где именно проблема, потому что всё связано со всем.
Чёткая архитектура и слоистая структура дают вам карту системы. Вы точно знаете, в каком слое копать, что трогать можно, а что — нет. Баг перестаёт быть лотереей и становится задачей с понятным адресом.
- Масштабируемость
Любой живой продукт растёт: новые фичи, новые пользователи, новые требования. Монолит под это не заточен — расширить его, не сломав то, что уже работает, почти невозможно.
Модульная система с чёткими границами между слоями позволяет развивать продукт без страха. Новый модуль добавляется в свой слой и не тянет за собой остальное. Продукт можно растить итерационно — именно так, как и должен работать живой продукт.
Разница между хаотичным и структурированным вайбкодингом — это не разница в сложности процесса. Это разница между продуктом, которым можно управлять, и кодом, который страшно трогать.
Что я поняла
Вайбкодинг работает не тогда, когда вы просто разговариваете с ИИ. Он работает, когда вы знаете, что делаете — и умеете это объяснить. ИИ не заменяет процесс. Он его ускоряет. Но только если процесс есть.
Мой опыт в IT оказался не помехой, а суперсилой. Все те артефакты, которые кажутся «бюрократией» в большой компании, здесь стали моим каркасом. Без них — хаос. С ними — продукт.