Дисклеймер: не претендую на открытие, просто делюсь результатами своих экспериментов. Все примеры сгенерированы в ChatGPT в режиме Plus — Thinking.
Наблюдая за друзьями и знакомыми, далёкими от IT, которые начинают использовать генеративные модели для написания кода, замечаю интересную тенденцию. Даже те, кто раньше боялся программирования, теперь уверенно формулируют запросы вроде: «Сделай программу для хранения результатов анализов». А потом уточняют: «Нет, пусть она работает на телефоне».
На выходе — часто непредсказуемый, но вполне приемлемый результат. И многие новички тут же попадают на пик графика Даннинга-Крюгера: ведь раньше они не смогли бы написать даже std::cout << "Hello, world!";, а теперь получают работающее приложение.
Андрей Карпати, один из основателей OpenAI, в феврале 2025 года ввёл термин vibe coding — подход, при котором код создаётся через естественный язык, быстрые итерации и «ощущения». По его словам, это подходит для небольших, «выходных» проектов, но не заменяет продакшен-разработку. Вторую часть посыла многие проигнорировали. Но я пишу не об этом.
Мне хочется помочь новичкам мыслить структурированнее. Поэтому я предлагаю Vibe++ — язык намерений, то есть слабо формализованный способ описывать задачи так, чтобы ИИ выдавал более предсказуемый результат.
Начну с результата. Я подготовил два примера: один — по обычному промпту на естественном языке, второй — по структурированному промпту на Vibe++. Оба запроса запускались впервые, без доработки кода после генерации.
Первый промпт обработался за две минуты. Второй — примерно в два раза дольше. Но есть нюанс.
Версия на естественном языке заняла 500 Мб в Google Chrome, а версия на Vibe++ — всего 50 Мб. Для меня это показатель эффективности сгенерированного кода.
Если вы заинтересовались — ниже кратко объясню, что такое Vibe++.
Коротко: суть
Vibe++ — это не новый язык программирования и не попытка создать универсальный стандарт. Это рекомендательный формат описания задачи для LLM, помогающий человеку чётко выразить свои намерения.
Вместо одного размытого запроса вроде «Сделай приложение, красивое, быстрое, для телефона» мы раскладываем задачу на понятные блоки:
- что за проект;
- зачем он нужен;
- кто будет им пользоваться;
- какой стиль нужен;
- какие технологии предпочтительны;
- какой архитектурный подход желателен;
- какие ограничения нельзя нарушать;
- как документировать результат;
- что считать хорошим итогом.
Vibe++ не улучшает код магически. Он уменьшает хаос при постановке задачи.
Для новичков в этом и есть главная польза. Даже без навыков программирования можно задавать контекст, рамки, стиль и ожидания. Это не делает человека инженером, но делает запросы гораздо эффективнее.
В чём польза?
Обычный промпт часто смешивает цель, ограничения, пожелания, технологии и стиль. Модели приходится догадываться, что важно, а что — нет.
Vibe++ предлагает простое решение: разнести всё по смысловым блокам. Это упрощает понимание как человеку, так и модели.
- project — что создаётся;
- purpose — зачем это нужно;
- audience — кто пользователь;
- style — настроение и характер решения;
- technology — предпочитаемый стек;
- architecture — архитектурный подход;
- documentation — как оформлять код, README, комментарии;
- rules — разделяет обязательные требования, рекомендации и пожелания.
Новички редко формулируют архитектурные требования, но могут сказать: «Это MVP», «Не используй внешние библиотеки», «Сделай код понятным», «Добавь README», «Не перегружай интерфейс». Для модели это уже намного лучше, чем «сделай красиво».
Как выглядит синтаксис
Vibe++ можно писать в YAML-подобном формате. Никакой строгой грамматики — только понятная структура.
Минимальный пример:
Синтаксис прост:
- есть имя секции;
- внутри — поля на естественном языке;
- некоторые поля — списки или вложенные блоки;
- всё носит рекомендательный характер, а не является строгой спецификацией.
Vibe++ — не формальный язык, а шаблон мышления, который хорошо воспринимается LLM.
Что важно в Vibe++
1. Разделение обязательного и желательного
Если всё написать в одном абзаце, модель сама решает, что критично. А если явно выделить:
- hard — обязательно;
- firm — желательно;
- soft — по возможности;
— результат становится гораздо управляемее.
2. Отдельный блок про документацию
Новички редко просят README, комментарии или описание архитектуры. А потом не понимают, что им сгенерировали.
Если явно указать: «Добавь README, опиши архитектуру, комментируй только неочевидное» — результат становится удобнее для дальнейшей работы.
3. Описание стиля и контекста
LLM хорошо реагируют на слова вроде «минималистичный», «спокойный», «быстрый», «MVP», «без лишней магии». Это не инженерные термины, но они задают правильный вектор.
Что Vibe++ не делает
Важно понимать ограничения:
- не делает код автоматически хорошим;
- не заменяет архитектурное мышление;
- не превращает новичка в senior-разработчика;
- не гарантирует продакшн-качество;
- не отменяет необходимости проверять результат.
Это просто способ лучше сформулировать задачу. Но даже этого — как показывает практика — уже достаточно, чтобы заметно улучшить результат.
Что мне кажется главным
Главная идея проста: между хаотичным промптом и полноценной постановкой задачи есть промежуточный слой. Vibe++ — это и есть такой слой.
Не строгий стандарт. Не «новый язык будущего». Не замена ТЗ, PRD или архитектурным документам. А просто удобный, понятный и рекомендательный способ описать свои намерения — так, чтобы модель с большей вероятностью поняла, чего вы хотите.
И если это поможет новичкам хоть немного лучше управлять результатом — идея уже оправдана.
p.s. Для управления изменениями можно ввести отдельный блок с описанием ошибки. Это — тема для обсуждения.