What Is Vibe Coding? The 2026 Guide to Meaning, Examples, and Real Risks

In February 2025 a single tweet gave a name to something thousands of people were already doing: getting an AI to write their code while they described, in ordinary words, what they wanted. The name stuck. Within a year it was everywhere, then it was a dictionary's Word of the Year, and then the person who coined it started to walk it back. To use vibe coding well, you need the current picture, not the hype version from its first month.

So what is vibe coding, exactly?

Vibe coding is a way of building software where you describe what you want in plain language and an AI model writes the code. You hold the goal, the AI handles the syntax and the boilerplate, and you steer the output through conversation until it runs. The name fits the feel of the work: you care about the result, not the keystrokes.

Two readings of the phrase now sit side by side. In the strict sense Karpathy first intended, you accept whatever the model produces and rarely inspect it. In the looser sense most people use today, it covers any workflow where the AI writes the bulk of the code and a human guides it. This guide leans on the broader meaning, because that is what people are asking about when they search for it.

Why it's called “vibe” coding

The “vibe” is your intent. You keep a picture of what the app should do and how it should feel, and you let the model translate that picture into working code. You sit closer to a director than a typist. When it goes smoothly, you barely read the code at all, which is exactly what the phrase was meant to capture.

Where the term came from, and why the origin still matters

On 2 February 2025, Andrej Karpathy posted the sentence that named the movement. Karpathy is a founding member of OpenAI and the former director of AI at Tesla, so when he described a new way to build software, people paid attention. He wrote about a new kind of coding where you “fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

He was half joking. He later called it a “shower of thoughts throwaway tweet,” and he meant it for weekend experiments, the kind of project where a bug you cannot fix gets worked around rather than solved.

The phrase escaped that narrow meaning almost at once. By late 2025, Collins Dictionary had named vibe coding its Word of the Year. As the term spread, it stopped describing careful weekend tinkering and came to mean any prompt-driven development, including production systems it was never designed for. That drift is why the same two words now read as “fun and fast” to a hobbyist and “reckless” to a senior engineer.

How vibe coding actually works

Strip away the philosophy and every session runs on the same short loop.

The core loop

You describe the outcome. The model generates code. You review whether it matches your intent and runs. You refine through conversation, and the loop starts again. A feature that would take a day by hand can appear in under an hour, which is why the cycle feels addictive.

The four-step vibe coding loop: describe, generate, review, iterate.

Speed is both the appeal and the trap. Because each turn is cheap, it is easy to keep accepting output without reading it, and that is where the trouble usually begins.

A short example, from prompt to problem

Here is a typical session, shown for illustration rather than drawn from a specific product. Say you want a booking feature for a small salon site. You prompt:

Add a booking form where a customer picks a service, chooses an available time slot, and gets a confirmation email.

The model returns a form, a database table and an email step, and it runs. Then you ask for a second feature, and the AI rewrites part of what it built earlier because it does not remember the conventions it invented last time. This is the common failure mode, and there is data behind it. CodeRabbit's December 2025 analysis of 470 GitHub pull requests found that AI-generated code carries roughly 1.7 times more issues than human-written code when there is no architectural context to guide it.

Vibe coding, traditional coding and agentic engineering

Because the term now covers so much, it helps to place it against its neighbours.

What is genuinely different

Traditional development starts from the pieces. You define functions, wire up data and write tests, then assemble a working system. Vibe coding starts from the vibe: the goal and the constraints come first, and the pieces get filled in by the model. The skill shifts from writing code to describing outcomes clearly and judging what comes back.

How the meaning changed in 2026

One year after the original tweet, Karpathy moved on from his own term. At Sequoia's AI Ascent event in February 2026 he reframed the work as “agentic engineering,” arguing that the new default is that you are not writing the code directly most of the time, yet you are still engineering with specs, tests and review. The lesson for readers is plain: “vibe coding” now describes the loosest end of a range, and serious production work has a different name and a different rulebook.

The vibe coding spectrum, from accept-the-output prototyping to disciplined agentic engineering.

The tools that make vibe coding possible

The tools split into a few groups, and the right one depends on how much code you want to see.

•     AI-first editors, such as Cursor or GitHub Copilot, put the model inside a familiar code editor. You still see every file, which suits developers who want speed without losing control.

•     Browser builders, including Bolt and Lovable, generate a whole app from a description and host it for you. They hide most of the code, which is why non-technical builders reach for them first.

•     Agent tools, such as Claude Code or Vercel's v0, take a larger task and work across many files on their own, sitting closer to the agentic-engineering end of the spectrum.

Under the hood the experience is similar across platforms, so the deciding factors tend to be pricing and how well a tool keeps track of your project as it grows.

What people actually build with it

The honest answer is that vibe coding shines for small, personal software and struggles with large, shared systems.

New York Times columnist Kevin Roose described using it to make “software for one”: small personal apps no company would ever build for you, like a habit tracker or a lookup tool for a five-person team. That is the sweet spot. The idea is too niche to justify a developer, the stakes are low, and the payoff is immediate.

Non-technical people are building internal dashboards and simple intake tools the same way, describing the workflow and letting the model wire it together. Karpathy's own examples were throwaway projects, built for the pleasure of watching an idea run rather than for anything that had to survive contact with real users.

The ceiling is real. Complex distributed systems and anything holding sensitive data still need structured engineering well past a first AI draft, which is why the method fits the edges of software rather than its core infrastructure.

Should you vibe code it? An honest test

Two questions decide whether vibe coding is the right call: how much damage a failure causes, and how long the code has to live.

A simple test for when to vibe freely and when to slow down.

Where it shines

For prototypes and personal tools the method is hard to beat. You go from idea to working software in an afternoon, there is almost no learning curve to start, and experiments are cheap enough to throw away. A good first project is a single-purpose tool: a form that saves responses to a spreadsheet, or a small dashboard that charts a file you upload. Each one works end to end, which teaches more than a tutorial does and keeps motivation high while the fundamentals sink in.

Where it breaks down

The weaknesses show up as projects grow. You can end up with a codebase you do not understand, which makes the next bug hard to find and harder to fix. Quality drifts as the model invents fresh conventions on every prompt. And the speed that felt great early becomes a liability when a broken change ships because nobody read it. A 2025 Harness survey found that 67 percent of developers spend more time debugging AI-generated code than they did before adopting AI tools, a sign that the time saved up front often comes back later with interest.

The risks nobody puts on the brochure

The most important thing to understand about vibe coding is that working code and safe code are not the same thing.

Security findings vary by study and method, but the direction is consistent.

What the security data shows

The numbers from 2025 and 2026 are sobering. A study by Escape.tech scanned 5,600 applications built with vibe coding tools and found more than 2,000 vulnerabilities, over 400 exposed secrets such as API keys, and 175 cases of exposed personal data. Researchers at Carnegie Mellon found that while about 61 percent of AI-generated code functions correctly, only 10.5 percent passes a security review. Fewer than eleven snippets in every hundred clear the bar.

Veracode tested more than 100 large language models and found that 45 percent of AI-generated samples introduced a vulnerability from the OWASP Top 10, and that this rate did not improve across testing cycles from 2025 into early 2026. Security firm Wiz reported that around 20 percent of vibe-coded apps shipped with serious vulnerabilities or misconfigurations.

The gap that matters: AI code got far better at running, not at being safe. Source: Veracode.

That last point is the one to sit with. Veracode found that leading models now produce code that compiles about 90 percent of the time, up from under 20 percent two years earlier. The share of code free of common vulnerabilities barely moved. The machines got much better at writing code that runs and no better at writing code that is safe.

Why AI code fails differently

The failures are not random. Because models learn from public code, they reproduce the outdated patterns and insecure habits in that training data, and they sometimes invent package names that do not exist. Roughly one in five AI-generated snippets references a non-existent package, and attackers have learned to register those hallucinated names as malware, a trick now nicknamed “slopsquatting.”

Volume compounds the problem. Apiiro reported that AI-assisted developers ship code three to four times faster while producing security findings at roughly ten times the rate. A December 2025 study found that AI-assisted pull requests generated 2.74 times more security issues than human-only ones. And a large-scale study of more than 500,000 code samples, presented at IEEE's ISSRE 2025 conference, concluded that AI-generated code carries more high-risk vulnerabilities than human-written code, and that the review frameworks built around human error are a poor fit for catching them.

How to keep the risk in check

None of this means avoid the tools. It means treating AI output as a fast, careless first draft, and checking its work.

•     Read the diffs. Skimming past changes you do not understand is how bugs and secrets slip in.

•     Keep everything in version control so one bad prompt cannot erase working code.

•     Add tests for anything that matters, and run a dependency and secrets scan before you ship.

•     Keep real credentials and customer data away from a prototype until it has had a proper security review.

What vibe coding means for jobs and skills

The fear that AI will erase programming jobs misreads what is happening. The work is moving, not vanishing. Time once spent typing boilerplate now goes into describing outcomes precisely, reviewing generated code and catching the mistakes the model cannot see. Prompt writing and code review are becoming core skills rather than side ones.

Fundamentals matter more, not less. You cannot judge whether generated code is safe or sensible if you do not understand what it is doing. AI researcher Andrew Ng has offered a pointed reality check on the hype, reminding people that understanding how software works is what lets you direct these tools instead of being misled by them. For beginners the practical path is to build with AI and study what it produces, using each project to learn how real applications fit together.

Where vibe coding goes from here

The term is settling into its proper place. “Pure” vibe coding, accept the output and forget the code, is finding its home in prototypes and personal software, exactly the throwaway projects Karpathy had in mind. Production work is drifting toward the disciplined end of the spectrum, with written specs, automated tests, guardrails and human review wrapped around the AI, under names like agentic engineering.

One detail from the original tweet tends to get lost, and it points at what comes next. Karpathy was not only typing prompts; he was speaking them, dictating to his editor so he barely touched the keyboard. The label he coined may fade, and the argument over what counts as “real” engineering will run for a while yet, but the shift he pointed at, describing software in plain human language and letting the machine build it, is the part that has only grown. The question worth asking is no longer whether to work this way. It is how much you are willing to check before you ship.

The Bottom Line

Vibe coding is real, useful, and easy to overtrust. Used for what it was built for, small prototypes and personal software, it turns an afternoon into a working app and lets people who never learned to code build things that matter to them. Pushed into production without discipline, it ships fast and breaks quietly, which is why the same tools that compile code 90 percent of the time still leave close to half of it carrying known vulnerabilities.

The practical takeaway is a single habit: match your caution to the stakes. Vibe freely on throwaway work, read every diff on anything that lasts, and wrap real specs, tests and human review around anything that touches money or personal data. Do that, and the label you use for it stops mattering. What you are really doing is deciding how much to trust the machine before you hand it the keyboard, and answering that question honestly is the whole skill.