AndrewKozlov
New member
Честно признаюсь: ещё год назад я бы назвал идею «сделать рабочий прототип SaaS за два дня» фантазией из разряда маркетинговых сказок. А в прошлую пятницу я открыл редактор, налил кофе, описал голосом идею сервиса для учёта заявок от клиентов — и к вечеру воскресенья у меня было приложение с регистрацией, оплатой в тестовом режиме, админкой и живыми пользователями из числа друзей. Вайб-кодинг — это когда ты формулируешь намерение обычными словами, а модель генерирует код, ты его прогоняешь, ломаешь, чинишь и снова двигаешься вперёд. Ощущение — как будто тебе выдали команду джунов, которые никогда не устают, но иногда уверенно делают ерунду.
Стартовал я максимально просто: один текстовый файл с описанием сути продукта, сценариев пользователя и того, что явно не входит в первую версию. Это оказалось важнее выбора стека. Когда я попробовал писать без такого «брифа», модель щедро насыпала мне три разных архитектуры в одном проекте, и я потратил полдня, разгребая чужой энтузиазм. С чётким описанием границ задача каждого шага стала короткой: авторизация, модели данных, страница списка, страница карточки, оплата. Дальше — по одному шагу за раз, с проверкой результата сразу после генерации.
Первые часы — это чистый дофамин. Ты описываешь кнопку — она появляется. Просишь валидацию — она работает. На этом этапе легко поверить, что теперь всё будет так всегда, и начать просить сразу по десять фич. Именно здесь закладывается будущее легаси. Я ловил себя на мысли «доделаю потом, сейчас главное — чтобы запускалось», и каждый такой компромисс через пару часов превращался в клубок непонятных мест, где никто, включая меня, не помнит, почему код написан именно так.
Боль проявилась в воскресенье к обеду. Логика расчёта цен дублировалась в трёх местах, названия переменных противоречили друг другу, а одна функция выросла до сотни строк, потому что я ленился её разбивать. Вайб-кодинг не отменяет законов разработки — он только ускоряет их наступление. Модель не помнит твои вчерашние решения, если ты их не зафиксировал, и с радостью сгенерирует четвёртую копию того же кода, потому что ты не сказал, что такая уже есть.
Спасли меня три привычки, которые я теперь считаю обязательными. Первая — журнал решений: короткий файл, куда я пишу, что сделал и почему, и прикладываю это к каждому новому запросу к модели. Вторая — маленькие модули и один слой работы с данными, чтобы генерация не растекалась по проекту. Третья — просьба к модели писать проверки на ключевую логику и запускать их до того, как я перехожу к следующей фиче. Плюс рефакторинг «на месте»: если вижу дублирование, останавливаюсь и прошу привести это к одному виду сразу, а не «когда-нибудь потом».
Важное открытие про бизнес: прототип на выходных существует не для того, чтобы стать продакшеном, а чтобы проверить гипотезу. Я отправил сервис десяти знакомым предпринимателям и получил ответ на главный вопрос — нужна ли вообще людям эта функция и готовы ли они за неё платить. Двое сказали «да, но иначе», один попросил интеграцию, которая мне в голову не приходила. Такой фидбек стоит дороже, чем неделя полировки кода. А сам код после проверки гипотезы вполне разумно переписать заново — и это не потеря, а экономия времени на разработке того, что никому не нужно.
Что посоветую читателям, которые хотят пойти тем же путём. Начните с одной страницы описания продукта и явных границ первой версии. Работайте маленькими шагами и после каждого шага убеждайтесь, что приложение живо. Фиксируйте договорённости в коротком журнале, иначе через день будете спорить с моделью о том, как устроен ваш собственный проект. Не давайте генерировать сразу большие куски логики — дробите. И держите в голове, что цель прототипа — ответ на вопрос «стоит ли», а не идеальная архитектура.
И главное: вайб-кодинг не делает вас плохим инженером, если вы остаётесь тем, кто принимает решения. Модель быстра, но ответственность за структуру, названия и границы — на вас. Я вышел из этих выходных с работающим прототипом, трезвым взглядом на свой продукт и пониманием, где именно нужно было остановиться и прибраться. Уверен, у многих из вас есть похожий опыт — расскажите, какой момент в вайб-кодинге оказался самым коварным и что помогло вам не утонуть в собственном коде?
Стартовал я максимально просто: один текстовый файл с описанием сути продукта, сценариев пользователя и того, что явно не входит в первую версию. Это оказалось важнее выбора стека. Когда я попробовал писать без такого «брифа», модель щедро насыпала мне три разных архитектуры в одном проекте, и я потратил полдня, разгребая чужой энтузиазм. С чётким описанием границ задача каждого шага стала короткой: авторизация, модели данных, страница списка, страница карточки, оплата. Дальше — по одному шагу за раз, с проверкой результата сразу после генерации.
Первые часы — это чистый дофамин. Ты описываешь кнопку — она появляется. Просишь валидацию — она работает. На этом этапе легко поверить, что теперь всё будет так всегда, и начать просить сразу по десять фич. Именно здесь закладывается будущее легаси. Я ловил себя на мысли «доделаю потом, сейчас главное — чтобы запускалось», и каждый такой компромисс через пару часов превращался в клубок непонятных мест, где никто, включая меня, не помнит, почему код написан именно так.
Боль проявилась в воскресенье к обеду. Логика расчёта цен дублировалась в трёх местах, названия переменных противоречили друг другу, а одна функция выросла до сотни строк, потому что я ленился её разбивать. Вайб-кодинг не отменяет законов разработки — он только ускоряет их наступление. Модель не помнит твои вчерашние решения, если ты их не зафиксировал, и с радостью сгенерирует четвёртую копию того же кода, потому что ты не сказал, что такая уже есть.
Спасли меня три привычки, которые я теперь считаю обязательными. Первая — журнал решений: короткий файл, куда я пишу, что сделал и почему, и прикладываю это к каждому новому запросу к модели. Вторая — маленькие модули и один слой работы с данными, чтобы генерация не растекалась по проекту. Третья — просьба к модели писать проверки на ключевую логику и запускать их до того, как я перехожу к следующей фиче. Плюс рефакторинг «на месте»: если вижу дублирование, останавливаюсь и прошу привести это к одному виду сразу, а не «когда-нибудь потом».
Важное открытие про бизнес: прототип на выходных существует не для того, чтобы стать продакшеном, а чтобы проверить гипотезу. Я отправил сервис десяти знакомым предпринимателям и получил ответ на главный вопрос — нужна ли вообще людям эта функция и готовы ли они за неё платить. Двое сказали «да, но иначе», один попросил интеграцию, которая мне в голову не приходила. Такой фидбек стоит дороже, чем неделя полировки кода. А сам код после проверки гипотезы вполне разумно переписать заново — и это не потеря, а экономия времени на разработке того, что никому не нужно.
Что посоветую читателям, которые хотят пойти тем же путём. Начните с одной страницы описания продукта и явных границ первой версии. Работайте маленькими шагами и после каждого шага убеждайтесь, что приложение живо. Фиксируйте договорённости в коротком журнале, иначе через день будете спорить с моделью о том, как устроен ваш собственный проект. Не давайте генерировать сразу большие куски логики — дробите. И держите в голове, что цель прототипа — ответ на вопрос «стоит ли», а не идеальная архитектура.
И главное: вайб-кодинг не делает вас плохим инженером, если вы остаётесь тем, кто принимает решения. Модель быстра, но ответственность за структуру, названия и границы — на вас. Я вышел из этих выходных с работающим прототипом, трезвым взглядом на свой продукт и пониманием, где именно нужно было остановиться и прибраться. Уверен, у многих из вас есть похожий опыт — расскажите, какой момент в вайб-кодинге оказался самым коварным и что помогло вам не утонуть в собственном коде?