When the thing is small, self-contained, short-lived and handles nothing sensitive. An internal tool that answers one question, a prototype that exists to settle an argument, a script run twice: in all of these, reading the code would cost more than it returns, and that is a defensible trade rather than a lapse.

When does it become a liability?

The moment somebody else has to change it, or the moment it touches customer data, money or credentials. Both of those move the standard from behaves correctly to is understood, and unread code cannot meet the second one no matter how well it passes the first.

Can it be done responsibly?

Yes, by deciding at the start which kind of thing you are building. Prototype or product, throwaway or maintained: the answer sets the standard, and the trouble almost always comes from a prototype quietly becoming a product without anyone marking the transition or revisiting what was skipped.

Glossary

Vibe coding

Vibe coding means building software by describing what you want and accepting what comes back, and whether that is reckless or sensible depends entirely on how long the result has to live.

In plain terms

Describing what you want, taking what you get, and not reading it closely. The name started half as a joke and stuck because it described something people were genuinely doing. Whether it is reckless depends on one thing, which is how long the result has to survive and who has to change it after you.

Why it matters

Because the argument about it is usually conducted at the wrong level. People debate whether the code is good, when the useful question is whether anybody will ever need to modify it, and a throwaway tool that answers one question this week is held to a completely different standard than something three people will maintain for two years.

How it works

The loop is describe, run, look, describe again, and the code is never really read. Progress is measured by whether the thing behaves, which for a small self-contained tool is a perfectly reasonable measure and is roughly how a spreadsheet has always been built.

It works well while the thing stays small enough to hold in your head as a behaviour. Once it has several parts that interact, describing a change stops producing the change you meant, because the description no longer pins down which of the interacting parts should move, and you cannot say more precisely without reading what is there.

The failure is not usually bad code, which is the common misdiagnosis. It is code nobody understands, including whoever produced it, so the first serious change costs more than a rewrite and the second one is a rewrite whether or not anybody admits it.

Security and correctness fail quietly rather than loudly. Something that behaves correctly on the cases you tried can still handle credentials badly, trust input it should not, or be subtly wrong on the case you did not try, and none of that is visible from watching it work.

One question decides it

The debate tends to be framed as a question of craft, which is why it does not resolve. One side points at genuinely useful things built in an afternoon by people who could not otherwise have built them, and the other side points at unmaintainable software running in production with nobody able to explain it. Both are describing real cases, and the disagreement is not about quality at all. It is about which column the thing was in, and the reason it feels unresolvable is that the column is frequently decided after the fact. Something built as a prototype gets shown to a customer, then to another, and at no point does anybody stop and say that the standard has changed. Marking that transition explicitly, and treating it as a decision that costs something, converts an argument about taste into a scheduling question, which is a much easier kind of argument to have.

Seen in the wild

A builder turning descriptions into working full-stack apps with database, authentication and storage included, aimed squarely at non-technical builders.
Lovable
A tool that generates a project, runs it in the browser and updates the live preview as you keep talking to it.
Bolt
A prompt-to-app generator that also hands the work into a real repository, which is the seam where this practice meets ordinary engineering.
v0

Common misconceptions

People assume

It is simply irresponsible.

In fact

It is appropriate for a large class of software that was never going to be maintained anyway. A tool built to answer one question this week, used by one person and discarded, does not need review, and holding it to production standards is its own kind of waste.

People assume

The risk is that the code is bad.

In fact

The risk is that nobody understands it, which is a different and more expensive problem. Bad code that somebody understands can be fixed incrementally; unread code that works cannot be changed with confidence by anyone, including the person who produced it.

Telling them apart

Vibe coding vs No code

Vibe coding

Real code is produced; nobody reads it.

No code

No code is produced; the platform holds the logic.

One leaves you with a codebase you do not understand, the other with no codebase at all, and those fail in opposite ways.

Questions

When is it fine?: When the thing is small, self-contained, short-lived and handles nothing sensitive. An internal tool that answers one question, a prototype that exists to settle an argument, a script run twice: in all of these, reading the code would cost more than it returns, and that is a defensible trade rather than a lapse.
When does it become a liability?: The moment somebody else has to change it, or the moment it touches customer data, money or credentials. Both of those move the standard from behaves correctly to is understood, and unread code cannot meet the second one no matter how well it passes the first.
Can it be done responsibly?: Yes, by deciding at the start which kind of thing you are building. Prototype or product, throwaway or maintained: the answer sets the standard, and the trouble almost always comes from a prototype quietly becoming a product without anyone marking the transition or revisiting what was skipped.