Как вайбкодить без боли? 11 выводов, к которым я пришёл
За последние 3 месяца я провел 200 часов за вайбкодингом и хочу поделиться мыслями, которые сэкономят вам нервы и время, если вы тоже решились заняться этим делом. Я буду рассматривать Cursor, но эти правила подойдут и для других аналогов
Как я «докатился» до этого
У меня есть друг, который в последнее время часто переезжал и остро почувствовал, как сложно находить друзей в новых местах. При нынешнем темпе жизни и падении социальной активности адаптация и нетворкинг превратились в настоящий челлендж. Но его велосипед все изменил)
У велосипедистов сейчас мощное комьюнити. Это не просто покатушки — это кофе до заезда, сама поездка, отдых и обсуждение после. Целый ритуал. Бегуны тоже не отстают, плюс у них порог входа еще ниже. Оба варианта — отличный способ провести время с кайфом, завести знакомства и оздоровиться.
Проблема в том, что не всегда понятно, где искать заезды, забеги и мероприятия. Так родилась идея создать место, где легко найти единомышленников для любимого хобби.
После этого все было по классике — анализ рынка, бенчмаркинг, концепт и затем проработка основных флоу. Помимо этого мы накидали роадмап, где думали о том, за счет чего мы сможем выделиться среди остальных cервисов, которые занимаются мероприятиями.
Когда мы закончили с дизайном встал вопрос о том, а как вообще теперь все это реализовать и первой мыслью, естественно, было нанять разработчика, который нам это все запилит. Но бюджет на такие вещи сложно поддается анализу и прогнозу, поэтому мы конкретно застопорились, так как у нас нет понимания того, насколько будет востребован это продукт на рынке и сколько в него нужно вложить, чтобы создать mvp от которого уже можно отталкиваться. Ну и нанимая разработчика на такое дело любая доработка, проверка той или иной гипотезы будет выражаться для тебя в определенной сумме деняк
После долгих размышлений было принято решение попробовать навайбкодить mvp сервиса. Целью было попробовать возможности вайбкодинга ну и, в идеале, создать работающий прототип, который позволит собрать обратную связь и понять, что мы вообще хотим дальше. И тут на горизонте появился он — AI-редактор, который обещал закодить всё за нас.
За следующие 3 месяца я провел в нём достаточно времени, чтобы собрать основные правила, которые помогут вам избежать пустых трат времени и сделать работу эффективнее. Перейдем к ним.
11 инсайтов, которые я вывел
Cursor — это стажер
Представьте Курсор, как стажера, который готов стараться, но которого критически нельзя оставлять наедине со своими мыслями и нужно давать четкое направление что делать, каким образом либо наводить его на эти мысли. Без вашего направления он может, допустим, решить, что для того, чтобы поменять цвет у кнопки Primary он не будет переписывать стиль, а навесит сверху еще парочку, которые затем усложнят ваш код и жизнь
Вы должны знать, что вы хотите
Нельзя просто написать прост «сделай страницу как у Apple по братски, чтоб красиво было». Ну точнее можно, но результат вас неприятно удивит. Чем конкретнее промт — тем меньше итераций до нормального результата. Это как с дизайнером: скажете «сделай что-нибудь красивое» — получите что-нибудь
Начинаем с дизайн системы
Не буду рассказывать про преимущества использования дизайн системы. Это просто нужно сделать, иначе каждая кнопка будет вырисовываться каждый раз заново и ваш проект будет готов тогда, когда ИИ наши рабочие места. Я использовал Ant Design, потому что в ней есть все (или почти все), что вам нужно. Можно также подключить Shadcn — более современный вариант. Или Framework7, если делаете что-то мобильное.
Главное — выберите одну систему и скажите Cursor использовать только её. Пропишите это в rules или просто напоминайте в каждом промте: «Используй компоненты из Ant Design». Иначе он начнет импровизировать, и вы получите адскую мешанину из самописных компонентов, библиотечных и вообще непонятно откуда взявшихся
Сначала план, потом действия
Допустим, стоит задача спроектировать целый сервис, и вы даже не знаете, с какой стороны начать. Прямо так и напишите в промте: «Мне нужно спроектировать сервис, но сначала я хочу, чтобы ты составил детальный план — как это эффективнее и лучше всего сделать, какие нюансы нужно учесть и так далее». Когда получите наброски плана, пробегитесь по оставшимся вопросам, а затем декомпозируйте задачу на части и начинайте. В плане написания промтов нет чего-то универсального, что подойдет к каждому случаю, но вы можете ознакомиться с официальной библиотекой промтов от команды OpenAI и что-то оттуда для себя подчерпнуть
Постановка задач среднего размера и брейншторминг
После того как у вас наметился план, беритесь за дело и задавайте задачи среднего уровня. Например: «Спроектируй главную страницу. На ней должен быть хедер, фильтры, карточки — как в макете». Если на странице будут использованы новые компоненты, обязательно напишите, чтобы Cursor брал их из дизайн-системы (которую вы уже, надеюсь, подключили). Но самое важное — дайте ему поразмышлять. Дополните промт фразами типа: «Пока не пиши код, поразмышляй о том, что я не учел. Какие у тебя еще есть вопросы? Как мое решение сделать более проработанным?». Это работает хорошо. Cursor начинает задавать вопросы, на которые вы сами не подумали: «А как должны вести себя фильтры на мобилке?», «А нужна ли пагинация для карточек?», «А что показывать, если карточек нет?». В общем, продумавыет разные корнерсы
Доработка и постановка маленьких задач. Максимум конкретики
Когда будет готова страница, то вам нужно будет пройтись по каждому блоку и контейнеру, рассказать, что в нем не так и попросить исправить. Нужно будет прям заходить в инспектор кода, скринить оттуда проблемное место и описывать то, что вы хотите сделать, а еще лучше давать скрин макета с правильной версткой. Во время исправлений можно попробовать обматерить ИИ, тогда эффективность вырастает на 4-6%. Не могу заверить, что это так, но по ощущениям работает 😅
Похожие ошибки
Если в процессе написания кода возникает ошибка, которая уже ранее была успешно решена в другом месте проекта, скажите Курсору, чтобы он посмотрел, как он уже решал её до этого. Это значительно сократит время на поиск решения и снизит риск новых ошибок.
В идеале попросите Курсор завести memorybank, где он запишет ошибку и найденное решение — так к ним будет легче возвращаться в будущем.
Пример: у меня в интерфейсе есть форма создания мероприятия и форма редактирования. И там, и там есть инпут с вводом локации, но в одной форме он отрабатывал правильно — при вводе показывал список потенциальных мест, а в другой список вообще не появлялся. Если просто сказать Курсору решить эту проблему, появляется куча рисков. Куда проще дать конкретную инстр��кцию: «Сходи в форму создания, посмотри как там это реализовано, найди отличия и примени то же решение здесь»
Правильные решения
Можно решить потенциальные проблемы ещё на этапе написания промта. Если у вас в интерфейсе уже есть решение, которое вас устраивает, просто скажите, чтобы при написании кода Cursor ориентировался на него.
Пример: на одной странице у вас есть красивый скелетон, а на другой просто крутится лоадер при загрузке. Если вы скажете сделать скелетон на другой странице, Cursor будет заново придумывать реализацию. Вместо этого лучше сказать: «Посмотри, как сделано на странице X, и реализуй так же». Таким образом вы избавите Cursor от лишних размышлений, а себя — от его возможных ошибок.
Следите за тем, что он делает
Вайбкодинг не такой уж и вайбовый. У меня ещё ни разу не получалось посмотреть ютубчик в этом процессе, потому что я всегда наблюдаю за тем, не пишет ли он лишний код, не нагромождает ли избыточные CSS-правила или вообще не сносит ли половину сервиса.
Однажды, пока я отвлёкся, Cursor долго не мог поменять стиль шрифта у заголовка на свёрстанной странице — и в этот момент решил, что легче удалить всю страницу и переписать её заново. По итогу, он удалил страницу и не смог заново её написать. Я попытался сделать бэкап в самом Cursor'е, но не получилось. А так как проект не был синхронизирован с репозиторием на GitHub, пришлось делать всё заново. Из этой истории логично исходит следующий пункт.
Познакомьтесь с GitHub
Заведите репозиторий на GitHub. Это позволит вам создавать облачные версии своего проекта и в случае чего откатиться к рабочей версии. Также последующий деплой будет делаться через него.
Разберитесь с понятиями: мердж, ветка, коммит и основными командами для Git. Таким образом вы не потеряете прогресс и будете лучше понимать, где искать ошибку.
Наберитесь терпения
Будьте готовы к тому, что ничего и никогда не получится сделать с первого раза. А если получится — значит, вы просто пока не заметили ошибку.
Как сейчас выглядит сервис
Вот что можно поделать в Humans (рабочее название сервиса) сейчас:
1 Просматривать ивенты по городам и делиться
2.Зарегаться, чтобы добавлять ивенты в избранное. Также заполнить свой профиль
3. Создать свой ивент и загрузить туда GPX маршрута, который отобразится в виде интерактивной карты
Кстати, я немного причесал UI и поработал над навигацией, так что заходите посмотреть
На этом все. Спасибо тем, кто дошел до конца. Надеюсь, что каждый смог найти для себя что‑то полезное 🖤
Если вам близка тема роста в дизайне и хочется находить что-то полезное без воды — заходите в мой телеграм-канал Тултип. Там я делюсь тем, что сам изучаю и применяю в работе: полезные статьи, продуктовые кейсы, фреймворки для роста и инструменты. Увидимся там!
А как у вас дела с вайбкодингом? Успели повайбкодить и, если да, то что из этого вышло? Пишите в комментах — соберём коллективный опыт 🔥