Vibe Coding: What It Means and Why It’s Risky

Vibe coding is an informal term for making software by describing what you want to an AI coding tool, then accepting and refining the code it produces—often with limited line-by-line review. It can make prototypes easier to build, but speed does not guarantee that the software is correct, secure, or maintainable.

What “vibe coding” means

“Vibe coding” is informal, contemporary tech slang, not a standard technical term with a formal specification. It describes a way of working rather than a particular programming language, product, or reliably defined level of AI assistance. In practice, people use it for a range of activities: asking a code-generating assistant for a small function, iteratively prompting it to build an application, or accepting large changes without understanding every detail.

The phrase was popularized in February 2025 by computer scientist Andrej Karpathy, who used it to describe a deliberately loose approach to building software with large language models. His description emphasized expressing requests in natural language, running generated code, and responding to the result, while sometimes not closely inspecting the code itself. The label caught on in developer and media discussions. That origin explains the name, but everyday use is broader: someone might say, “I vibe-coded a weekend prototype,” meaning they built it through prompts and quick iterations.

The word “vibe” signals that intuition and conversational feedback are steering the process. It does not mean that the software is necessarily casual, useless, or entirely written by a model. Nor does it mean that a developer never reads the output. The key distinction is how much the person building the software understands and verifies what they are accepting.

How vibe coding works

A typical cycle is conversational: the user states a goal, a coding assistant proposes or edits code, the user runs the result, and the next prompt describes what to change. For example, a prompt might ask for a page that collects a name and displays a greeting. If the result looks wrong, the user may say, “Move the button below the field,” or paste an error message and ask for a fix.

Tools differ. Some suggest a few lines inside an editor; others can modify multiple files, run commands, or work with a project. But the basic loop is similar:

Describe a feature or problem in ordinary language.
Review or accept the generated changes, then run the software.
Report visible problems or new requirements and request another change.
Test the result—and, in responsible development, inspect, document, and verify the code before relying on it.

The last step is where the casual version can diverge from established software engineering. A page that appears to work in one demonstration may fail with unusual input, on another device, or when connected to real accounts or data.

Why people use it

Natural-language prompting can reduce the initial effort needed to turn an idea into a visible prototype. It may help someone explore a user interface, automate a repetitive task, learn by experimenting, or communicate a rough concept to a programmer. People who can describe what they want but do not know the syntax of a language may find it easier to get started.

It can also be useful for experienced developers. Generated code may provide a draft, a test scaffold, or an example of an unfamiliar library. In that setting, the developer’s ability to evaluate the proposal is an important part of the workflow. The potential benefit is faster drafting, not the removal of design, testing, or accountability.

Why it is risky

AI-generated code can be plausible while being wrong. A program may appear to work for the prompt’s simplest case but mishandle empty fields, unexpected input, concurrent users, or failures elsewhere in the system. If a person cannot explain what a change does, they may also struggle to spot a flawed assumption or diagnose a later problem.

Security flaws: Generated code may handle passwords, permissions, uploaded files, or user input unsafely. A feature that works in a demo may expose data or allow actions that should be restricted.
Hidden failures: A tool may fix the visible error while introducing a different bug. Repeated prompt-and-patch cycles can leave behind duplicated logic, fragile workarounds, or changes whose effects are unclear.
Privacy and confidentiality: Pasting private source code, credentials, customer information, or internal documents into an external service can disclose information. What a service stores or uses depends on its settings and terms; users should check those details rather than assume prompts are private.
Dependency and maintenance problems: Code may rely on unsuitable, outdated, or unnecessary packages, or may not fit the project’s existing design. The person who maintains it later needs to understand its behavior and dependencies.
Misleading confidence: A polished interface and a successful first run are not proof of correctness. Tests can help, but tests themselves may be incomplete or generated from the same mistaken assumptions.

Risk depends on the stakes and the degree of review. A disposable mock-up is different from a service that stores personal records, handles payments, controls equipment, or supports an organization’s operations. In higher-impact work, code review, security checks, testing, and clear responsibility matter regardless of who drafted the code.

Safer ways to use the approach

Vibe coding is less risky when treated as a drafting and learning method rather than a substitute for verification. Keep experiments isolated from production systems and use sample data when possible. Do not paste secrets such as passwords, API keys, or private customer records into prompts. Before accepting a change, ask what files it modifies, what assumptions it makes, and how it handles invalid or unexpected input.

Make small changes that are easy to inspect and undo; use version control or another reliable backup.
Run relevant tests after each change, and add tests for important edge cases rather than checking only the happy path.
Review authentication, authorization, data handling, and dependencies before exposing an application to users.
Ask the assistant to explain unfamiliar code, then verify the explanation against the code and trusted documentation.
Get qualified human review for software with consequential safety, privacy, financial, or operational effects.

These habits do not make generated code automatically safe. They make errors more likely to be noticed before the code is trusted or deployed.

Vibe coding versus traditional development

The contrast is not simply “AI” versus “no AI.” Professional developers may use AI tools, and a person vibe-coding may write some code themselves. The more useful comparison is between workflows. A careful workflow includes requirements, review, testing, and maintenance whether code is typed by a person or generated from a prompt. Vibe coding, in its original loose sense, puts greater emphasis on conversational iteration and less on inspecting each change.

That makes the term useful as a description, not a guarantee of quality. “Built with AI assistance” says something about the tool; “vibe-coded” often suggests something about the builder’s level of engagement with the underlying code. Neither phrase alone tells you whether a program is fit for purpose.

Frequently Asked Questions

Is vibe coding a real technical term?
It is a real, widely used informal expression, but it is not a formal engineering standard. Its meaning can vary, so it helps to ask whether the person means AI-assisted coding generally or accepting code with little review.

Who coined the term vibe coding?
Computer scientist Andrej Karpathy popularized the phrase in February 2025 when describing a loose, prompt-driven style of AI-assisted programming. It subsequently became common in wider discussion of coding with generative AI.

Do you need to know how to code to vibe-code?
Not necessarily to produce a simple prototype, but coding knowledge helps you judge output, find bugs, and maintain the result. Difficulty understanding the generated code is a reason to limit its use to low-stakes experiments.

Is vibe coding safe for a real application?
It can be part of building one, but prompts and a successful demo are not enough to establish safety or reliability. Real applications need appropriate testing, review, security checks, and maintenance.

Does vibe coding mean the AI writes everything?
No. The term covers different levels of assistance, from small suggestions to substantial generated changes. Its defining idea is the prompt-and-feedback style, especially when the builder does not closely inspect every line.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →