Andrej Karpathy coined the term "vibe coding" and suddenly everyone had an opinion. The idea: you describe what you want to an AI in natural language, accept the code it writes without fully understanding it, and iterate based on whether it works. You "give in to the vibes" and let the AI handle the details.
I tried this approach for a week across three different projects. Here's my honest take.
Where Vibe Coding Actually Works
Prototypes and throwaway code. Building a quick demo to test an idea? Vibe coding is perfect. "Build me a dashboard that pulls data from this API and shows a chart of daily trends." Accept whatever comes out, click around, refine with more vibes. If the code is ugly underneath, who cares? It's a prototype.
I built a working internal tool in two hours this way. Pull data from our analytics API, display it in a table with filters and sorting, add an export button. The code underneath is not something I'd want to maintain. But it works, the team uses it, and if it needs to become a real product someday, I'll rewrite it properly.
Learning new frameworks. Vibe coding is a great way to explore unfamiliar territory. "Build a basic app with [framework I've never used]." Accept the output, run it, see how things connect. It's like having a tutor who builds examples on demand. I learned more about SvelteKit in an afternoon of vibe coding than I would have from reading docs.
One-off scripts. "Write a script that reads all JSON files in this directory, extracts the 'email' field from each, deduplicates them, and writes them to a CSV." Run it, check the output, delete the script. No need to understand every line if the output is correct.
Where Vibe Coding Fails
Production code. This is the big one. Code you don't understand is code you can't debug, can't extend, and can't maintain. When something breaks at 2 AM, "the AI wrote it and it worked" is not a debugging strategy. You need to understand the code enough to diagnose issues, and vibe coding deliberately skips that understanding.
During my experiment, a vibe-coded feature started throwing intermittent errors under load. The code looked reasonable, but I didn't understand the concurrency model it was using. Debugging took longer than writing it from scratch would have, because I was reverse-engineering someone else's (the AI's) decisions. I ran into similar issues during my autonomous coding experiment.
Security-sensitive code. Authentication, payment processing, data encryption, access control. If you're vibing through auth code, you're one hallucinated parameter away from a security vulnerability. I found a SQL injection vulnerability in vibe-coded database queries during my experiment. The AI used string interpolation instead of parameterized queries in one endpoint, and it wasn't obvious from a quick glance.
Complex business logic. When the logic has edge cases that depend on domain knowledge, vibe coding produces code that handles the common case and misses the exceptions. These are exactly the bugs that slip into production and cause data corruption.
The Uncomfortable Truth
Vibe coding works well for people who already understand programming. If you know what good code looks like, you can vibe code quickly and catch problems when they arise. Your experience serves as a safety net.
For people who don't know how to code, vibe coding is dangerous. Not because the code is bad, but because they can't evaluate whether the code is bad. They ship it, it works in testing, and then it fails in production in ways they can't diagnose. The ability to read and evaluate code is the prerequisite that makes vibe coding safe.
My Vibe Coding Rules
After the experiment, I've settled on these guidelines:
Vibe code when the stakes are low. Prototypes, demos, internal tools, learning exercises, scripts that run once. Accept the output, check if it works, move on.
Understand what you ship. Before any code goes to production, I read every line. Not because I wrote it manually, but because I need to be able to debug it, extend it, and explain it. If I can't explain what a function does, it doesn't ship.
Never vibe through security. Auth, encryption, access control, and input validation get full attention every time. These are the areas where a subtle bug has outsized consequences.
Use vibes for the first draft, not the final draft. Vibe code to get something working quickly. Then review, understand, and refine. The speed benefit comes from the first draft being generated in seconds. The quality comes from the review pass that follows.
The Real Opportunity
Vibe coding is not a replacement for understanding code. It's a speed boost for the exploration phase. The developers getting the most out of it are the ones who vibe code a first draft in minutes and then spend their saved time on architecture, testing, and review, the parts that AI still doesn't do well.
The hype says vibe coding means you don't need to understand programming. The reality is that understanding programming is exactly what makes vibe coding safe and productive - something I also addressed when debunking the 100x developer myth. The trend is real. The "you don't need to learn to code" narrative around it is not.