Vibe++ очень простой язык для промпт-программистов. А почему бы и не да?
Дисклеймер: ни на что не претендую, просто делюсь результатами своих размышлений с коллегами и приглашаю к диалогу. Примеры сгенерированы на 100% в ChatGPT в режиме Plus - Thinking.
Мои наблюдения за коллегами, друзьями и знакомыми не из ИТ, которые начинают работать с генеративными системами с целью написания кода, показывают, что даже те, кто раньше боялся подступиться к программированию, сейчас вполне амбициозно пишут промпты уровня: "А что, если сделать программу для фиксации результатов анализов и сбора информации? Сделай мне программу". А потом дорабатывают результат в духе: "Нет, не так, пусть работает на телефоне".
На выходе появляется результат, зачастую непредсказуемый, но вполне устраивающий новичков, которые тут же воздвигают себя на вершину графика Даннинга-Крюгера, потому что подобного результата люди, не написавшие в жизни даже std::cout << "Hello, world!";, раньше бы просто не достигли.
Андрей Карпати, один из founding members OpenAI, в феврале 2025 года ввёл термин vibe coding. Он описал подход, при котором код получается через естественный язык, быстрые итерации и работу "по ощущению", а сам такой подход, по его словам, неплохо подходит для небольших, условно "выходных" проектов, но не является прямой заменой продакшен-разработке. Второй посыл многие, как мне кажется, не услышали. Ну да ладно, я пишу не совсем об этом. Мне хочется помочь новичкам мыслить чуть более структурированно, и для этого я предлагаю Vibe++ - язык намерений, язык промпт-программирования, то есть слабо формализованный способ описывать задачи в виде понятного человеку и модели текста так, чтобы на выходе получать более предсказуемый результат.
Первый промпт отработал примерно за две минуты в том же режиме. Второй промпт генерировал результат примерно в два раза дольше. Но есть нюанс.
Если я вас хоть немного заинтриговал, то ниже коротко опишу, что именно я предлагаю.
Коротко, суть
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 и архитектурные документы. А просто удобный, понятный и рекомендательный способ оформить свои намерения так, чтобы модель с большей вероятностью поняла, что именно вы от неё хотите.
И если это поможет новичкам хотя бы немного лучше управлять результатом, то, как по мне, идея уже не зря появилась.