Дисклеймер: ни на что не претендую, просто делюсь результатами своих наблюдений за знакомыми и коллегами. Примеры сгенерированы на 100% в ChatGPT в режиме Plus — Thinking.
Мои наблюдения за коллегами, друзьями и знакомыми не из ИТ, которые начинают работать с генеративными системами с целью написания кода, показывают, что даже те, кто раньше боялся подступиться к программированию, сейчас вполне амбициозно пишут промпты уровня: «А что, если сделать программу для фиксации результатов анализов и сбора информации? Сделай мне программу». А потом дорабатывают результат в духе: «Нет, не так, пусть работает на телефоне».
На выходе появляется результат, зачастую непредсказуемый, но вполне устраивающий новичков, которые тут же воздвигают себя на вершину графика Даннинга‑Крюгера, потому что подобного результата люди, не написавшие в жизни даже std::cout << "Hello, world!";, раньше бы просто не достигли.
Андрей Карпати, один из founding members OpenAI, в феврале 2025 года ввёл термин vibe coding. Он описал подход, при котором код получается через естественный язык, быстрые итерации и работу «по ощущению», а сам такой подход, по его словам, неплохо подходит для небольших, условно «выходных» проектов, но не является прямой заменой продакшен‑разработке. Второй посыл многие, как мне кажется, не услышали. Ну да ладно, я пишу не совсем об этом. Мне хочется помочь новичкам мыслить чуть более структурированно, и для этого я предлагаю Vibe++ — язык намерений, язык промпт‑программирования, то есть слабо формализованный способ описывать задачи в виде понятного человеку и модели текста так, чтобы на выходе получать более предсказуемый результат.
Начну с конца. Я подготовил два примера, которые были сгенерированы простым промптом на человеческом языке, и структурированным промптом на Vibe++. Я сохранил их в виде текстовых файлов. Оба запроса запускались с первого раза, и код после генерации не дорабатывался.
Первый промпт отработал примерно за две минуты в том же режиме. Второй промпт генерировал результат примерно в два раза дольше. Но есть нюанс.
Результат работы простого промпта на человеческом языке представлен тут, а результат аналогичного запроса на Vibe++ представлен тут. Я не буду делать выводы за вас, но, по‑моему, результаты отличаются очень заметно. Обращу внимание, что первый вариант занимает 500 Мб на закладке Google Chrome, в то время как Vibe++ вариант всего 50 Мб. Для меня это показатель эффективности кода.
Если я вас хоть немного заинтриговал, то ниже коротко опишу, что именно я предлагаю.
Коротко, суть
Vibe++ — это не новый язык программирования и не попытка придумать универсальный стандарт. Это, скорее, рекомендательный формат описания задачи для LLM, который помогает человеку изложить свои намерения более структурированно.
Если совсем просто, идея такая: вместо одного длинного промпта в духе «сделай мне приложение, но красивое, быстрое и чтобы на телефоне работало» мы раскладываем задачу по нескольким понятным блокам:
что за проект;
зачем он нужен;
кто им будет пользоваться;
какой стиль нужен;
какие технологии предпочтительны;
какой архитектурный подход желателен;
какие ограничения нельзя нарушать;
как документировать результат;
что считать хорошим итогом.
То есть Vibe++ нужен не для того, чтобы «магически улучшить код», а для того, чтобы уменьшить хаос при постановке задачи.
Для новичков в этом, как мне кажется, и есть главная польза. Даже если человек не умеет программировать, он всё равно может хотя бы частично управлять результатом: не просто просить «сделай что‑нибудь», а задавать контекст, рамки, стиль и ожидания. Это не делает его инженером, но делает постановку задачи заметно лучше.
В чём польза?
Обычный prompt часто смешивает всё сразу: цель, ограничения, пожелания, технологические предпочтения, стиль интерфейса и требования к документации. Модель, конечно, пытается это понять, но ей приходится догадываться, что важно, а что второстепенно.
Vibe++ предлагает простую идею: разнести всё по смысловым секциям, чтобы и человеку, и модели было проще.
Например:
блок
projectописывает, что вообще создаётся;блок
purposeобъясняет, зачем это нужно;блок
audienceзадаёт пользователей и целевую аудиторию;блок
styleпередаёт настроение и характер решения;блок
technologyфиксирует стек;блок
architectureзадаёт желаемый подход;блок
documentationговорит, как описывать код, README, комментарии и архитектурные решения;блок
rulesразделяет обязательные требования, рекомендации и мягкие пожелания.
На мой взгляд, это особенно полезно именно новичкам. Они редко умеют формулировать архитектурные требования, но уже вполне могут сказать: «это MVP», «не используй внешние библиотеки», «сделай код понятным», «добавь README», «не перегружай интерфейс» и «пусть структура проекта будет простой». Для модели это уже гораздо лучше, чем просто «сделай красиво».
Как выглядит синтаксис
Vibe++ можно записывать в обычном YAML‑подобном виде. Ничего сложного в этом нет. Смысл не в формальной строгости, а в понятной структуре.
Минимальный пример может выглядеть так:
vibepp: "0.1" project: name: "FocusBoard" type: "web-app" summary: "Простой kanban для личных задач" purpose: goal: "Сделать минималистичный task manager" problem: "Задачи разбросаны по разным местам" style: product_vibe: - "minimal" - "clean" - "fast" technology: frontend: - "Next.js" - "TypeScript" architecture: approach: "modular monolith" documentation: required_files: - "README.md" rules: hard: - "код должен быть читаемым" - "README обязателен"
По сути, синтаксис тут очень простой:
есть имя секции;
внутри секции лежат поля;
поля описывают проект человеческим языком;
часть полей может быть списками;
часть может быть вложенными блоками;
всё это носит рекомендательный характер, а не является жёсткой спецификацией компилятора.
То есть Vibe++ — это не «язык с формальной грамматикой», а понятный шаблон мышления, который LLM хорошо читает.
Что важно в Vibe++
На мой взгляд, в таком формате особенно полезны три вещи.
1. Разделение обязательного и желательного
Если написать всё одним абзацем, модель сама будет решать, что важно. Если же отдельно есть:
hard- обязательно,firm- желательно,soft- по возможности,
то результат обычно становится более управляемым.
2. Отдельный блок про документацию
Новички почти никогда не просят README, описание структуры проекта, комментарии и фиксацию архитектурных решений. А потом сами же не понимают, что им сгенерировали.
Если явно сказать модели: «добавь README, опиши архитектуру, комментируй только неочевидное», результат становится намного удобнее для дальнейшей работы.
3. Описание стиля и контекста
LLMнеплохо работают со словами вроде «минималистичный», «спокойный», «быстрый», «перегруженный», «MVP», «без лишней магии», «без сложной архитектуры». Это не строгие инженерные термины, но они задают правильный вектор.
Что Vibe++ не делает
Важно проговорить и ограничения.
Vibe++:
не делает код автоматически хорошим;
не заменяет архитектурное мышление;
не превращает новичка в senior-разработчика;
не гарантирует продакшн-качество;
не отменяет необходимости проверять результат.
Это всего лишь способ лучше формулировать задачу. Но даже этого, как показывает практика, уже немало.
Что мне кажется главным
Главная мысль очень простая: между хаотичным prompt и нормальной постановкой задачи есть промежуточный слой, и Vibe++ можно рассматривать именно как такой слой.
Не строгий стандарт. Не «новый язык будущего». Не попытку заменить ТЗ, PRD и архитектурные документы. А просто удобный, понятный и рекомендательный способ оформить свои намерения так, чтобы модель с большей вероятностью поняла, что именно вы от неё хотите.
И если это поможет новичкам хотя бы немного лучше управлять результатом, то, как по мне, идея уже не зря появилась.
P. S. Кстати, для управления изменениями в коде, можно ввести отдельный блок с описанием ошибки, но это предлагаю обсудить.
UPD: https://stukalin.ru/vibepp/vibepp.md - описание v0.1
Комментарии (59)
rsashka
20.04.2026 11:46это не язык, а описание структуры ТЗ или отдельно взятой задачи (если что, извините :-) ) )
bormee Автор
20.04.2026 11:46=) Пусть новички думают, что знают язык программирования. Но формально, конечно же, это пока структура, не язык, вы правы, но кто знает, может мы совместно сделаем язык. Главное начать.
rsashka
20.04.2026 11:46Чтобы начать что-то делать, нужно понимать что, как и зачем. Вы можете это сформулировать? Или учитывая контекст вашей статьи, “написать программу”, что как и зачем нужно разрабатывать подобный язык программирования :-)
bormee Автор
20.04.2026 11:46Ну, например, я бы с радостью услышал предложение о том, как вкрячить в Vibe++ исправление ошибок и управление техдолгом, бэклогом. Кстати, отличная у меня идея про блок backlog, чтобы система сразу знала к чему готовиться =)
rsashka
20.04.2026 11:46беклог, это не про кодирование, а про планирование. И к непосредственному программированию имеет слабое отношение
bormee Автор
20.04.2026 11:46Ну давайте поспорим. Если знать к чему готовиться, то сразу закладываешь в архитектуру нужные модули. Например, если бы в моем примере я заложил функцию управления кубиком, то LLM мне бы сразу предусмотрела модель, управляемую, сделала бы нужные хелперы (пустые), но сделала бы. Так что тут это не лишнее.
rsashka
20.04.2026 11:46Сложно об этом спорить, так как на вкус и цвет все фломастеры разные.
Просто по моему опыту не имеет смысла ставить очень долгоиграющие задачи без промежуточного контроля. И это в случае людей, а для LLM это вообще фундаментальное ограничение на длину контента (качество, время, деньги).
В этом случае длительное планирование становится бессмысленным для разработчика и нужно только для руководителя проекта или архитектора. Поэтому и затаскивать следующую задачу из беклога для разработки большого смысла не имеет.
Единственный вариант, когда в этом появляется смысл, это когда вы делаете не язык программирования, а какую нибудь автономную систему разработки кода (скайнет, например :-) ) и у нее есть функциональность системного анализа и планирования работ. Разбивает на подзадачи, анализирует на согласованность и взаимное влияние.
Но даже в этом случае беклог, как отдельная подсистема, будет нужна только для взаимодействия с внешним миром минуя репозитарий кода. А если все и так находится вместе с кодом, то можно обойтись несколькими файлами и “беклог”, как система, становится ненужной.
bormee Автор
20.04.2026 11:46Ну вот простой пример. Вы делаете какое-то приложение, делаете его на русском языке, но при этом не закладываете файл локализации, потому что не думаете о том, что вам потом захочется сделать китайскую версию. Если в бэклог поместить мультиязычность, то LLM сразу создаст файл локализации, для одного языка. А потом просто хоп, сделает перевод на китайский и приложение будет поддерживать сразу два языка. Это касается доменного подхода к хранению данных, использование очередей и шардинга для высоконагруженных систем и т.п. Ставить цели надо масштабные.
Nehc
20.04.2026 11:46Ну да, а теперь оборачиваем все это в агент/сабскилл, что бы на любое пользовательское "А что, если сделать программу для фиксации результатов анализов и сбора информации? Сделай мне программу" следовало интервью, на выходе формирующее спеку... Ой, да это же plane mode получается! ;)
Не, ну а так-то и правда паркуа бы не па?bormee Автор
20.04.2026 11:46Же сью контант де ву ву а =) (фр.) Очень рад вас видеть.
Слушайте, хаос надо немного структурировать, ну как иначе? Пусть вайбкодят все, я же только за, но посмотрите примеры, разница же очевидна. Ну раз лучше работает, пусть пользуются.Следом добью Markdown с формальным описанием, а дальше будет круче. Скармливаешь шаблон описания в чат и говоришь, сделай мне ТЗ в этом формате, потом немного причесываешь и в светлое будущее стартап запускаешь.
GameHipe
20.04.2026 11:46Можно сказать что это Obsidian для ИИ, но в более строгой форме, интересно в каком направлении всё это пойдёт?
Кстати крутой пост, не ожидал что в 90% постах про ИИ найдётся такое золото!bormee Автор
20.04.2026 11:46Мерси вери мач. Приятно. Жду помимо мёда ещё и предложения и дополнения.
Dreams_and_magic
20.04.2026 11:46Спасибо за статью:)
Vibe++ это очень детальный формат, и в полном виде для моего скромного проекта может быть overkill.
Сделал себе PLANNING.md и там два формата:Базовый - краткий чеклист.
Полный - Vibe++ для проекта с полной структурой и примером использования.
Посмотрим, насколько это пригодится:)
bormee Автор
20.04.2026 11:46Желаю удачи, поделитесь потом результатом. Вот тут описание поподробней https://stukalin.ru/vibepp/vibepp.md
visirok
20.04.2026 11:46Я крайне редко пишу негативные комментарии. Но тут не удержусь.
Чем дальше я продвигался по статье, тем больше надеялся, что в конце автор пояснит, в чём суть шутки. А оказывается, и автор и комментаторы воспринимают это серъёзно.
Если кто-то дочитает до моего комментария, и также будет считать, что это серьезно, ответьте мне пожалуйста:
в то время как Vibe++ вариант всего 50 Мб
Даже если учесть, что наверняка львиную долю этих 50 Мб составляют файлы или кодировки изображений, разве это не маркер, что автор вас разыгрывает?
А автор и читателей не смущает, что подобного результат можно добиться, если из всего текста на Vibe++ оставить (по моим оценкам) пять предложений? Остальное можно просто выкинуть или заменить другими словами.
Рискну предположить, что и одного предложения хватит. LLM видела тысячи страниц с анимацией кубика Рубика и наверняка справится.
А что делать, если страниц надо много, и они должны взаимодействовать? Во что превратиться тогда ваше Vibe++ описание?
Если Вы, автор, написали это на полном серъёзе, то поверте мне: это тупик.
Посмотрите, что делают другие, например, вот сюда: https://codespeak.dev/
Поверьте, мне, я знаю о чем говорю. Я разрабатываю много проектов, практически не прикасаясь к коду руками. Один такой проект описан недавно мной на Хабре: https://habr.com/ru/articles/1016102/
bormee Автор
20.04.2026 11:46Не шутка потому что это инструкция для начинающих, ну что вы ей богу. Тому, кто знает что такое код - глупо объяснять как вайбкодить, он справится с этим и сам. Хотели пропиарится - класс. Сайт ваш мне понравился, я люблю такое, у меня похожий.
visirok
20.04.2026 11:46Хотели пропиарится - класс.
Не люблю оправдываться, но сам, как автор на Хабре, уже переживал нападки от комментаторов, которые, как потом выяснялось, были «не в теме». Поэтому упреждающе ответил на вопрос «А ты кто такой?».
bormee Автор
20.04.2026 11:46И чем идея отличается от идеи по вашей ссылке? Если бы я ее видел раньше, не стал бы писать статью, а с радостью описал этот сайт.. Но еще раз повторюсь - это я написал для тех, кто только постигает азы, ну вчитайтесь в введение.
visirok
20.04.2026 11:46И чем идея отличается от идеи по вашей ссылке?
Я не уверен в успехе начинания Андрея Бреслав (это его стартап). С ним, кстати последнее время несколько видео на YouTube опубликовано, например вот это: https://www.youtube.com/watch?v=0lBmqwlkWVI Советую посмотреть.
Подозреваю, они надеются как-то научить LLM (возможно через тюнинг, возможно с помощью RAG) генерировать по спекам код и наоборот.
А Вы просто предлагаете очередной формат для спецификаций в надежде, что он лучше других подойдет для LLM. А почему? Где аргументы? Где эксперименты? Где сравнения с другими?
В общем, погорячились Вы с таким сравнением.
Dron007
20.04.2026 11:46блок
technologyфиксирует стек;блок
architectureзадаёт желаемый подход;
У меня сложилось как раз противоположное ощущение. Не нужно стремиться фиксировать и навязывать своё, уж тем более этого не стоит делать новичкам. Он там где-то может услышал что-то и наплетёт ей всякого. Модель очень редко возражает, чаще подчиняется и старательно делает любой бред. Много раз уже у меня было такое, что если ей сказать "предложи решение, подход", описав не задачу, а проблему или цель, которую хочется получить, то результаты прямо удивляют в хорошем смысле. Это касается даже интерфейсов. Я не являюсь дизайнером, да и дизайнеры часто чушь городят, а модель бывает просто из миллионов известных ей решений предлагает что-то вполне подходящее, если требования не очень жёсткие, конечно. Если прямо хочется что-то очень конкретное, бывает намного сложнее ей объяснить.
Так что вместо фиксации стека и архитектуры, предлагаю больше общаться с моделью, не жалея токенов в режиме планирования. Чтобы их всё-таки сэкономить, можно в другом чате поизучать явно тёмные моменты, ведь она знает практически всё, что знает человечество, а мы - нет. Спрашивайте совета как при общении с толковыми программистами. Уточняйте сомнительные моменты. Если видите, что это не то, что нужно, конечно, смело говорите ей просто как сделать. Но всегда полезно предложить ей потом оценить правильность подхода, поискать недоработки и сомнительные места даже когда план уже готов. Она может выдавать иногда улучшения ради улучшений, тут уже от качества модели многое зависит.
И вот еще в который раз удивляюсь зачем прямо сразу всё описывать. Это невозможно и так не делаются продукты и даже люди эволюцией получались постепенно. Даже обычная разработка давно использует спринты и прочее, когда команда тупо не знает толком куда будет двигаться дальше и с какой скоростью. Это ж не вагоны разгружать. Любой продукт - развивающаяся система. Но то, что с командой занимало бы недели и месяцы, с моделью может занять часы, поэтому не выходя из потока и не теряя энергии можно проверять сразу множество вариантов или даже полностью менять концепцию. И цена изменения архитектуры даже становится уже не такой большой, соответственно и значимость её выбора уменьшается.bormee Автор
20.04.2026 11:46Возможно вы правы, вам никто не мешает написать в ветке: выбери оптимальный стек технологий для проекта, учитывай нагрузку и мой КТС, а дальше описываешь КТС.
BlackSCORPION
20.04.2026 11:46Если новичок хочет когда то стать специалистом, ему надо учится думать самому и задавать вопросы.
Это как разница между StackOverflow copy paste coding, и посмотреть 10 вариантов решения, понять каждое, понять где лучшее для твоео случая и почему.
В первом случае получается что то рабочее, но ты не знаешь как и почему это работает. Во втором случае ты получаешь что то рабочее но ты уже знаешь как и почему оно работает, почему это лучшее решение для задачи, и ты на шаг ближе к тому чтобы быть специалистом.
bormee Автор
20.04.2026 11:46Vibe++ это инструкция с описанием того, что нужно знать модели. Новичкам будет легче, будь понятно с чего начать, прежде чем сожгут время
BlackSCORPION
20.04.2026 11:46Я о том что работать с ИИ в режиме сделай мне это и то, это и есть сжигание времени.
Приведу пример, у меня 15 лет стажа в программировании и 0 в ремонтах и серьёзных умных домах. Но я делаю ремонт и хочу крутой умный дом, а специалисты которые могут такое сделать получают как минимум не меньше меня, у меня нет возможности их нанять. Приходится разбираться самому.
Так вот, когда я работаю с ИИ в программировании, Я вижу как "тупит" ЛЛМ. Я выступаю в роли техлида/тимлида, а ЛЛМ/агент в роли крайне исполнительного джуника. Я знаю на что смотреть когда делаю ревью ИИ кода, я знаю какой мне код нужен и могу поставить чёткую ясную задачу, легко вижу когда решение ей соответствует, когда это хорошее решение, когда нет, почему нет.
С ремонтом ситуация ровно наоборот. Каждый ответ ЛЛМ выглядит правильным и логичным. Но стоит начать задавать вопросы как выясняется что это даже не ответ а сферический конь в вакууме. Вменяемый ответ получается только после десятков часов общения плюс десятки часов размышлений, когда я достаточно потыкал тему с разных сторон, и уже в ней ориентируюсь.
Мой комментарий как раз об этом, если Вы новичок который хочет стать специалистом, учитесь критическому мышлению а не вайбкодингу, задавайте вопросы а не раздавайте задания, чтобы ставить хорошие задания надо хорошо разбираться в теме.
bormee Автор
20.04.2026 11:46Есть люди, которые не хотят вообще программировать, но хотят запустить стартап. И у них теперь есть инструмент в виде относительно бесплатного ИИ. Я согласен, что глюки моделей, ошибки в коде, уязвимости - все это будет, но этого точно будет меньше, если правильно поставить задачу.
BlackSCORPION
20.04.2026 11:46Если речь о новичках которые не хотят быть специалистами, ИМХО, легче поговорить с ЧатЖПТ, описать что ты хочешь, попросить придумать решения и описать что они дают. Когда понимание ЧатЖПТ выглядит достаточным, попросить составить промпт для кодинг агента. Это интуитивно понятнее и проще чем пытаться описывать задачу самому, и нет желания разбираться в деталях.
Что то типа, есть идея для бизнеса, хочу продавать нумерологические прогнозы через телеграм бота, помоги мне составить техническое задание/BRD. Задавай вопросы, один за раз, пока у тебя не будет достаточно информации чтобы составить детальное, качественное техническое задание, когда будешь готов сделай ТЗ как маркдаун файл который я могу скачать и отдать агенту на исполнение.
DmitryOlkhovoi
20.04.2026 11:46Более технический подход - скетч программирование))
https://github.com/DmitryOlkhovoi/Sketch-programming// @sketch:reactComponent // @ext:tsx Component Count props add = 0 state count = 0 effect { console.log("Component mounted"); cleanup { console.log("Cleanup"); } } <div onclick="count += add"> Will add {add} </div> <div> Current count: {count} </div>bormee Автор
20.04.2026 11:46Такие фреймворки понятны программистам. Я люблю фреймворки, с детства их создаю. Vibe++ - это естественный слабо структурированный язык, даже больше шаблон, позволяющий просто немного поток мыслей непрограммиста направить в нужное и понятное LLM русло.
DmitryOlkhovoi
20.04.2026 11:46Ну там можно описать любой язык, придумать свой. Там где-то есть пример. Но плагин надо обновить на новое апи, подзабил я немного))
VGoudkov
20.04.2026 11:46Вы сильно переоцениваете возможности и желания типового непрограммиста. Да и программиста тоже. Никто не хочет писать с нуля, да ещё и используя новый язык, который перед началом работы надо загрузить в мозг. Пусть даже это спека в формате YAML. Я, заради интерса, вставил спеку в Word. 7 страниц. Да, можно убрать лишние вертикальные интервалы, будет 5. Это всё равно очень много. Пять страниц технического описания - в реальном проекте не каждый аналитик напишет за полный рабочий день.
Это может взлететь в режиме опросника - когда отдельный генератор или сама LLM задаёт вопросы по такой спеке, а пользователь (в данном случае - будущий потребитель продукта) показывает пальчиком - это мне надо, это не надо. И то после первых пятнадцати минут скажет "что-то дофига сложно", потому как устанет.
bormee Автор
20.04.2026 11:46Да я так и думал, сделать в виде опросника. Но вы упускаете подход, когда вы скармливаете описание в формате md в LLM, говорите, просите заполнить "паспорт проекта" на Vibe++ и потом его ручками рихтуете и запускаете в продакшн.
Megamort001
20.04.2026 11:467 страниц реально ту мач. Я как яркий представитель вайбкодера, который класс от библиотеки не отличит, и до сих пор не знает правила нормальности в СУБД, могу сказать, что максимум только одна страница залетит)
Ну и еще с точки зрения системного анализа наверно имеет смысл в вайб++ добавить выпадающий список сразу "что система создаваемая должна делать": по критериям операционных либо линейных функций систем, либо гибридная. это может быть на уровне языка осин, но и это уже значительно бы облегчило экономию токенов в используемом ИИ-ассистенте. в целом поддержу ораторов, что лень правит миром, и жду выхода вайб++ в виде какой-нибудь утилиты/приложухи, или как там у вас это называется?)))bormee Автор
20.04.2026 11:46Ну так и надо делать 1 страницу, но в правильной структуре, которую я предложил и описал. Эффект будет иной.
Sega-mobile
20.04.2026 11:46Может вам будет интересно мнение вайб-кодера:
ИМХО у идеи огромный потенциал - нам нужна прокладка между человеком, который не до конца понимает что он хочет и как это объяснить, и роботом, который не до конца понимает что от него хотят и вместо того чтобы спросить пытается угадать.
ИМХО надо избавиться от английского - не вижу смысла в использовании другого языка, все параметры - кирилица, так проще русскоязычным
Видится мне это в виде программы-оболочки (типа visual studio code)
Пользователь заполняет необходимые поля, которые ему предлагается заполнить (в статье указаны) и по правому клику на каждое свое утверждение, просьбу, предложение, мысль может установить предлагаемые оболочкой параметры (ограничения, обязательные условия, стиль и прочее уже заранее заготовленное и адаптированное под понимание робота)
Иметь возможность составлять не ТЗ "от и до", а "текущий промт" - начальные установки, с которых начинается работа над любой подзадачей внутри большого проекта. (Если интересно могу показать свой "текущий промт", с которого начинается каждый новый чат с роботом. Внутри текущего промта я ставлю роботу конкретную задачу (каждый раз разную, но над одним и тем же проектом). Было бы здорово иметь оболочку, в которой можно было управлять не только всем ТЗ, но и задавать перманентные условия, требования, ограничения.
Иметь готовые шаблоны подходящие под большинство типовых задач. Я имею в виду возможность выбрать не "ЧТО должно быть", а "КАК должно быть"
В этом плане можно очень много чего предложить пользователю и помочь новичку избежать глупых ошибок, а также помочь продвинутому заниматься вайбкодингом в более удобной и функциональной среде, нежели просто строка промта
bormee Автор
20.04.2026 11:46Английский язык не обязателен конечно же, но его лучше модели понимают, т.к. терминология устоявшаяся, но вам никто не мешает такой же yaml файл сделать полностью на русском. Конструктор и собственная ide для вайбер-кодеров это да или как плагин в существующие. Надо подумать
quarus
20.04.2026 11:46Если будете что-то изменять или разрабатывать, по возможности - в промпте сохраните "устоявшуюся терминологию" на английском...
plyuschevmax
20.04.2026 11:46Сделал по примеру https://stukalin.ru/vibepp/vibepp-prompt-rubik.txt себе vibepp.yaml в https://github.com/Quantum-Insight-Lab/aeon_map_system. На 845 строк файл вышел...
Интересно, с текущей скоростью Composer 2.0 Fast такой проект в 2-3 человека за неделю соберут?
FixicusMaximus
20.04.2026 11:46Вайб-идеи кончились? Вернулись к коду? К кривому, но все же коду. А как же agi? Все, не ждем?
bormee Автор
20.04.2026 11:46Пришли к структуре.
Action:
Обязательное: казнить
Ограничение: нельзя помиловать
FixicusMaximus
20.04.2026 11:46По мне, лучше обычный код писать, у него структура структурированнее
bormee Автор
20.04.2026 11:46Совершенно с вами согласен. Я тоже люблю код. Vibe++ я придумал именно для тех, кто не собирается учить код, но желает попасть в Айти =)
janvarev
Учитывая количество статей на Хабре про ИИ и вайбкодинг - лично я этой неожиданно ставлю "лайк".
Фактически это что-то в духе spec-driven development (для него есть фреймворки). Но тут заточено под более любительскую разработку (а не полное TDD + куча ограничений) - и лично мне представляется более гибкой и удобной. Имхо по сути весь Vibe++ - список требований к генерации нейросети, которые неплохо бы не забыть (уровень документированности, используемые технологии и пр.)
bormee Автор
Ой, спасибо. Ждал первого комментария и взял даже тряпочку, чтобы обтираться =) А тут столько добра. Спасибо большое.
plyuschevmax