Is vibe coding real development?

It is a way of producing software, with its strengths and its blind spots. The useful question is not whether it is respectable but where it holds: excellent for starting, fragile for lasting.

Do I need to learn to code to use it?

Not to start, and that is the whole point. But the bigger the project gets, the more you need to describe precisely what you want — a separate skill, and one you can learn without writing a line.

Where exactly does the term come from?

From a public post by researcher Andrej Karpathy in early February 2025, describing how he built things by letting the tool carry him. The phrase spread everywhere within weeks.

Does it work for a professional site?

For building one, often yes. For maintaining it over two years, it depends entirely on what you put around it — backups, written instructions, checks.

Vibe coding: what it is, and where it breaks

You describe what you want, the AI builds it, and it works. It is exhilarating. Then one day it breaks, you open the project, and you understand nothing of what was written for you. You can neither repair it, nor explain it, nor even ask for help properly.

Vibe coding means describing what you want in plain language and letting the AI write the code, without reading it back. The term was coined in early 2025 by researcher Andrej Karpathy. The method works remarkably well until three specific moments where it turns on you.

Where the word comes from

The term was born in early February 2025, in a public post by researcher Andrej Karpathy, formerly head of artificial intelligence at Tesla.

He was describing a way of working he practised himself: talk to the tool, look at what comes out, run it again, copy and paste, and forget that the code exists at all. Let yourself be carried, literally.

The post was seen millions of times within days and the phrase spread everywhere. Today it describes a very concrete practice: describe what you want in plain English, let the machine produce the code, and judge the result by what it does rather than by what it contains.

Why it works so well at first

This has to be said plainly, because critics of the practice often forget it: it genuinely works.

Someone who has never written a line of code gets, in one evening, something that displays, that responds, that resembles what they had in mind. That was impossible three years ago. It is not an illusion, it is a real change.

And for a large share of projects — a presentation page, a form, an internal tool, a prototype to show around — this way of working is entirely sufficient. No need to complicate matters.

The problem is not the method. It is believing that it covers everything.

First moment it breaks: when you can no longer describe what you want

As long as the request fits in one sentence — “add a button that submits the form” — all is well.

The wall arrives when the request becomes a multi-storey intention: “when someone signs up, check the address does not already exist, send a confirmation message, and if the send fails, keep the signup anyway”.

At that point the gap between what you meant and what you asked becomes enormous, and it is invisible. The result works on screen. It will do something other than intended the day an edge case turns up.

That is not a code problem. It is a wording problem — which is why the skill that matters most is not knowing how to code, but knowing how to describe.

Second moment: when you can no longer check

Vibe coding rests on a simple principle: you judge by the visible result.

That principle holds as long as everything that matters is visible. It gives way as soon as part of the work does not show: a backup that never fires, data stored wrongly, an error case never tested, a security key written in the wrong place.

None of that appears on screen. The site looks perfect. The problem already exists and is waiting for its moment.

This is why “it works” is not the same as “it is fine”. The difference is paid later, and it is paid dearly when the site breaks.

Third moment: when the conversation outgrows its own memory

This one surprises everybody, because it has nothing to do with how hard the project is.

A conversation with an AI has a size limit. Beyond it, the oldest content drops out of view. A decision taken two hours ago — “we do not touch that part” — stops being applied, with nothing to signal it.

And vibe coding produces exactly that kind of conversation: long, continuous, everything decided as you go and nothing written down elsewhere. The further you go, the more the beginning fades.

That is why the same tool, on the same project, seems to “get dumber” late in the day. It is not getting dumber: it can no longer see the beginning.

What to take from it

Vibe coding is not a bad method. It is a method without memory and without a safety net — perfectly suited to a prototype, and perfectly unsuited to anything meant to last.

So the right question is never “am I doing vibe coding or real development”. It is: does what I am building need to survive the conversation that produced it?

If the answer is no, carry on exactly as you are, it is fine. If the answer is yes, three things are missing — somewhere to write what must survive, a way to check what does not show, and a way back. None of the three requires knowing how to code.