За последние 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 и поработал над навигацией, так что заходите посмотреть
На этом все. Спасибо тем, кто дошел до конца. Надеюсь, что каждый смог найти для себя что‑то полезное ?
Если вам близка тема роста в дизайне и хочется находить что-то полезное без воды — заходите в мой телеграм-канал Тултип. Там я делюсь тем, что сам изучаю и применяю в работе: полезные статьи, продуктовые кейсы, фреймворки для роста и инструменты. Увидимся там!
А как у вас дела с вайбкодингом? Успели повайбкодить и, если да, то что из этого вышло? Пишите в комментах — соберём коллективный опыт ?
Комментарии (29)
vic_1
21.11.2025 10:00Не знаю как насчёт вайбкодинга, у меня была мысль попробовать, но как то со временем никак, но есть опыт немного другого плана, но мне кажется очень похоже, даёшь задание, смотришь на результат, поправляешь и новая итерации и так пока не получится то чо хочется,. Так вот я хотел составить брошюру по своей новой машине, читать 300 с лишним страниц не хотелось, а что то действительно нужно можно пропустить если читать по диагонали. Так вот есть gemini pro, кормил ей pdf ник и попросил сделать конспект где будут перечилины действия как сделать, ссылка на картинку если есть и английская цитата из брошюры. Казалось просто, но ничего не получилось, я так и не добился конспект по всей брошюре, а потом она перешла на украинский. Так что мне кажется тоже будет и с вайбкодингом, попробую как нибудь если время будет, а пока юнит тесты пусть пишет, с этим пока вроде норм
Evgenii707 Автор
21.11.2025 10:00Да, с первого раза, к сожалению, далеко не всегда что-то получается. Причем, даже простые задачи
grixis
21.11.2025 10:00Скорее всего 300 страниц pdf не умещались в контест, поэтому он выдал фигню. Ещё нужно учитывать что у него довольно строгий и небольшой лимит на сам ответ.
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 . Хорошо дополняет описанные стратегии.
dibu28
21.11.2025 10:00Тоже заметил что переключение между моделями помогает. Если одна модель зацикливается или не может за несколько шагов починить ошибку, то перекдючение на другую модель с тем же промптом помогает двигаться дальше.
Juzujka
21.11.2025 10:00Вайбкодинг - это хорошо. Но где велосипеды-то? Кататься когда будем? Или бегать хотя бы. По ссылке страница не открывается.
iAVKi
21.11.2025 10:00Курсор и подобная дребедень при таком уровне развития нейросети вообще не должна применяться для серьёзных задач. Рекомендую использовать нейросети по другому. От задачи к задаче, со созданием бэкапов между ними. Я не пользуюсь GitHub , если не хочу публиковать код, поэтому пишите сначала себе софтинку, чтобы пользовать нейросеть как вам удобно и вайбкодите уже на своём софте.
hc13
21.11.2025 10:00Я зарегистрировался чтобы сказать тебе, что я делаю функционально практически тоже самое, только в другой сфере, и пришел к таким же выводам, почти дословно. Ты не один, круто что в мире появляется больше полезных вещей. Респект, и желаю успеха
chh76
21.11.2025 10:00Нужно всего лишь прочитать хотя бы одну книгу по ИИ и не придётся придумывать велосипед, не придётся хаять и за то, что он и не должен делать так, как кому то кажется, все встанет на свои места. Например есть книжка "промтп инжиниринг для ллм" , автор Джон барриман, Альберт циглер
Grifonhard
21.11.2025 10:00Я сам пишу на go, но иногда мне приходится вайбкодить поневоле - надо сделать фронт-"времянку" или написать цепь скриптов, чтобы собственные интеграционные тесты провести. Можно было б и самому освоить, но не хочется тратить много времени на непрофильные занятия. Ко всем сказанным выводам выше присоединяюсь, еще поделюсь собственным опытом.
Для себя я выбрал оптимальный подход максимально мелкое разбиение (поднимаемый в статье тезис о подробности ТЗ) - генерим - отправляем другой сети (но можно и этой же) с запросом что можно улучшить - дебажим. Единственное, что если есть хоть капля алгоритмичности, то это многократно более быстро и практично делать руками, благо алгоритмы сами по себе в реализации компатные обычно. Грубо говоря, я прошу сети сделать "рыбу" в которую я сам вставляю более сложные элементы.
Но на мой взгляд вайб-кодинг - это просто костыль. Использовать LLM для настоящего бизнес кода (имею в виду как программиста) - это смерть. Сначала х3 сил чтоб заставить родить что-то работающее, потом терпеть урон от водопада багов, который не закончится до тех пор, пока какой-нибудь человек не проанализирует всю архитектуру и каждую функцию и, скорее всего, все перепишет. Для пет-проекта или демонстрации пойдет, когда этим начнуть пользоваттся реальные потребители - вот тут-то все и полетит в пропасть.
Evgenii707 Автор
21.11.2025 10:00Согласен, IDE стоит рассматривать, как возможность для разработчика повысить свою продуктивность, чем как самостоятельную рабочую единицу
Но для пет проекта или mvp для проверки гипотезы самое то)
gun_dose
21.11.2025 10:00Всякие курсоры пока потрогать не довелось, но давно пользуюсь ИИ плагинами для IDE. И вот буквально неделю назад заметил, что GitHub copilot на бесплатном тарифе в режиме агента выдаёт очень даже крутые результаты. Я в него скопировал текст из задачи, где было подробно расписано, какие классы нужно создать, и что они должны делать. Он минут 10 подумал и создал и отредактировал штук 5 файлов. Там конечно был один баг, плюс пришлось немного причесать стандарты кода, кое-где оказались даже лишние фичи, попросил копайлота выпилить, он споавился. В общем, через пару часов доработки получилось окончательное решение. Без ИИ, я бы там на день точно закопался. Вот не знаю только, считается это за вайбкодинг или нет)))
Но вообще, я к тому, что вовсе не обязательно ломать свой порядок работы. Нужно просто найти плагин для своей IDE и пользоваться. Причём даже бесплатной версией. Если пользоваться несколькими плагинами, у каждого есть своя квота. У одного закончилась, используй другой. Но самое главное: все эти плагины очень активно развиваются. Несколько месяцев назад я сам тут писал, что копайлот отстойный. А сейчас в нём очень крутой агентский режим. Буквально пару недель назад этот режим был ещё очень сырой. А ещё все эти плагины активно используют MCP-tools, из-за чего неслабо экономится квота. Месяц или два назад у меня копайлот в агентском режиме сожрал всю квоту на одной задаче. А сейчас мне этой квоты хватает на неделю активного использования.
KonstantinTokar
21.11.2025 10:00Я недавно столкнулся с тем, что в процессе правки ии поменял названия локальных переменных :) Вроде мелочь, но я пока не придумал как с этим бороться. Ему всё равно, а мнк для контроля большие проблемы.
Evgenii707 Автор
21.11.2025 10:00Можно попробовать добавить это правило в rules и есть шанс, что в следующий раз, когда он решит это сделать, то передумает, прочитав правила)
riky
21.11.2025 10:00Ещё важно диалог как можно быстрее заканчивать и создавать новый, иначе токена начнут быстро улетать. Ну и начинать с авто режима, он чуть дешевле чем этот же соннет(но по качеству он получше). Мелочь он и так хорошо делает практически с первого раза. А если надо что то посложнее, то лучше сначала попросить варианты и описание того что нужно сделать и как. Например если надо создать систему из десятков классов, то попросить написать их сигнатуры. И сразу оценить по ним правильно ли он понял, исправить на этом этапе гораздо проще и быстрее, чем потом копаться в тысячах строках кода. Для разработки фронтера обычно помогает сразу подкинуть пример страницы откуда он и цсс классы и в целом подход возьмёт.
В общем после начала работы развидеть это конечно уже сложно. Работа переходит больше на уровень архитектуры. Но использовать надо топовые модели, чтобы не разочароваться. Все это стоит денег конечно, но того стоит
kostoms
21.11.2025 10:00Я вот тоже сначала развлекался пару месяцев, создал неведомую монструозную хрень по приколу, но с прицелом на будущее, потом ИИ убил её, а я переключился на один легаси-проект как раз на курсоре... С учётом примерного такого же опыта (правда в другой IDE) сразу завёл ему правило поддерживать memory bank, в правилах так же указал проверять мои требования в директориях `ai` на уровне воркспейса и самого проекта, чуть позже запретил что-либо менять в проекте если я явно не попросил (но работает ненадёжно - вроде в зависимости от модели, но пока не уверен) - вот в режиме "Ask" он строго ничего не портит. Короче, за месяца полтора навайбал то, куда боялся раньше палочкой потыкать. Постепенно выработал для себя несколько правил, в произвольном порядке:
Держу копию оригинального кода рядом в сторонке, так потом проще сказать модели "скопируй оттуда" чем откати к оригиналу
Модель не имеет права ничего никуда коммитить и менять за пределами проектного дерева исходников (где оно, это дерево - надо разъяснить в требованиях, кроме обычных требований)
Проект довольно большой, поэтому вначале прогнал (кажется ГПТ) в режиме MAX с требованием проанализировать проект и сохранить в мемориз. Потом в MAX и не переключался вроде
Задачи у меня определяются тикетами, если что-то надо сделать - создаю тикет, пока формулирую там проблему начинаю сам яснее понимать чего хочу. Потом спрашиваю у ассистента (ГПТ) - а как бы сделал ты. Он расписывает решение - обычно сразу ОК, я сложного не прошу. Потом в том же чатике переключаюсь на Клод и прошу его реализовать тест кейсы, воспроизводящие нашу текущую проблему. Он создаёт, я проверяю, что тесты успешно валятся (агент и этого у меня не может, хе-хе). После этого я в том же чатике его же прошу реализовать фикс. И обычно всё более-менее ОК, за пару-тройку итераций всё работает и полный набор тестов (что бы убедиться что мы чего-то не упустили) проходит успешно.
На одно дело используется один чат, или больше. Но для другой проблемы обязательно открываю новый чат, чтобы старый контекст не сбивал модель с толку.
Ну и так несколько общих замечаний.
В том первом эксперименте у меня и веб-юи было, на реакте. Ну оно предложило, я согласился и потом его ещё одну утилиту просил его состряпать. О том как должен выглядеть интерфейс мне так и не удалось ему объяснить, поэтому сказал - вон тот скрипт возьми и на нём сделай. Он и там визуально накосячить умудлился, но хотя бы функционал получился.
Но то был новый проект. А в старом проекте мешанина файлов сбивает модель с толку, она перестаёт понимать что откуда берётся - надо объяснять что там к чему, а ещё лучше отрефакторить к логичной структуре.
Daemon_Magic
21.11.2025 10:00Товарищам, пользующим т.н. "искусственный интеллект", для начала неплохо-бы поиспользовать ЕСТЕСТВЕННЫЙ ИНТЕЛЛЕКТ. Но, это-ж в разы дольше (и дороже). Так-что...
kostoms
21.11.2025 10:00Не суди о людях по себе. Как ты думаешь мы раньше жили? А теперь нам дали инструмент, который делает всю рутину за нас. Остаётся только творчество.
Pitcentr0
сейчас навайбкодить не сложно и не долго, сложно и дорого его продвигать и развивать, как в проекте https://belbooking.by все просто и выглядит не сложно но продвижение и поддержка занимает очень много времени в команде, да , но да, с вайбкодиногом стало легче
Evgenii707 Автор
Поддержка и развитие — это главный нюанс)
Mr_Cheater
Так нужен вайб-продвигатор, простите, вайб-маркетолог.