What vibe coding actually is, and where it stops working

Short version: vibe coding is building software by describing what you want in plain language and letting a model write the code. You stay the author of the product and decide what goes in it. You do not spend a year learning syntax first

That definition is the easy part. The useful part is knowing where the method holds and where it falls apart, because it does fall apart, and always in the same five places

The definition, without the hype

Andrej Karpathy named it in February 2025, describing a way of working where you talk to the model, accept what it writes, and mostly stop reading the code line by line. The name stuck because it described something people were already doing quietly

Source: Andrej Karpathy named the term in a post on X, February 2025

Strip the marketing and you get three properties

You describe outcomes, not steps. Not "add a flex container with 40px gap", but "these blocks are cramped, give them room"

The model writes and edits the files. Not snippets you paste. Actual files in an actual project

You judge the result by running it. The browser, the terminal output, the bot replying in the chat. Running the thing is the review

What it is not: a no code builder. Builders give you blocks and a ceiling. Vibe coding gives you a real codebase you own, with all the freedom and all the responsibility that implies

How it differs from no code builders

They get confused constantly, and the difference decides which one you should pick

A builder is genuinely the better answer when the site is needed tomorrow, will never change, and does exactly what the builder already does. That case is real and more common than people in this field admit

Everything else favours owning the code, and the advantage compounds. The first project takes an evening. The second takes two hours, because the understanding transfers and a builder account does not

What the loop actually looks like

An honest walkthrough of an evening, because the abstract description hides where the time goes

You open a terminal in an empty folder and run git init. Then you describe the thing: what it is, who opens it, what happens when they do, what it must not do. Three or four sentences, specific

The agent writes files. You open the result and look at it. Something is wrong, because something always is. You describe the one thing that is wrong. It fixes it. You save

git add -A && git commit -m "landing renders, form does nothing yet"

Then you repeat that loop forty times. That is the whole method. The skill is not in the prompts, it is in noticing what is wrong and describing it in one sentence

Roughly eighty percent of the evening goes into decisions and text, not code. People are surprised by this every single time

Where it stops working

Five failure modes. All five are predictable, which means all five are manageable

The model invents things that do not exist

It will confidently import a library that was never published, or call a method that does not exist in the version you have. It looks right: correct naming, correct shape, and nothing to actually call

Catch it by opening the project page of anything unfamiliar. Thirty seconds, and it saves an hour of debugging a thing that cannot work

Its knowledge of any API is frozen and slightly stale

Interfaces change. A model trained months ago writes the old call with total confidence. This is invisible in review and only shows up at runtime, and the error text rarely points at the real cause

The fix is not a better prompt. It is you handing the model current documentation: paste the page, or point it at the docs

One edit breaks something that worked yesterday

You ask for a button change, it touches a neighbouring file, and login stops working. Nobody notices until someone tries to log in

This is not solved with prompting. It is solved with version control and the habit of saving after every working step. Then a rollback costs one command instead of an evening

The project outgrows what the model can hold

At ten files the model sees the whole project. At a hundred it sees a slice, edits that slice, and has no idea what it contradicts elsewhere. Fixes start fighting each other

Everyone hits this, at a different size, and sooner than expected. The workaround is a short project description you keep in a file and hand over at the start of each session: what lives where, what the rules are, what must never be touched

Security and money are not free

The model does not think about consequences by default. It will happily put a payment key in a file that ships to the browser, or trust a price that arrived from the client instead of the price list on the server

Nothing about that is exotic. It is the expected outcome of shipping payments without once asking what an attacker would try

The line, stated plainly

Things this method genuinely ships: landing pages that take payments, internal dashboards, Telegram and Slack bots, scrapers and reports, small SaaS with a few hundred users, anything where you are the only developer

Things it does not ship on its own: systems where a bug costs someone their money or their health, anything with real concurrency and real load, code that a team of ten will maintain for five years

The boundary is not the size of the code. It is the cost of being wrong

What it costs

A paid plan on one of the coding agents, twenty dollars a month at the entry tier, with higher tiers at a hundred and two hundred. Hosting is free until you have real traffic. A domain is about fifteen dollars a year

So around twenty five dollars a month to work seriously. The expensive part is not money, it is the evenings

What you still have to learn

Not syntax. Four other things, and they take a few evenings, not six months

How to go back. Version control, one commit per working step, and how to read what changed

Where your machine ends and a server begins. Why it works locally and not for anyone else, and what an environment variable is for

Why a password never goes in the code. And what to do when it already did

What happens when two people use it at once. The single most common reason a demo that worked falls over in public

Skip these and you will ship things that work exactly once, on your laptop, for you

How to tell a good session from a bad one

A good session has short steps and frequent saves. You know what changed and why. When something breaks you can name the last thing you did

A bad session looks like this: you ask for a fix, it does not work, you ask again, it half works, you ask a third time, and now three files have changed and nothing runs. The project is a pile

The rule that prevents it: after two failed fixes, stop asking. Roll back to the last working state and describe the task again, differently. The third attempt from a broken state has close to zero chance, and every attempt after that makes the pile bigger

Does the model actually understand what it wrote

No, and it does not need to for this to be useful. But that changes how you review

The model is confident regardless of whether it is right. Confidence carries no information here. So you cannot use its tone as a signal, and you should not ask "is this correct", because the answer is always yes

Ask differently. "Show me where this breaks with ten people using it at once" produces noticeably better output than "check this code". So does "what did you assume that I did not tell you"

The three prompts that carry most of the weight

Not a library of magic phrases. Three shapes that consistently produce better output than the alternative

Constraints instead of adjectives. "One accent colour, two text sizes, no icons" beats "make it look modern". Constraints remove the safe average answer, adjectives add to it

The failure question. "Where does this break with ten people at once" beats "is this code good". The first has a real answer, the second has a polite one

The assumption question. "What did you assume that I did not tell you" surfaces the decisions the model quietly made for you, and those decisions are where the surprises live

Everything else people sell as prompt engineering is mostly this, restated

Will this still work when the models change

The tools will change. The four things above will not, because none of them are about a particular model. Version control, environments, secrets and concurrency were true before any of this and will outlive whatever replaces it

What ages fastest is the tool names. What ages slowest is knowing what you are building and why

Common questions

Do I need to know how to code. To ship the first thing, no. To keep it running, you need the four things above. That is a few evenings, not a career change

Can I use the free tier. For the first steps yes. Serious work runs into limits quickly, and the twenty dollar tier is where most people settle

Is the code any good. Usually fine for its size and worse than it looks at scale. That is exactly why the boundary above matters more than the code quality debate

What if I do not understand what it wrote. Then ask it to explain that file in plain language before you accept it. Not understanding is fine early on. Not knowing that you do not understand is what causes damage

Will this replace developers. It replaces the part where a simple thing needed a developer for three weeks. Everything that was hard is still hard, and the hard part was never typing

Where to start tonight

Three steps, twenty minutes, no reading required

Create a folder and run git init in it. Write one sentence about who opens the thing and what happens when they do. Hand that sentence to an agent and look at what comes back

Everything after that is edits, and edits go one at a time