What is vibe coding?

Describing software in plain English and letting an AI write it, without ever reading the code. The fastest way a non-technical CEO can get a working tool. Also the fastest way to ship something nobody understands.

A non-technical friend texted me a screenshot last week: a working expense tracker, running in her browser, that she "built" on a Tuesday night by talking to an AI for forty minutes. She has never written a line of code. She did not read a line of the code that runs her tracker. She has no idea what is inside it, and for what she is using it for, that is completely fine.

That is vibe coding. You describe what you want, the AI writes the code, and you judge the result by whether it works, not by reading how it works.

What it is (in plain English)

The phrase comes from Andrej Karpathy, a co-founder of OpenAI and the former head of AI at Tesla. On February 2, 2025, he posted a description of "a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." He was talking to the tool by voice, accepting whatever it produced, barely looking. He later called it a throwaway tweet. It stuck anyway. Merriam-Webster added it as slang in March 2025; Collins named it a word of the year.

The strict meaning is the one that matters to you: you are not reviewing the code. You state an outcome, the AI produces something, you run it, and if it does the job you keep it. If it does not, you describe the problem and let the AI try again. The work runs through a coding agent, a tool that can read files, write code, and run it on your machine, so the loop closes without you ever touching the code yourself.

The word has since blurred. Plenty of people now say "vibe coding" for any AI-assisted programming, including the careful kind where an engineer reviews every change. That is not what Karpathy meant, and the difference is the whole point for you. Real vibe coding means nobody read the code. That is a gift when the tool is disposable and a trap when the thing is doing real work.

Why CEOs care

For twenty years, getting a piece of custom software meant a budget, a hire, or a six-week agency quote. Vibe coding collapses that to an afternoon for one specific class of thing: the small internal tool you would never have justified paying for. A calculator your sales team needs. A page that turns a messy export into a clean one. A tracker for the one number you check every morning. You can have it today, by describing it.

The catch is the same sentence that makes it powerful: nobody read the code. That is why the boundary, not the tool, is the thing to learn. Vibe coding is the right call when the tool is internal, disposable, and touches nothing precious: a prototype, a personal tracker, a sales calculator that lives on one laptop. It is the wrong call the moment real money, customer data, passwords, or payments are involved, because a tool nobody understands will eventually break in a way nobody can fix, and you will not see it coming.

That is not caution for its own sake. In 2025, one AI app builder shipped hundreds of apps carrying security holes that exposed real people's personal data, and a coding agent at another company deleted a live production database it had been told not to touch. Those were not freak accidents. They are what happens when "it works" is the only check and the thing is doing real work. The line operators are settling on is simple: vibe the prototype, engineer the production.

Where you'll see it

• Your first build in Claude Code. The step-by-step is here, and a margin calculator is the right size to start.
• Every "I built an app this weekend and I can't code" story on X. Most of them are real, and most of them are this.
• The day someone on your team ships a small internal tool without filing a ticket. Treat it as a good sign, then ask the one question that matters: does this touch customer data or money?
• The argument your engineers are having about whether it counts as real engineering. It does not, and that is fine. It is a different tool for a different job.

What to do next

Build one throwaway tool this week so the idea stops being abstract: build your first software tool in Claude Code. Pick something internal that touches nothing precious, describe it, and let Claude write it. Then notice the moment your gut says "I should get someone to look at this before it goes anywhere real." That instinct is the entire skill.