What is vibe coding? Definition, workflow, and real examples

The phrase went from a throwaway social-media post to a word every engineering team argues about in under a year. Here is what it actually means, how the loop works, and where it quietly stops being a good idea.

New to cloud? CAMPUX is a free, build-first course. Start here →

Vibe coding is a way of building software where you describe what you want in plain language and an AI agent writes, runs, and revises the code, while you steer with high-level intent and review the result. The term was popularized in early 2025; it trades typing syntax for guiding, testing, and judging. That is the whole idea in two sentences, and the rest of this note is about the parts that sentence hides — where the practice shines, where it bites, and what you still owe the code that comes out.

The definition, in one paragraph

When you vibe code, you stop thinking in terms of functions and loops and start thinking in terms of outcomes. You tell the model something like "read this CSV and give me a chart of sales per month," and it produces working code. You run it. If the chart is wrong, you do not go hunting through the source — you tell the model what looked off and let it try again. Your attention sits at the level of does this do what I meant, not is this the right syntax for a list comprehension. The model owns the keystrokes; you own the intent and the verdict.

Where the term came from

The phrase comes from Andrej Karpathy, a well-known figure in machine learning, who described the habit in a short post in early 2025. He was talking about his own weekend projects: a loose, conversational way of programming where he leaned almost entirely on an AI model, spoke to it, accepted its changes, and barely read the code. He framed it as fun and a little reckless, good for throwaway things — not as a discipline for production systems. The name stuck because it captured something people were already doing but had not named. Within months it was in job descriptions, conference talks, and more than a few arguments about whether it counts as engineering.

It is worth being precise about that origin, because the term gets stretched. Karpathy's version was deliberately hands-off — the fun was in not looking closely. Most teams who say "vibe coding" today mean something more careful: prompt-driven development where you very much do read the output. Both are real; they just carry different risk.

The vibe-coding workflow, step by step

Strip away the hype and the loop is short. It goes intent, prompt, draft, run, refine — and then it circles back on itself until the thing works.

• Intent. You decide what you actually want, in human terms. This is the part no model does for you, and it is the part people skip. A fuzzy intent produces a fuzzy program.
• Prompt. You describe the outcome, plus any constraints that matter — the language, the inputs, the shape of the output.
• Draft. The agent writes the code. Modern tools do this inside your editor and can create several files at once.
• Run and test. You execute it against real input and see what happens. This is the heartbeat of the whole practice; without it you are just accepting text on faith.
• Refine. Something is off — an edge case, a wrong column, a crash. You describe the problem and the model revises. Then you run it again.

The last two steps repeat. What makes the loop fast is that the feedback is concrete: the program either does the thing or it does not, and you can see which in seconds. What makes it dangerous is that "it ran without crashing" and "it is correct" are not the same claim, and the loop can lull you into treating them as one.

A real example

Say you want a small script that scans a folder of images and renames each file to include the date the photo was taken. Traditionally you would look up the library that reads photo metadata, remember its API, handle the files that have no date, and get the string formatting right. Fifteen minutes of documentation, minimum.

Vibe coding it, you open your editor's agent and type roughly this:

# prompt to the agent
Write a Python script that scans ./photos, reads each
image's EXIF capture date, and renames the file to
YYYY-MM-DD_originalname. If a file has no date, leave
it alone and print its name so I can see which were skipped.

The agent returns a complete script — it picks a metadata library, loops the folder, handles the missing-date case you asked about, and prints the skips. You run it on a copy of the folder. Two files come out named oddly, so you tell it "the date should come from DateTimeOriginal, not the file's modified time," and it patches that one detail. Run again, correct, done. The task that was fifteen minutes of reading became two minutes of describing and checking. That gap — for small, testable, low-stakes work — is the real draw.

The model can write the code in seconds. Deciding whether the code is right is still your job, and it always will be.

Traditional coding vs vibe coding

The two are not rivals so much as different altitudes. Here is the honest comparison — what you produce, what you review, and where the risk lives.

The honest limits

Here is the part the demos leave out. A model will hand you code that looks finished and reads well and is quietly wrong — an off-by-one, a missed edge case, a query that opens a security hole, a dependency it invented. It does this with total confidence, because producing plausible text is exactly what it is built to do. None of that shows up until you read the code or run it against the case that breaks it.

So the limits are simple to state and easy to ignore. You still have to read the output, or at least test it hard enough that a wrong answer cannot hide. Unreviewed vibe code that ships to real users is a liability, not a shortcut — the time you saved writing it comes back with interest the first time it fails in front of someone. And the more the code matters — money, personal data, anything you cannot easily undo — the more the review stops being optional. Vibe coding lowers the cost of producing code. It does not lower the cost of being wrong, and knowing the difference is most of the skill.

None of that is an argument against the practice. It is an argument for using it where it fits: to move fast on the small, testable, reversible things, and to slow down and read carefully everywhere else. The engineers getting the most out of it are not the ones who trust the model — they are the ones who know exactly when not to.

Questions people also ask

What does vibe coding mean?

Vibe coding means building software by describing what you want in plain language and letting an AI agent write, run, and revise the code. You stay at the level of intent — what the program should do, whether the result is correct — while the model handles the syntax. It works best for small tools, prototypes, and throwaway scripts where you can test the output quickly.

Who coined the term vibe coding?

Andrej Karpathy popularized the term in early 2025 in a short social-media post describing a loose, conversational style of programming where you lean on an AI model and barely look at the code. He was describing his own hobby-project habit, not proposing a formal methodology, and the phrase spread from there into wide use.

Is vibe coding good or bad?

It is neither on its own; it depends on the stakes. For a personal script, a prototype, or exploring an idea, vibe coding is fast and genuinely useful. For code that ships to real users or handles money or data, unreviewed output is a liability — the model can produce something that runs but is wrong, insecure, or fragile. The practice is good when you still read and test what comes out.

Do you still need to know how to code to vibe code?

To do it safely, yes. You do not need to remember every syntax detail, but you need to read code well enough to judge whether the output is correct, spot an obvious security or logic flaw, and describe the fix. Someone who cannot read the result is trusting the model blindly, which is fine for a toy and risky for anything real.