What is vibe coding? The original meaning, and when it is a good idea

What is vibe coding? It is building software by describing what you want to a model and accepting the code it writes without reading it. The term comes from a post by Andrej Karpathy, the machine learning researcher, on X on February 2, 2025, describing "a new kind of coding" where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists". Collins Dictionary made it its Word of the Year 2025. Since then the phrase has stretched to mean almost any programming with a model, which is where most of the confusion starts. This explainer gives the original definition, the line between vibe coding and model-assisted development, when it is safe, and the risks, citing the original sources.

Where the term comes from

Karpathy's post, as quoted in full by the developer Simon Willison, describes a very specific way of working. He talks to the editor by voice and "barely even touch[es] the keyboard". He asks for small changes like "decrease the padding on the sidebar by half" because he is "too lazy to find it". He always clicks "Accept All" and doesn't "read the diffs anymore". Error messages get pasted back to the model "with no comment". When the model can't fix a bug, he works around it or asks "for random changes until it goes away". His own verdict: "It's not too bad for throwaway weekend projects, but still quite amusing." He adds that it is "not really coding": he just sees stuff, says stuff, runs stuff and copies and pastes stuff, "and it mostly works".

Two details are worth keeping. The post names the tools he used: Cursor's Composer with a Claude Sonnet model, plus speech-to-text. And X dates the post February 2, 2025 at 23:17 UTC, while Willison's article, and pages that copy it, give February 6.

Collins announced vibe coding as its Word of the Year on November 6, 2025, defining it as the use of a model prompted by natural language to write computer code, and noting that "tech experts debate whether it's revolutionary or reckless".

Vibe coding vs model-assisted programming

Willison's article, published on March 19, 2025, argues that the term was already "escaping its original intent" and being applied to all forms of code written with a model's help. His working definition is narrow: "building software with an LLM without reviewing the code it writes."

The difference is not the tool but what you do with its output:

• Vibe coding: you judge the result only by whether it seems to work. You don't read the code, and often couldn't explain it.
• Model-assisted development: the model writes some or most of the code, but you review it, test it and understand it. Willison's rule is that he won't commit code he "couldn't explain exactly what it does to somebody else", and that if you reviewed, tested and can explain machine-written code, "that's not vibe coding, it's software development".

The same person can do both on the same day: vibe code a throwaway prototype in the morning, then use the same assistant carefully on production code in the afternoon. Our guide to the best coding assistants covers the tools for the second kind of work, and Claude Code vs Cursor compares two of the most common ones.

When vibe coding makes sense

Willison, who says he has published more than 80 experiments built this way, is enthusiastic about it in the right place. He sees it as a way for people without a computer science degree to "automate tedious tasks in their lives", and as the best way for experienced developers to build intuition about what models can and cannot do.

His conditions, written for people starting out:

1. Low stakes. Ask how much harm a bug or a security hole could cause, especially if other people will use the software.
2. Secrets. Anything that looks like a password or an API key needs care, which "means you need to understand how the code works".
3. Private data. Be sure you understand whether data could leave your machine.
4. Other people's services. Code that calls other platforms adds load and cost to them.
5. Your money. Be very careful vibe coding against anything billed by usage; Willison mentions people who ran up thousands of dollars in charges against an API without a billing limit.

Typical good uses: a one-off script to rename files, a personal dashboard, a prototype to show an idea to a developer, a small game for your kids.

The risks, and how to reduce them

The risks follow from the definition: if nobody reads the code, nobody catches what is wrong with it.

• Plausible but wrong code. Language models produce fluent output that can be false; the same mechanism behind model hallucinations can produce code that runs and quietly does the wrong thing.
• Security holes. Exposed keys, missing input checks and over-broad permissions are invisible if you never look.
• Code you can't maintain. Karpathy's own post says "the code grows beyond my usual comprehension". The next change, by you or by the model, gets harder.

Practical guardrails that keep the speed without the worst outcomes:

• Use a sandbox. Willison praised Claude Artifacts in March 2025 because code there runs in a locked-down frame that "can't make any network requests to other sites", and noted that tools like Cursor have "far less safety rails".
• Keep secrets out. Put keys in environment variables, never in the prompt or the code you share, and set spending limits on every paid API.
• Ask for tests, and run them. Even if you don't read the code, you can check behavior.
• Get a review before sharing. Willison's advice is to ask someone more experienced for a "vibe check" before you put anything in front of other people.

If you want to go from vibe coding to building properly with a model, start with how to use Claude Code and our prompt engineering basics: clear instructions and examples matter as much for code as for text.