Дисклеймер: ни на что не претендую, просто делюсь результатами своих ргу. Примеры сгенерированы на 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