Хабр Курсы для дизайнеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Дизайн доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 32
сейчас навайбкодить не сложно и не долго, сложно и дорого его продвигать и развивать, как в проекте https://belbooking.by все просто и выглядит не сложно но продвижение и поддержка занимает очень много времени в команде, да , но да, с вайбкодиногом стало легче
Не знаю как насчёт вайбкодинга, у меня была мысль попробовать, но как то со временем никак, но есть опыт немного другого плана, но мне кажется очень похоже, даёшь задание, смотришь на результат, поправляешь и новая итерации и так пока не получится то чо хочется,. Так вот я хотел составить брошюру по своей новой машине, читать 300 с лишним страниц не хотелось, а что то действительно нужно можно пропустить если читать по диагонали. Так вот есть gemini pro, кормил ей pdf ник и попросил сделать конспект где будут перечилины действия как сделать, ссылка на картинку если есть и английская цитата из брошюры. Казалось просто, но ничего не получилось, я так и не добился конспект по всей брошюре, а потом она перешла на украинский. Так что мне кажется тоже будет и с вайбкодингом, попробую как нибудь если время будет, а пока юнит тесты пусть пишет, с этим пока вроде норм
Как вайбкодить без боли?
Не вайбкодить
Интересный разбор. Узнал много знакомого из своего опыта 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 . Хорошо дополняет описанные стратегии.
Вайбкодинг - это хорошо. Но где велосипеды-то? Кататься когда будем? Или бегать хотя бы. По ссылке страница не открывается.
Курсор и подобная дребедень при таком уровне развития нейросети вообще не должна применяться для серьёзных задач. Рекомендую использовать нейросети по другому. От задачи к задаче, со созданием бэкапов между ними. Я не пользуюсь GitHub , если не хочу публиковать код, поэтому пишите сначала себе софтинку, чтобы пользовать нейросеть как вам удобно и вайбкодите уже на своём софте.
Я зарегистрировался чтобы сказать тебе, что я делаю функционально практически тоже самое, только в другой сфере, и пришел к таким же выводам, почти дословно. Ты не один, круто что в мире появляется больше полезных вещей. Респект, и желаю успеха
Нужно всего лишь прочитать хотя бы одну книгу по ИИ и не придётся придумывать велосипед, не придётся хаять и за то, что он и не должен делать так, как кому то кажется, все встанет на свои места. Например есть книжка "промтп инжиниринг для ллм" , автор Джон барриман, Альберт циглер
Я сам пишу на go, но иногда мне приходится вайбкодить поневоле - надо сделать фронт-"времянку" или написать цепь скриптов, чтобы собственные интеграционные тесты провести. Можно было б и самому освоить, но не хочется тратить много времени на непрофильные занятия. Ко всем сказанным выводам выше присоединяюсь, еще поделюсь собственным опытом.
Для себя я выбрал оптимальный подход максимально мелкое разбиение (поднимаемый в статье тезис о подробности ТЗ) - генерим - отправляем другой сети (но можно и этой же) с запросом что можно улучшить - дебажим. Единственное, что если есть хоть капля алгоритмичности, то это многократно более быстро и практично делать руками, благо алгоритмы сами по себе в реализации компатные обычно. Грубо говоря, я прошу сети сделать "рыбу" в которую я сам вставляю более сложные элементы.
Но на мой взгляд вайб-кодинг - это просто костыль. Использовать LLM для настоящего бизнес кода (имею в виду как программиста) - это смерть. Сначала х3 сил чтоб заставить родить что-то работающее, потом терпеть урон от водопада багов, который не закончится до тех пор, пока какой-нибудь человек не проанализирует всю архитектуру и каждую функцию и, скорее всего, все перепишет. Для пет-проекта или демонстрации пойдет, когда этим начнуть пользоваттся реальные потребители - вот тут-то все и полетит в пропасть.
Всякие курсоры пока потрогать не довелось, но давно пользуюсь ИИ плагинами для IDE. И вот буквально неделю назад заметил, что GitHub copilot на бесплатном тарифе в режиме агента выдаёт очень даже крутые результаты. Я в него скопировал текст из задачи, где было подробно расписано, какие классы нужно создать, и что они должны делать. Он минут 10 подумал и создал и отредактировал штук 5 файлов. Там конечно был один баг, плюс пришлось немного причесать стандарты кода, кое-где оказались даже лишние фичи, попросил копайлота выпилить, он споавился. В общем, через пару часов доработки получилось окончательное решение. Без ИИ, я бы там на день точно закопался. Вот не знаю только, считается это за вайбкодинг или нет)))
Но вообще, я к тому, что вовсе не обязательно ломать свой порядок работы. Нужно просто найти плагин для своей IDE и пользоваться. Причём даже бесплатной версией. Если пользоваться несколькими плагинами, у каждого есть своя квота. У одного закончилась, используй другой. Но самое главное: все эти плагины очень активно развиваются. Несколько месяцев назад я сам тут писал, что копайлот отстойный. А сейчас в нём очень крутой агентский режим. Буквально пару недель назад этот режим был ещё очень сырой. А ещё все эти плагины активно используют MCP-tools, из-за чего неслабо экономится квота. Месяц или два назад у меня копайлот в агентском режиме сожрал всю квоту на одной задаче. А сейчас мне этой квоты хватает на неделю активного использования.
Я недавно столкнулся с тем, что в процессе правки ии поменял названия локальных переменных :) Вроде мелочь, но я пока не придумал как с этим бороться. Ему всё равно, а мнк для контроля большие проблемы.
Ещё важно диалог как можно быстрее заканчивать и создавать новый, иначе токена начнут быстро улетать. Ну и начинать с авто режима, он чуть дешевле чем этот же соннет(но по качеству он получше). Мелочь он и так хорошо делает практически с первого раза. А если надо что то посложнее, то лучше сначала попросить варианты и описание того что нужно сделать и как. Например если надо создать систему из десятков классов, то попросить написать их сигнатуры. И сразу оценить по ним правильно ли он понял, исправить на этом этапе гораздо проще и быстрее, чем потом копаться в тысячах строках кода. Для разработки фронтера обычно помогает сразу подкинуть пример страницы откуда он и цсс классы и в целом подход возьмёт.
В общем после начала работы развидеть это конечно уже сложно. Работа переходит больше на уровень архитектуры. Но использовать надо топовые модели, чтобы не разочароваться. Все это стоит денег конечно, но того стоит
Я вот тоже сначала развлекался пару месяцев, создал неведомую монструозную хрень по приколу, но с прицелом на будущее, потом ИИ убил её, а я переключился на один легаси-проект как раз на курсоре... С учётом примерного такого же опыта (правда в другой IDE) сразу завёл ему правило поддерживать memory bank, в правилах так же указал проверять мои требования в директориях `ai` на уровне воркспейса и самого проекта, чуть позже запретил что-либо менять в проекте если я явно не попросил (но работает ненадёжно - вроде в зависимости от модели, но пока не уверен) - вот в режиме "Ask" он строго ничего не портит. Короче, за месяца полтора навайбал то, куда боялся раньше палочкой потыкать. Постепенно выработал для себя несколько правил, в произвольном порядке:
Держу копию оригинального кода рядом в сторонке, так потом проще сказать модели "скопируй оттуда" чем откати к оригиналу
Модель не имеет права ничего никуда коммитить и менять за пределами проектного дерева исходников (где оно, это дерево - надо разъяснить в требованиях, кроме обычных требований)
Проект довольно большой, поэтому вначале прогнал (кажется ГПТ) в режиме MAX с требованием проанализировать проект и сохранить в мемориз. Потом в MAX и не переключался вроде
Задачи у меня определяются тикетами, если что-то надо сделать - создаю тикет, пока формулирую там проблему начинаю сам яснее понимать чего хочу. Потом спрашиваю у ассистента (ГПТ) - а как бы сделал ты. Он расписывает решение - обычно сразу ОК, я сложного не прошу. Потом в том же чатике переключаюсь на Клод и прошу его реализовать тест кейсы, воспроизводящие нашу текущую проблему. Он создаёт, я проверяю, что тесты успешно валятся (агент и этого у меня не может, хе-хе). После этого я в том же чатике его же прошу реализовать фикс. И обычно всё более-менее ОК, за пару-тройку итераций всё работает и полный набор тестов (что бы убедиться что мы чего-то не упустили) проходит успешно.
На одно дело используется один чат, или больше. Но для другой проблемы обязательно открываю новый чат, чтобы старый контекст не сбивал модель с толку.
Ну и так несколько общих замечаний.
В том первом эксперименте у меня и веб-юи было, на реакте. Ну оно предложило, я согласился и потом его ещё одну утилиту просил его состряпать. О том как должен выглядеть интерфейс мне так и не удалось ему объяснить, поэтому сказал - вон тот скрипт возьми и на нём сделай. Он и там визуально накосячить умудлился, но хотя бы функционал получился.
Но то был новый проект. А в старом проекте мешанина файлов сбивает модель с толку, она перестаёт понимать что откуда берётся - надо объяснять что там к чему, а ещё лучше отрефакторить к логичной структуре.
Товарищам, пользующим т.н. "искусственный интеллект", для начала неплохо-бы поиспользовать ЕСТЕСТВЕННЫЙ ИНТЕЛЛЕКТ. Но, это-ж в разы дольше (и дороже). Так-что...
Какова мотивация была писать эту статью? Откуда уверенность, что вот этот ваш опыт - настолько уникален, что никто другой не смог его повторить? Что умение правильно вайб-кодить намного важнее, чем собственно организовать инфраструктуру для этого самого вайб-кодинга? (ну там дата-центры построить, нейросети обучить на триллионах токенах и миллионах видеокартах, бла-бла-бла)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как вайбкодить без боли? 11 выводов, к которым я пришёл