What Vibe Coding Is, in Plain English
In short
Vibe coding is a way of building software where you describe the task in ordinary words and an AI model writes the code for you. Andrej Karpathy coined the term in February 2025: the idea is to "give in to the vibes" — don't read every line, look at the result and fix it with new requests. It works beautifully for prototypes, scripts and small apps. On serious projects it takes discipline, or mistakes you never noticed quietly pile up.
What vibe coding is, in plain English
Vibe coding is software development where a human states the task in natural language and a large language model (LLM) generates the source code. You don't type code — you describe what you want: "build a landing page with a contact form", "add a dark theme", "fix this error". The model writes the code, you run it, watch how the program behaves and refine it with the next request.
The core idea behind the term is trusting the result rather than the code. In its original, "pure" sense, vibe coding means you don't review every line — you judge by whether the program does what you intended: it works, you accept it; it doesn't, you ask for a rewrite. The codebase can grow faster than you can understand it.
Who coined the term
Andrej Karpathy — an OpenAI co-founder and former head of AI at Tesla — introduced the phrase "vibe coding" in February 2025. In a short post he described his own style: "fully give in to the vibes... and forget that the code even exists." He talked about dictating tasks by voice, always hitting "Accept All" and no longer reading diffs. The phrasing hit a nerve in the industry and went mainstream fast: in 2025 Collins Dictionary named vibe coding its word of the year, and Merriam-Webster had already added it to its slang list back in March.
How vibe coding differs from regular programming
In classic development the main skill is knowing a language and its syntax, reading and writing code by hand. With vibe coding the main skill shifts: what matters is stating the task clearly and judging the result. Code becomes a consumable that an agent generates.
| Criterion | Regular programming | Vibe coding |
|---|---|---|
| Who writes the code | a human | AI, from your description |
| Main skill | language and syntax | framing the task |
| Unit of work | a line, a function | a request in plain language |
| How it's checked | code review, tests | watch the behaviour, fix with prompts |
| Time to start | slow | very fast |
| Typical risk | clear, visible bugs | hidden mistakes nobody caught |
The table also shows the central trade-off: you gain speed and lose control. While the project is small, that's a good deal. The bigger the codebase, the more unnoticed mistakes cost you.
How vibe coding differs from agentic engineering
This is where most of the confusion lives. Vibe coding is about trusting the vibe with minimal control. Agentic engineering is disciplined work with the same AI agents: a written spec, rules, review and tests. The tools are identical; the approach is the opposite. In one case you deliberately let go of the wheel, in the other you keep the process in hand and verify what the agent did.
Put simply, vibe coding is "for the thrill" mode and agentic engineering is "for production" mode. Experienced teams switch between them depending on the stakes. For more on where that line runs and what counts as an AI agent, see "What vibe coding and agentic engineering are".
Who vibe coding is for and what it solves
Vibe coding helps two groups at once. Beginners and non-programmers get to build a working thing without spending years learning a language. Experienced developers get an order-of-magnitude speedup on routine and one-off tasks where digging into the code isn't worth it.
Typical tasks where vibe coding lands well:
- a prototype or MVP to test an idea quickly;
- a landing page, a form, a simple personal site;
- automation scripts: parse files, hit an API, assemble a report;
- a small internal tool just for yourself;
- learning — seeing a task turn into working code.
They share one thing: the cost of a mistake is low, and speed matters more than perfect architecture.
What people vibe code with: the tools
Vibe coding lives inside AI editors and agents. The two most popular tools:
- Claude Code — Anthropic's agent; runs in the terminal and in your editor, reads and edits project files on its own.
- Cursor — a VS Code-based editor with built-in AI, and the birthplace of the term itself (Karpathy was vibe coding in Cursor).
MCP servers extend what an agent can do — they give the model access to external tools: a database, a browser, documentation, GitHub. What MCP is and how to connect it safely is covered in "MCP: connecting tools safely". Ready-made tools, prompts and stacks for specific tasks are collected in the qvib knowledge base.
The risk: "describe it and take it on faith"
Vibe coding's main risk is baked into its definition: you accept code you never checked. Here's what follows:
- Hidden bugs. The program seems to work on your examples but breaks on everything you didn't test.
- Security holes. A model will happily leave an exposed key, a weak permission check or a vulnerability — and you didn't see it. The ground rules are collected in the "Security" section.
- Technical debt. Code grows faster than your understanding of it. When something breaks, you'll be fixing code you never read.
- Invented dependencies. The model may reference a library that doesn't exist or a method that's been deprecated.
Hence an honest rule: vibe code freely wherever a mistake is cheap. The moment money, people's data or your reputation is on the line, "take it on faith" stops being a strategy.
When vibe coding works and when it doesn't
Vibe coding works when the cost of a mistake is low, the project is small and disposable, you're building a prototype or learning, and the result is easy to verify by eye.
Vibe coding stalls when the product ships to real users in production, touches payments, personal data or security, and the codebase is already large and has to be maintained for months.
The good news: this isn't a dead end, it's a question of discipline. The same agent delivers consistent results if you give it a frame — a precise task statement, project rules, verification of the output. That's where the move from "vibes" to engineering starts. How to phrase a task so the agent gets it right the first time is covered in "How to state a task".
How to make vibe coding reliable
For vibe coding's speed not to turn into chaos, the agent needs scaffolding: shared rules, checklists, a repeatable process and clear checks at every step. Setting that up by hand for every project takes ages — and that's exactly the work our vibe-coding engine Quest does for Claude Code and Cursor.
Quest turns scattered prompts into a predictable process: the agent works from a spec, follows project rules and checks itself instead of just "writing something". You keep vibe coding's speed but remove its biggest downside — unpredictable results. You can assemble a configuration for your stack in the studio. That's the bridge from "describe it and take it on faith" to development you can rely on.
FAQ
Is vibe coding the same as programming with AI?
Not quite. Programming with AI is any use of a model as an assistant, including reading the code it produces. Vibe coding is the extreme form, where you deliberately don't read the code and trust the result.
Do you need to know how to program to vibe code?
To build something — no, that's the whole point. But a basic grasp of how code works raises quality sharply: you frame tasks more precisely and spot the agent's mistakes earlier.
Can you build production products with vibe coding?
You can, but not with pure vibes. Production needs specs, review, tests and rules — in other words, a move to agentic engineering. The Quest engine helps you build that process.
What tools do you need to get started?
One AI agent is enough — Claude Code or Cursor. After that you add MCP servers as needed for access to a database, a browser and other tools.
Will vibe coding replace programmers?
It changes their work more than it replaces them. Framing the task, checking the result and owning architecture and security still fall to a human — they just do it faster now.