Vibe coding is a way of writing software where you describe what you want in plain language, let an AI model generate the code, and accept output you have not fully read or understood in order to move faster.
Andrej Karpathy named it in a February 2, 2025 tweet: "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." The phrase stuck because it named something developers were already doing.
What vibe coding actually is
Vibe coding is a behavior, not a tool or a technique. The defining characteristic is the acceptance step: you let the model write code, run it to see whether it works, and iterate by describing symptoms rather than reading the source.
In a working day this looks like: you open a chat interface, describe the feature you want, accept the first draft without auditing it, run the tests, paste any errors back into the chat, and keep cycling until the output behaves correctly. The code sitting in your editor may be code you have never read.
The word "vibe" is intentional. You are navigating by feel and outcome, not by line-by-line understanding. Some practitioners report not looking at the generated code at all between prompts.
This is not the same as writing code faster with assistance. Traditional AI-assisted coding means you read the suggestion, understand it, accept or modify it, and own the result. Vibe coding means you trust the outcome over the mechanism. That is a meaningful difference in posture, not a matter of degree.
What vibe coding is not
Not agentic coding. Agentic coding systems run multi-step loops, read their own output, write and execute tests, and may call external APIs without a human in the loop at each step. Vibe coding keeps the human at the describe-and-review layer. An agent can operate fully unattended; vibe coding does not.
Not autocomplete. Copilot-style autocomplete shows a suggestion in the editor and you accept or reject it token by token. Vibe coding delegates the full implementation to the model in response to a natural-language brief. The level of abstraction is different by an order of magnitude.
Not no-code. No-code tools replace code with visual configuration. Vibe coding produces code. You just did not write it or fully read it.
Not chat-with-code. Asking a model to explain a function, find a bug, or suggest a refactor is assisted coding. You still own the understanding. Vibe coding is the posture where you accept not owning the understanding in exchange for speed.
Vibe coding vs traditional coding vs agentic coding
| Dimension | Traditional coding | Vibe coding | Agentic coding |
|---|---|---|---|
| Who writes the code | The developer | The model, prompted by the developer | The model, in an autonomous loop |
| Does the developer read the output | Yes, line by line | Sometimes, selectively | Rarely; the agent self-reviews |
| Human-in-the-loop step | Every line | At the test-and-describe layer | At the goal-setting layer |
| Auditability of final code | High | Low to medium | Low |
| Speed on greenfield tasks | Baseline | Significantly faster on small scope | Fastest on well-defined tasks |
| Where it breaks | Complexity, time | Production systems, security, maintenance | Ambiguous requirements, novel contexts |
Where vibe coding works and where it fails
Vibe coding performs well on tasks where the cost of a wrong answer is low and iteration is fast.
Prototyping a UI nobody will ship yet. You want to see the shape of an idea. If the generated code is wrong, you describe the difference and cycle again. The cost of not understanding the code is zero because nothing depends on it and it will be rewritten before it goes anywhere near users.
Scripts and glue code you use once. A one-time data migration, a batch rename, a conversion script. You run it, check the output, and discard the code. Auditability does not matter if the artifact is disposable.
Personal projects with no security surface. A weekend app that only you use. The risk profile is entirely different from production software with user data attached.
Learning the surface of a new framework. You want to see what the API looks like in practice before you read the documentation. Vibe coding a small example and then reading it is legitimate exploration.
Where it fails:
Security boundaries. Code you have not read cannot be audited for injection, privilege escalation, or data leakage. Models produce plausible-looking security errors. You will not catch them if you are not reading the code.
Production systems with on-call. When something breaks at 2 a.m. and the code in your codebase is code nobody has read, the engineer on call cannot reason from source. They have to reverse-engineer generated output while users are affected. This cost does not show up during the vibe.
Long maintenance cycles. Generated code tends to be verbose, convention-inconsistent, and underdocumented. A codebase grown by vibe coding accumulates patterns that contradict each other. After six months the next person to touch it has no signal on which choices were intentional.
Regulated domains. Financial services, healthcare, and legal software have compliance requirements that treat code as a controlled artifact. Provenance, review records, and auditability are not optional. Vibe coding, by design, breaks that chain.
Team codebases. What works in a solo context fails in a team. The implicit knowledge you carry about generated code, the shortcuts you took, the things you tested informally but never documented: these do not transfer. The review process also breaks because a reviewer cannot tell which parts are understood and which are trusted on vibes.
Tools practitioners use
The term is not tied to a specific tool. The most commonly named ones are Claude (Sonnet and Opus), ChatGPT (GPT-4o), Cursor in composer mode, Windsurf, and Replit. Some practitioners use voice-to-prompt pipelines where they describe what they want without typing at all.
If you want to experiment before committing to a paid plan, there are free LLM APIs to practice with.
FAQ
What is the difference between vibe coding and just using AI to write code?
The difference is the reading step. When you use AI as an assistant, you read and understand the output before accepting it. In vibe coding you deliberately skip that step: you test the outcome and iterate on symptoms. The behavioral line is clear: do you own the understanding, or do you trust the result?
Is vibe coding bad practice?
It is a poor fit for specific contexts: production security, regulated domains, team codebases, anything you have to maintain. It is a reasonable tradeoff for others: prototypes, throwaway scripts, personal projects. Framing it as universally good or bad misses the point. The question is always: what is the cost if the code is wrong and nobody understands it?
Can someone with no coding background use vibe coding?
Yes, to a point. Someone with no prior background can produce working software for simple tasks. The failure mode is that they also cannot recognize when the output is subtly wrong, will have no fallback when iteration stalls, and cannot maintain what they built. Vibe coding lowers the floor for starting; it does not lower the ceiling on what can go wrong.
Where did the term vibe coding come from?
Andrej Karpathy, former director of AI at Tesla and founding member of OpenAI, introduced the term on February 2, 2025 to describe the practice of prompting AI for code and trusting the output without reading it. The phrase spread rapidly through developer communities on X and Hacker News because it named a real and already-common pattern.
What does vibe coding mean in software development?
Vibe coding means writing software by describing intent and accepting AI-generated code based on whether the output works, rather than whether you understand the code that produces it. The "vibe" is navigating by outcome and feel rather than by reading and reasoning from source.
An honest take
Vibe coding is real, it is faster in the right contexts, and it has genuine failure modes that most positive coverage ignores. The practitioners who use it most effectively tend to have strong enough fundamentals to recognize when generated code is wrong, even if they are not reading it line by line: they test with intent, not just by clicking run and hoping. If that describes you, vibe coding is a legitimate part of the toolkit. If it does not, you are taking on risk that will not become visible until it is expensive.
If the vibe has run out and what remains needs someone who reads every line, klim.expert is where that goes: one senior engineer, your codebase, the work finished.
