Vibe++: A Very Simple Language for Prompt Programmers. Why Not?
Disclaimer: I am not claiming anything definitive here. I am simply sharing the results of my thinking with colleagues and inviting discussion. The examples were generated 100% in ChatGPT Plus — Thinking mode.
My observations of colleagues, friends, and acquaintances outside IT who are starting to use generative systems to write code show that even people who used to be afraid to go anywhere near programming are now writing fairly ambitious prompts like: "What if we made a program for recording lab test results and collecting information? Build me that program." Then they refine the result with something like: "No, not like that — make it work on a phone."
What comes out is often unpredictable, but perfectly satisfying to beginners, who immediately place themselves at the very top of the Dunning–Kruger curve, because people who had never written even std::cout << "Hello, world!"; in their lives simply could not have achieved anything like this before.
Andrej Karpathy, one of the founding members of OpenAI, introduced the term vibe coding in February 2025. He described an approach where code is produced through natural language, fast iterations, and working "by feel." According to him, this approach works reasonably well for small, casual, weekend-style projects, but it is not a direct replacement for production software development. I suspect many people missed that second part. But that is not exactly what I want to write about here. I want to help beginners think a little more structurally, and for that I propose Vibe++ — a language of intent, a prompt-programming language; in other words, a lightly formalized way to describe tasks in human- and model-readable text so that the output becomes more predictable.
The first prompt completed in about two minutes in the same mode. The second prompt took roughly twice as long to generate the result. But there is an important nuance.
If I have managed to make you even slightly curious, below is a short explanation of what exactly I am proposing.
In short: the idea
Vibe++ is not a new programming language, and it is not an attempt to create a universal standard. It is more of a recommended task-description format for LLMs that helps people express their intentions in a more structured way.
Put simply, the idea is this: instead of one long prompt like "build me an app, but make it beautiful, fast, and mobile-friendly," we break the task down into several clear blocks:
- what the project is;
- why it is needed;
- who will use it;
- what style is needed;
- which technologies are preferred;
- what architectural approach is desirable;
- which constraints must not be violated;
- how the result should be documented;
- what should count as a good outcome.
In other words, Vibe++ is not meant to "magically improve the code." It is meant to reduce chaos when defining the task.
For beginners, I think this is where its main value lies. Even if a person does not know how to program, they can still partially steer the result: not just ask the model to "make something," but provide context, boundaries, style, and expectations. That does not make them an engineer, but it does make the task description much better.
What is the benefit?
A typical prompt often mixes everything together: the goal, constraints, preferences, technology choices, interface style, and documentation requirements. The model, of course, tries to understand it all, but it has to guess what is important and what is secondary.
Vibe++ offers a simple idea: separate everything into meaningful sections so that both the person and the model can understand the task more easily.
For example:
- the project block describes what is being created in the first place;
- the purpose block explains why it is needed;
- the audience block defines the users and target audience;
- the style block communicates the mood and character of the solution;
- the technology block fixes the stack;
- the architecture block defines the desired approach;
- the documentation block says how to describe the code, README, comments, and architectural decisions;
- the rules block separates mandatory requirements, recommendations, and soft preferences.
In my view, this is especially useful for beginners. They rarely know how to formulate architectural requirements, but they can already say things like: "this is an MVP," "do not use external libraries," "make the code readable," "add a README," "do not overload the interface," and "keep the project structure simple." For the model, that is already much better than just "make it look nice."
What the syntax looks like
Vibe++ can be written in a regular YAML-like format. There is nothing complicated about it. The point is not formal strictness, but a clear structure.
A minimal example might look like this:
vibepp: "0.1"
project:
name: "FocusBoard"
type: "web-app"
summary: "A simple kanban board for personal tasks"
purpose:
goal: "Build a minimalist task manager"
problem: "Tasks are scattered across different places"
style:
product_vibe:
- "minimal"
- "clean"
- "fast"
technology:
frontend:
- "Next.js"
- "TypeScript"
architecture:
approach: "modular monolith"
documentation:
required_files:
- "README.md"
rules:
hard:
- "the code must be readable"
- "a README is required"
Explain with
In essence, the syntax here is very simple:
- there is a section name;
- fields live inside the section;
- the fields describe the project in human language;
- some fields can be lists;
- some can be nested blocks;
- all of this is advisory rather than a strict compiler specification.
So Vibe++ is not "a language with a formal grammar," but rather a clear thinking template that an LLM can read well.
What matters in Vibe++
In my opinion, three things are especially useful in this format.
1. Separating mandatory requirements from desirable ones
If everything is written in a single paragraph, the model decides for itself what matters. But if there are separate categories:
- hard — mandatory,
- firm — preferred,
- soft — nice to have,
then the result usually becomes easier to control.
2. A separate documentation block
Beginners almost never ask for a README, a project structure description, comments, or recorded architectural decisions. Then they often do not understand what was generated for them.
If you explicitly tell the model: "add a README, describe the architecture, comment only on non-obvious parts," the result becomes much easier to work with later.
3. Describing style and context
LLMs work reasonably well with words like "minimalist," "calm," "fast," "cluttered," "MVP," "no unnecessary magic," and "no complex architecture." These are not strict engineering terms, but they point the model in the right direction.
What Vibe++ does not do
It is also important to state the limitations clearly.
Vibe++:
- does not automatically make code good;
- does not replace architectural thinking;
- does not turn a beginner into a senior developer;
- does not guarantee production quality;
- does not remove the need to review the result.
It is just a way to formulate the task better. But in practice, even that is already quite a lot.
What seems most important to me
The main idea is very simple: between a chaotic prompt and a proper task description, there is an intermediate layer — and Vibe++ can be viewed precisely as that layer.
Not a strict standard. Not "the new language of the future." Not an attempt to replace technical specifications, PRDs, or architecture documents. Just a convenient, understandable, recommended way to express your intentions so that the model is more likely to understand what exactly you want from it.
And if that helps beginners gain even a little more control over the result, then, as far as I am concerned, the idea was worth proposing.