What Vibe Coding Actually Is
(And Why Both Camps Are Wrong)
The Real Skill Isn’t Using AI. It’s Knowing Where to Stop and Adjust.
In February 2025, Andrej Karpathy posted something that would define the year in software development.
“There’s a new kind of coding I call ‘vibe coding,’” the OpenAI co-founder wrote, “where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”
He described his approach: accepting all AI suggestions without reading them, copy-pasting error messages without analysis, letting “the code grow beyond my usual comprehension.”
The response was immediate and polarized.
One camp embraced it completely. Suddenly feeds filled with people claiming anyone could build production apps overnight. No coding required. Just describe what you want and AI handles the rest.
The other camp rejected it just as forcefully. Senior engineers called it irresponsible. They pointed to security vulnerabilities, deleted databases, applications that collapsed under real usage. A study from METR found developers actually worked 19% slower with AI tools—even though those same developers believed they were faster. Before the study, developers predicted AI would speed them up by 24%. After experiencing the measured slowdown, they still believed AI had improved their productivity by 20%.
That perception gap should concern everyone.
Here’s what both camps missed: Karpathy explicitly said this approach was for “throwaway weekend projects.” Not production software. Not apps handling real users or real money. Weekend experiments where the stakes are low and the learning is high.
That context got stripped away in every hot take that followed.
The Actual Question Nobody’s Asking
The debate over whether vibe coding is “good” or “bad” misses what matters. The real question is simpler: Where does AI help end and human judgment begin?
Simon Willison—creator of Django, one of the most widely-used web frameworks—drew the line clearly: “Vibe coding does not mean ‘using AI tools to help write code.’ It means ‘generating code with AI without caring about the code that is produced.’”
His personal rule: “I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.”
That’s the distinction. Not whether AI wrote the code, but whether you understand it.
If you’ve reviewed everything, tested it, and can explain what it does? That’s not vibe coding—that’s software development with better tools. If you’re accepting suggestions without reading them and hoping it works? That’s the approach Karpathy reserved for throwaway projects.
The people having success with AI building aren’t the ones who’ve figured out how to give AI complete control. They’re the ones who’ve figured out how to collaborate—when to trust AI’s output and when to question it.
When to Use This Approach
Not every project deserves the same level of scrutiny. A weekend experiment is different from software handling customer data. The skill is matching your approach to the stakes.
This approach works well for:
Personal tools and games you’re building for yourself. The worst case is you waste some time if something breaks.
Prototypes where you’re testing whether an idea is worth pursuing. Speed matters more than polish. You’re trying to learn something, not ship something.
Learning projects where the goal is understanding, not production. Breaking things is part of the process.
Automation for your own workflows. Connecting tools, moving data around, simplifying repetitive tasks. Low stakes, high leverage.
This approach breaks down for:
Anything touching money. Payments, transactions, financial data. The cost of getting it wrong is too high.
Anything touching security. Authentication, authorization, user data. A Veracode analysis found 45% of AI-generated code introduced security vulnerabilities. That’s not a rounding error—that’s a pattern.
Production systems you don’t understand. If you can’t explain what the code does, you can’t debug it when it breaks. And it will break.
Code that other people depend on. When the blast radius extends beyond yourself, the standards have to go up.
The Permission You Might Need
Here’s something that took me too long to realize: you don’t need to “become a developer” to build useful things with AI.
That framing is wrong. It implies there’s a binary—either you’re a developer or you’re not, and you need to cross some threshold before you’re allowed to build.
The data suggests otherwise. According to research on vibe coding adoption, 63% of people using this approach identify as non-developers. Product managers, designers, entrepreneurs—people building functional applications without traditional engineering backgrounds.
The goal isn’t becoming an engineer. The goal is solving your problems.
What you do need: willingness to try, willingness to break things, willingness to ask questions when you’re stuck. The barrier isn’t knowledge—it’s permission.
And here’s the thing about permission: you don’t need anyone else to give it to you. You can just start.
Build something small. Something where the stakes are low and you’ll learn regardless of whether it works. See what happens. See if you like it. See if you want to keep going.
Most people who build successfully with AI didn’t start with a grand vision. They started with a small annoyance they wanted to fix. The skills compound from there.
What Comes Next
This piece was intentionally about framing. About understanding what vibe coding actually is, when it applies, and where the real skill lies.
Next week, I’ll share the actual playbook—the specific principles that guide how I build, with examples from tools I’ve shipped. The tactics work better once this framing is in place.
But here’s what I want you to take from today:
The skeptics aren’t entirely wrong. There are real risks, real failures, real reasons to be careful. Understanding those risks is part of being good at this.
The enthusiasts aren’t entirely wrong either. The barrier to building has genuinely collapsed. Things that required teams of engineers five years ago can be built by individuals now. That’s real and significant.
The skill isn’t picking a side in that debate. It’s developing judgment about when to trust AI’s output and when to verify. It’s understanding enough about what you’re building that you can catch problems before they become disasters.
That’s not magic. It’s not “just vibes.” It’s a learnable skill. And it starts with permission—permission to try, to break things, to build something even if you don’t have all the answers yet.
You’re allowed to try this.
Next week: The Vibe Coding Playbook—specific principles for building with AI, with examples from tools I’ve shipped. Subscribe so you don’t miss it.