За последние 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. Таким образом вы не потеряете прогресс и будете лучше понимать, где искать ошибку.

Наберитесь терпения

Будьте готовы к тому, что ничего и никогда не получится сделать с первого раза. А если получится — значит, вы просто пока не заметили ошибку.

Как сейчас выглядит сервис

Несмотря на все грабли, за 3 месяца получилось создать рабочий MVP
Несмотря на все грабли, за 3 месяца получилось создать рабочий MVP

Вот что можно поделать в Humans (рабочее название сервиса) сейчас:

1 Просматривать ивенты по городам и делиться

2.Зарегаться, чтобы добавлять ивенты в избранное. Также заполнить свой профиль

3. Создать свой ивент и загрузить туда GPX маршрута, который отобразится в виде интерактивной карты

Кстати, я немного причесал UI  и поработал над навигацией, так что заходите посмотреть

На этом все. Спасибо тем, кто дошел до конца. Надеюсь, что каждый смог найти для себя что‑то полезное ?

Если вам близка тема роста в дизайне и хочется находить что-то полезное без воды — заходите в мой телеграм-канал Тултип. Там я делюсь тем, что сам изучаю и применяю в работе: полезные статьи, продуктовые кейсы, фреймворки для роста и инструменты. Увидимся там!

А как у вас дела с вайбкодингом? Успели повайбкодить и, если да, то что из этого вышло? Пишите в комментах — соберём коллективный опыт ?

Комментарии (24)


  1. Pitcentr0
    21.11.2025 10:00

    сейчас навайбкодить не сложно и не долго, сложно и дорого его продвигать и развивать, как в проекте https://belbooking.by все просто и выглядит не сложно но продвижение и поддержка занимает очень много времени в команде, да , но да, с вайбкодиногом стало легче


    1. Evgenii707 Автор
      21.11.2025 10:00

      Поддержка и развитие — это главный нюанс)


    1. Mr_Cheater
      21.11.2025 10:00

      Так нужен вайб-продвигатор, простите, вайб-маркетолог.


  1. vic_1
    21.11.2025 10:00

    Не знаю как насчёт вайбкодинга, у меня была мысль попробовать, но как то со временем никак, но есть опыт немного другого плана, но мне кажется очень похоже, даёшь задание, смотришь на результат, поправляешь и новая итерации и так пока не получится то чо хочется,. Так вот я хотел составить брошюру по своей новой машине, читать 300 с лишним страниц не хотелось, а что то действительно нужно можно пропустить если читать по диагонали. Так вот есть gemini pro, кормил ей pdf ник и попросил сделать конспект где будут перечилины действия как сделать, ссылка на картинку если есть и английская цитата из брошюры. Казалось просто, но ничего не получилось, я так и не добился конспект по всей брошюре, а потом она перешла на украинский. Так что мне кажется тоже будет и с вайбкодингом, попробую как нибудь если время будет, а пока юнит тесты пусть пишет, с этим пока вроде норм


    1. Evgenii707 Автор
      21.11.2025 10:00

      Да, с первого раза, к сожалению, далеко не всегда что-то получается. Причем, даже простые задачи


    1. grixis
      21.11.2025 10:00

      Скорее всего 300 страниц pdf не умещались в контест, поэтому он выдал фигню. Ещё нужно учитывать что у него довольно строгий и небольшой лимит на сам ответ.


  1. estima92
    21.11.2025 10:00

    Как вайбкодить без боли?

    Не вайбкодить


    1. Evgenii707 Автор
      21.11.2025 10:00

      Тоже вариант)


    1. Juzujka
      21.11.2025 10:00

      Уже не вариант


  1. JrFrederick
    21.11.2025 10:00

    Интересный разбор. Узнал много знакомого из своего опыта vibecoding, только у меня это всё в 3D. В Blender я работаю через 3D-Agent и Blender MCP. По сути это «Cursor для Blender» и полноценный MCP, который закрывает работу с геометрией, скриптами и структурой проекта. Blender, конечно, не CAD, но он бесплатный, открытый и с нормальными библиотеками.

    Подходы у меня схожие. Тоже понял, что без чётких to-do списков ассистент начинает лепить лишнее. Задачи должны быть конкретными. Но сильнее всего на эффективность влияет TDD в vibecoding. Я использую сразу два LLM. В одном чате модель пишет unit, stress и integration тесты. Во втором, на другом провайдере (OpenAI плюс Claude, например), строю план и реализацию строго под эти тесты. Когда модели разные, ошибок и галлюцинаций меньше, и они лучше дополняют друг друга. Такой TDD в vibecoding работает заметно лучше классического.

    С 3D-Agent делаю то же самое. У них уже есть встроенные to-do задачи, плюс модель понимает визуальные изменения. Это убирает хаос, который обычно возникает в 3D vibecoding. В связке с 21st.dev получается быстрый цикл: чистые вайрфреймы, аккуратная топология и оригинальные ассеты для реальных проектов и коммерческих сайтов.

    Сейчас, в эпоху AI и vibecoding, свои качественные 3D ассеты — это уже необходимость, если хочется выделяться. Стоки больше не спасают. Собственный MCP для Blender плюс TDD дают стабильный и быстрый пайплайн.

    Если интересна 3D-часть vibecoding, посмотрите 3D-Agent . Хорошо дополняет описанные стратегии.


    1. Evgenii707 Автор
      21.11.2025 10:00

      Спасибо, было полезно
      MCP в блендер было бы интересно попробовать)


    1. dibu28
      21.11.2025 10:00

      Тоже заметил что переключение между моделями помогает. Если одна модель зацикливается или не может за несколько шагов починить ошибку, то перекдючение на другую модель с тем же промптом помогает двигаться дальше.


  1. Juzujka
    21.11.2025 10:00

    Вайбкодинг - это хорошо. Но где велосипеды-то? Кататься когда будем? Или бегать хотя бы. По ссылке страница не открывается.


    1. Evgenii707 Автор
      21.11.2025 10:00

      Проверил, должно работать)


  1. iAVKi
    21.11.2025 10:00

    Курсор и подобная дребедень при таком уровне развития нейросети вообще не должна применяться для серьёзных задач. Рекомендую использовать нейросети по другому. От задачи к задаче, со созданием бэкапов между ними. Я не пользуюсь GitHub , если не хочу публиковать код, поэтому пишите сначала себе софтинку, чтобы пользовать нейросеть как вам удобно и вайбкодите уже на своём софте.


    1. Mideks
      21.11.2025 10:00

      гит можно использовать и локально. избавит от многих проблем, зря вы так


  1. hc13
    21.11.2025 10:00

    Я зарегистрировался чтобы сказать тебе, что я делаю функционально практически тоже самое, только в другой сфере, и пришел к таким же выводам, почти дословно. Ты не один, круто что в мире появляется больше полезных вещей. Респект, и желаю успеха


    1. Evgenii707 Автор
      21.11.2025 10:00

      Спасибо, тебе того же)


  1. chh76
    21.11.2025 10:00

    Нужно всего лишь прочитать хотя бы одну книгу по ИИ и не придётся придумывать велосипед, не придётся хаять и за то, что он и не должен делать так, как кому то кажется, все встанет на свои места. Например есть книжка "промтп инжиниринг для ллм" , автор Джон барриман, Альберт циглер


    1. Evgenii707 Автор
      21.11.2025 10:00

      Спасибо за рекомендацию, хотел бы что-то почитать в этой тематике


  1. Grifonhard
    21.11.2025 10:00

    Я сам пишу на go, но иногда мне приходится вайбкодить поневоле - надо сделать фронт-"времянку" или написать цепь скриптов, чтобы собственные интеграционные тесты провести. Можно было б и самому освоить, но не хочется тратить много времени на непрофильные занятия. Ко всем сказанным выводам выше присоединяюсь, еще поделюсь собственным опытом.

    Для себя я выбрал оптимальный подход максимально мелкое разбиение (поднимаемый в статье тезис о подробности ТЗ) - генерим - отправляем другой сети (но можно и этой же) с запросом что можно улучшить - дебажим. Единственное, что если есть хоть капля алгоритмичности, то это многократно более быстро и практично делать руками, благо алгоритмы сами по себе в реализации компатные обычно. Грубо говоря, я прошу сети сделать "рыбу" в которую я сам вставляю более сложные элементы.

    Но на мой взгляд вайб-кодинг - это просто костыль. Использовать LLM для настоящего бизнес кода (имею в виду как программиста) - это смерть. Сначала х3 сил чтоб заставить родить что-то работающее, потом терпеть урон от водопада багов, который не закончится до тех пор, пока какой-нибудь человек не проанализирует всю архитектуру и каждую функцию и, скорее всего, все перепишет. Для пет-проекта или демонстрации пойдет, когда этим начнуть пользоваттся реальные потребители - вот тут-то все и полетит в пропасть.


    1. Evgenii707 Автор
      21.11.2025 10:00

      Согласен, IDE стоит рассматривать, как возможность для разработчика повысить свою продуктивность, чем как самостоятельную рабочую единицу

      Но для пет проекта или mvp для проверки гипотезы самое то)


  1. gun_dose
    21.11.2025 10:00

    Всякие курсоры пока потрогать не довелось, но давно пользуюсь ИИ плагинами для IDE. И вот буквально неделю назад заметил, что GitHub copilot на бесплатном тарифе в режиме агента выдаёт очень даже крутые результаты. Я в него скопировал текст из задачи, где было подробно расписано, какие классы нужно создать, и что они должны делать. Он минут 10 подумал и создал и отредактировал штук 5 файлов. Там конечно был один баг, плюс пришлось немного причесать стандарты кода, кое-где оказались даже лишние фичи, попросил копайлота выпилить, он споавился. В общем, через пару часов доработки получилось окончательное решение. Без ИИ, я бы там на день точно закопался. Вот не знаю только, считается это за вайбкодинг или нет)))

    Но вообще, я к тому, что вовсе не обязательно ломать свой порядок работы. Нужно просто найти плагин для своей IDE и пользоваться. Причём даже бесплатной версией. Если пользоваться несколькими плагинами, у каждого есть своя квота. У одного закончилась, используй другой. Но самое главное: все эти плагины очень активно развиваются. Несколько месяцев назад я сам тут писал, что копайлот отстойный. А сейчас в нём очень крутой агентский режим. Буквально пару недель назад этот режим был ещё очень сырой. А ещё все эти плагины активно используют MCP-tools, из-за чего неслабо экономится квота. Месяц или два назад у меня копайлот в агентском режиме сожрал всю квоту на одной задаче. А сейчас мне этой квоты хватает на неделю активного использования.


  1. KonstantinTokar
    21.11.2025 10:00

    Я недавно столкнулся с тем, что в процессе правки ии поменял названия локальных переменных :) Вроде мелочь, но я пока не придумал как с этим бороться. Ему всё равно, а мнк для контроля большие проблемы.