What is vibe coding? Where it works and where it falls short

Vibe coding means building software by describing what you want to an AI and never reading the code it writes. If the result on screen does the job, you accept it. If it does not, you ask again. The code itself stays out of sight.

A note first: I am the founder of Entrobase, a product where people build websites and apps with AI. At PNZ Medya, my agency, we build software as a team and we read the code. I look at the question of what vibe coding is from both sides, so keep that in mind as you read.

Below I cover where the term came from, where it works and where it is not enough on its own. At the end there is a prompt you can use before you ship something an AI wrote for you.

What is vibe coding and where did the term come from?

Andrej Karpathy coined the term in February 2025. He was part of OpenAI's founding team and later led AI at Tesla. In a short post on X he described a new way of programming.

His routine went like this. He said what he wanted and accepted the AI's changes without reading them. When an error appeared, he pasted the message back in as it was. In his words, he would almost forget that the code even existed.

The phrase spread fast, and Collins Dictionary named vibe coding its word of the year for 2025. Today it is used for everything from building an app without coding to any software work that involves AI. That breadth is the main source of confusion.

Is all AI-assisted coding vibe coding?

No, and this distinction is the most important part of this post. Developer Simon Willison put it clearly in March 2025. For him, vibe coding means building software with an AI without reviewing the code it writes. If you read it, test it and understand it, you are doing AI-assisted development.

The difference is not code quality but responsibility. With vibe coding you see the result, but nobody knows what the code does. With assisted development, a person stands behind the code and can explain it when needed.

Where does vibe coding actually work?

Karpathy's original post contains a line many people missed. He said the approach was fine for throwaway weekend projects. As the term spread, that caveat was mostly forgotten.

It's not too bad for throwaway weekend projects, but still quite amusing.

I think that sentence is the key to putting vibe coding in the right place. There are plenty of jobs where building without reading the code is fine:

• A working demo to show an idea to a client or your team.
• Small tools only you will use: a calculator, a converter, an internal report screen.
• Testing a screen flow: where users click and where they get stuck.
• Quickly finding out whether something can be built at all.

At PNZ Medya we show clients a working prototype before we start a project. People want to see something that works before they decide. Vibe coding has made that first step cheap for everyone, and that should not be underrated.

Where is vibe coding not enough on its own?

The trouble starts when something built as a demo quietly turns into a product. A screen that works in preview may not have been built to carry real user data. If nobody read the code, nobody knows what is missing either.

The parts that should never ship unread tend to be the same:

• Payments: where the amount is calculated and whether a user can change it.
• User data: what is stored and who can see it. Privacy laws such as GDPR add their own obligations.
• Login and permissions: whether one user can open another user's records.
• Secret keys: whether service keys are written into the code or sent to the browser.
• Backups and rollback: how you get back to the previous state when a change breaks something.

There is also maintenance. As code that nobody has read grows, every new request can break an earlier fix. Karpathy wrote in the same post that he sometimes could not fix a bug and simply worked around it. That is fine for a weekend project and a real problem in a product your customers use.

How to vibe code without knowing how to code

If you are not reading the code, other decisions have to take its place. Most software projects struggle because of scope, not code, and that includes what you ask an AI to build. This is the routine that works for me:

1. Write down the scope: the app's one main flow and what will not be in the first version.
2. Ask for one change at a time, and do not add features until the broken step works.
3. Start with test data, not real data.
4. After every change, walk through the main flow yourself from start to finish.
5. Before launch, show the payment, data and login parts to someone who can read code.
6. Find out at the start who keeps the code and the accounts.

The last item usually gets left to the end. With some tools the project lives only inside that platform, and leaving means rebuilding everything. In my own product the answer is simple: on Entrobase the code always belongs to the user, and you can download the project whenever you want.

I wrote about the app side of these steps, from preview to app store, in a separate post.

A ready prompt for a pre-launch check

If you cannot read the code yourself, you can have a separate AI chat do the first pass. Paste your project's code into the prompt below. The output is not an audit; it shows you which questions to ask someone who can read code.

Below is the code of an app I had an AI write. I did not write it and I cannot read it. Before I launch, I want to understand the risks.

Your task:
1. Explain in three sentences what the app does.
2. Look for problems in these areas: payments and price calculation, login and permissions, stored personal data, secret keys written into the code or sent to the browser, what happens when something fails.
3. For each finding, say where it is, why it is a risk and how serious it is (high, medium, low).
4. Do not fill gaps with guesses; list anything you are unsure about separately under 'needs checking'.
5. Finish with the five most important questions I should ask a developer who reviews this code.

If you use a technical term, explain it briefly.

Code:
[paste the code here]

The 'needs checking' list is often the most useful part of the output. Where the AI is unsure is exactly where a person should look.

Will vibe coding replace developers?

I do not think so, but it shifts where the weight of the job sits. As writing code gets cheaper, setting the scope, making the right call and owning the result become more valuable. Willison makes the same point: a developer's job is not just producing code but leaving code that demonstrably works and that others can understand.

Building Entrobase, I deal with the balance between model, cost and quality every day inside the product. AI sets up the average very quickly. The difference comes from the decisions of someone who knows the work: which flow matters, which data should not be stored, when to stop.

Vibe coding has become the fastest way to turn an idea into something that works. But what you build quickly and what you can ship safely are not the same thing. If you decide up front what is an experiment and what is a product, you get the real benefit of that speed.