What Is Vibe Coding? Karpathy's Idea and Why Developers Are Using It
Vibe coding is what happens when you let the AI drive and just describe the feeling of what you want. Karpathy coined it. Here's what it actually means.
On this page
Andrej Karpathy dropped a tweet in February 2025 that named something a lot of us were already doing.
"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 meant it as a description of his personal workflow. The term escaped the lab and now every developer who has opened Cursor in the last twelve months has either embraced vibe coding or yelled at it. It has become shorthand for a specific way of building software with AI.
This post is what vibe coding actually is, when it works, when it does not, and the part most people get wrong.
What vibe coding means, in plain English
Vibe coding is when you describe what you want the code to feel like or do, and the AI writes it. You read it quickly, maybe do not fully understand every line, accept it if the output looks right, and move on. If something breaks, you paste the error back to the AI and let it figure out the fix.
You are not ignoring the code. You are not pretending it does not exist. You are just treating the AI as the primary author and yourself as the director.
The old way: think through the algorithm, write each line, review, test. The vibe way: describe the outcome, run the result, correct with natural language, repeat.
Why it works now and did not in 2023
Three things changed.
Models got good at code. Claude 3.5 Sonnet in mid-2024 was the first model I used that could handle a React component with TypeScript, Tailwind, and three imports without hallucinating a method that does not exist. Claude 4 and GPT-5 are another tier above that.
Tool-using agents shipped. Cursor, Claude Code, Windsurf, and a dozen others now let the AI actually read your codebase, run tests, and iterate. Protocols like MCP make this possible at the infrastructure level, giving agents a standard way to read files, call tools, and talk to your environment. The model is not writing blind. It sees the same files you see.
Prompts stopped needing to be prompts. You can now write "the login button should have a hover state that makes it feel like it wants to be clicked" and get something reasonable. That is vibe. That is the coining.
When vibe coding actually works
It works great for:
- Throwaway code. Internal tools, scripts, one-off automation. If the code never ships to production and one person uses it, vibe as hard as you want. This overlaps heavily with the kind of AI automation a small business can actually ship without a full dev team.
- Prototypes. Getting a working version of an idea in front of a user in 48 hours. Speed matters more than elegance. Vibe it.
- UI tweaks. "Make this card look more premium" is a request the AI handles better than most junior designers now.
- Boilerplate. CRUD endpoints, form validations, standard error handling. Code that is boring to write and easy to review.
- Learning a new framework. You vibe, the AI writes, you read, you learn the patterns faster than tutorials.
That is a long list. For a lot of day-to-day development, vibe coding is genuinely the most productive workflow available right now.
When vibe coding breaks
It breaks in specific, predictable places.
Production code that handles money. Payments, billing, tax calculations. The AI is confident and wrong in these places more often than in UI code, and the failure mode is expensive. I review every line here.
Security-sensitive surfaces. Auth flows, permission checks, password handling. Same reason. The AI will generate code that compiles and runs and quietly introduces a vulnerability you will not catch unless you are reading carefully.
Performance-critical paths. If a function runs a million times a day, the difference between an O(n) and O(n log n) implementation matters. The AI will often pick the cleaner-looking one that is also slower. You need to notice.
Architecture decisions. What data structure to use, how to split services, what to cache. The AI will answer, and the answer will sound reasonable. But the cost of a wrong architecture decision is months of refactoring. These are not vibe decisions.
Debugging a deep bug. When something is broken and nobody knows why, vibe coding is how you end up with three new bugs and the original one still unfixed. Turn the AI off, read the code, understand the system, then come back.
The pattern: vibe works when being wrong is cheap. It fails when being wrong is expensive.
The tools people actually vibe with
Quick rundown of what the 2026 vibe-coding stack looks like.
Cursor. The IDE most serious vibe coders use. Has inline AI, agent mode, and a chat panel that knows your whole codebase. The agent mode is where real vibe coding happens: you describe a change, it edits multiple files, you accept or reject.
Claude Code. Terminal-based. You say what you want, it reads the repo, runs commands, modifies files. Closer to a pair programmer than an IDE assistant. I use Claude Code for larger tasks that span many files.
Windsurf. Similar to Cursor. Slightly different trade-offs on agent behavior. Developers who switched from Cursor to Windsurf usually cite better reasoning on complex refactors.
GitHub Copilot. The OG. Still the best for inline autocomplete inside VS Code. Weaker as an agent than Cursor or Claude Code. Fine if your company pays for it anyway.
v0, Bolt, Lovable. Vibe coding for people who do not code. Describe an app in plain English, get a running prototype. Good for ideation, not yet for production. Founders use these to test ideas before hiring a developer.
The hidden cost of vibe coding
Here is the part that usually does not get said out loud.
Vibe coding makes you a better product person and a worse engineer. You ship faster, iterate faster, test ideas faster. But the parts of your brain that used to think about edge cases, memory layout, algorithm complexity, they atrophy if you never flex them.
I notice this in myself. I have to deliberately spend time writing code without AI assistance, just to stay sharp on the fundamentals. It is like running without headphones once a week. Keeps the motor intact.
If you are five years into your career, vibe coding frees you up to work on bigger problems. If you are six months in, vibe coding without deliberate study will make you a button-pushing pseudo-engineer who cannot debug a system when the AI cannot help.
The AI will not tell you this because the AI does not know. You have to calibrate yourself.
When to vibe and when to think
The rule I use:
- Vibe when the cost of a mistake is low, the solution is well-trodden, or speed beats elegance.
- Think when the code handles money, auth, user data, architecture, or anything that runs at scale.
This is not a slogan. It is how I actually decide, function by function, when I am building something.
What vibe coding is not
It is not "AI will replace developers". Every developer I know who is good at vibe coding is also good at normal coding. The AI amplifies what you already are. It does not substitute for what you are not.
It is not the end of code review. If anything, code review matters more when the AI wrote it. Humans have skin in the game and reputations on the line. AI does not.
It is not a license to stop learning. It is a workflow that rewards experienced developers more than it rewards beginners. That is worth knowing if you are deciding whether to spend your next six months grinding fundamentals or racing to ship.
The short answer
Vibe coding is AI-first software development where you describe outcomes and the model writes the code. It is fast, productive, and increasingly standard for a lot of day-to-day work. It has real failure modes you need to respect. It is not replacing you, but it is changing what "writing code" means.
Use it for 80% of what you build. Turn it off for the other 20%. Get good at knowing which is which.
If you are a founder wondering whether this changes how you should be building or hiring, most of the "hire an AI engineer" advice out there is already wrong, and it gets wrong-er every month. Book a 25-minute call and I will give you a straight answer.

