Definition
Vibe coding is building software by describing what you want in plain language and letting an AI model write the code, which you then run and often ship without reading it or understanding how it works. The move that separates it from ordinary AI-assisted coding is deliberate: you do not review the generated code line by line — you accept whatever the model produces, run it, and judge success by whether the program appears to behave, steering by the "vibes" of the result rather than by the source.
That single choice is the whole idea, and it is easy to miss because so much AI coding looks similar on the surface. When an engineer uses an assistant to draft a function and then reads the diff, edits it, and takes responsibility for it, that is AI-assisted coding — the human still owns the code. Vibe coding removes the reading step on purpose. The code becomes a byproduct you are choosing not to look at, and your understanding of the system stops at "it ran and did roughly the right thing."
The term was coined by Andrej Karpathy — a founding member of OpenAI and former head of AI at Tesla — in a post on 2 February 2025. He wrote: "There's 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 added that it works because models such as Cursor's Composer running Claude Sonnet "are getting too good," and that he mostly talked to the tool by voice instead of typing. The half-joking phrase "forget that the code even exists" is the definition in five words: the source is there, and you are choosing not to know what it says.
How It Works
A vibe-coding session is a conversation loop that never leaves natural language. You state a goal — "make a page that shows my photos in a grid and lets me drag to reorder them." The model returns code, often editing several files at once. Instead of reading the diff, you run it. If the program works, you move on; if it errors or misbehaves, you paste the error message back or describe what looked wrong — "the images overlap on mobile" — and the model tries again. Your attention stays on the running program, not on the text of the code, and you iterate until the behaviour matches the vibe you were after.
This is possible now for the same reason Karpathy said it was: agentic coding tools can close the loop themselves. Editors and platforms such as Cursor, Replit Agent, Lovable, Bolt and v0 can generate code across many files, execute it, read the resulting error, and patch it — several rounds deep — before handing anything back. The human describes and reacts; the agent writes and runs. Compared with older autocomplete-style help, where GitHub Copilot suggested the end of a line you were already typing and reading, the unit of work has grown from a line to a whole feature, and the volume of code arriving unreviewed has grown with it.
The mechanism that makes it fast is exactly the mechanism that makes it dangerous. Skipping the review step is what lets one person produce a working prototype in an afternoon — and it is also what lets a subtle bug, a security hole, or a hardcoded password pass straight into the running program with nobody having looked at the line that contains it.
Real-World Applications
Vibe coding earns its keep wherever the code is disposable and the cost of a hidden defect is close to zero. The clearest fit is the throwaway prototype: a founder vibe-codes a clickable demo to show an investor or to test whether an idea feels right, then deletes it and rebuilds the real product with reviewed code. The AI app-builder ecosystem is largely aimed here — Lovable, Bolt and v0 market themselves for landing pages, internal dashboards and minimum viable products where "ship something today" outranks "maintain it for five years."
It also fits personal, single-user tools — a script to rename a folder of files, a small web page only you will use — where you are the only person who can be harmed by a bug and the blast radius is your own machine. And it fits learning and exploration: a beginner can watch a working program appear from a description and start poking at it, and an experienced developer can throw a spike solution together to answer "is this API even capable of what I need?" before committing to a real implementation. Karpathy framed his own vibe-coded projects the same way — weekend experiments, not things anyone depends on.
The decision that actually changes with the stakes is whether you open the code at all. For a demo you will throw away, not reading it is rational. For anything with real users, money, personal data, or a maintenance lifetime, the same not-reading becomes the source of the problems in the next section — which is why "should I look at this code?" is the real question vibe coding forces, and the honest answer depends entirely on what the code will touch.
Key Concepts
Vibe coding versus no-code. The two are often confused because both promise software without hand-writing code. No-code tools produce no source code at all — you assemble an app from visual blocks inside a platform that owns the runtime. Vibe coding produces ordinary source code in a real language, sitting in real files you could open, run and deploy anywhere. The only thing missing is that you did not read it. That difference matters the moment something breaks: with no-code you are limited by the platform's features; with vibe coding you have a full codebase and no mental model of it.
The review gate. The single variable that defines vibe coding is whether a human reads and approves the generated code before it runs. Keep that gate and you have AI-assisted engineering with all its safeguards; remove it and you have vibe coding with all its speed and all its risk. This is why some practitioners argue that the label only applies while you are not reviewing — the moment you start reading the diffs seriously, you are doing something else.
Challenges
The risks of vibe coding are not incidental rough edges; they are the direct, predictable consequence of removing the review step. "Seems to work" is a test for crashes, not for correctness — a program can run cleanly and still corrupt data, mishandle an edge case, or quietly compute the wrong number, and vibe testing never exercises the input that reveals it.
The security cost is measurable, and it has not fallen as the models have grown. Veracode's 2025 GenAI Code Security Report gave 80 standardised coding tasks — four languages and four common weakness types — to more than 100 large language models and checked each result against the OWASP Top 10; in 45% of the tasks the model introduced a known security flaw. Security performance was essentially flat across model size and release date — newer and larger models did not write safer code — and a Spring 2026 update covering more than 150 models found the rate unchanged. The study usually cited here points the same way but measures a narrower, older activity: Pearce and colleagues' 2021 "Asleep at the Keyboard?" had GitHub Copilot autocomplete 1,689 programs across 89 security-relevant scenarios and found approximately 40% of them vulnerable. That was single-file code completion in 2021, not the agentic, multi-file generation a vibe-coding session runs today, so treat its 40% as a dated data point on a related task rather than a measurement of a modern session. Both numbers land in the same place: a large fraction of model-written code that no human inspects carries an exploitable flaw. In a vibe-coding workflow those flaws — SQL injection, missing input validation, a hardcoded API key pasted straight into a public repository — ship silently, because the whole point was not to look.
The specific ways a vibe-coded system fails once it leaves the prototype stage:
- Nobody can debug the failure. When code no human has read breaks in production, there is no engineer who understands it well enough to explain or fix it. The only tool left is to describe the symptom back to the model and hope — which works far less reliably at debugging a large unfamiliar system than it did at writing the first draft.
- Security holes and leaked secrets pass unnoticed. Unreviewed generation ships the vulnerabilities the studies above quantify, plus credentials the model helpfully inlined, because the reviewer who would have caught them was removed by design.
- The codebase becomes unmaintainable. Accumulated code with no mental model behind it has no consistent structure, and each new AI-generated change is bolted onto a system the model itself does not fully remember. Small features start requiring large, risky rewrites.
- Confident wrong code looks the same as right code. Models hallucinate plausible APIs, invent function calls that do not exist, and produce output that reads as authoritative whether or not it is correct — and skipping review is exactly the choice that lets a hallucinated line through.
Future Trends
The direction the practice is moving is to put a review surface back in without putting the human back in front of every line. Instead of reading the code, teams increasingly ask the agent to write tests and run them, wire automated security scanners and secret-detection into the generation loop, and gate deploys on those checks — so the machine reviews the machine. That reintroduces the safety the "forget the code even exists" workflow removed, at the cost of some of its speed.
Alongside this, the vocabulary is splitting. "Vibe coding" is settling into its literal meaning — fast, unreviewed, disposable — while the disciplined use of the same generative tools, with tests, review and guardrails, is drifting toward separate names like agentic or AI-assisted engineering. The useful takeaway survives the terminology: the value of an AI writing your code and the danger of shipping code no one has read are the same fact seen from two sides, and which one you get depends entirely on whether you keep the review gate for the code that matters.