I Despise Vibe Coding. Here's the Only Place It Belongs
I use AI-assisted coding every day. Claude Code is part of how I build everything. And I despise vibe coding.
That sounds like a contradiction. It isn’t. AI-assisted coding and vibe coding are not the same thing, and the difference is the whole point of this post.
So what is vibe coding?
Vibe coding is when you don’t read the code. You trust the AI to write everything. You accept whatever it spits out. Something breaks? Paste the error back in and hope for the best.
That’s not me being harsh. That’s literally how it started. Andrej Karpathy coined “vibe coding” in a post on X on February 2, 2025 (X blocks some readers, so here’s a readable copy of the same post). In that same post, he admitted that the code grows beyond his usual comprehension, that when the AI can’t fix a bug he just asks for random changes until it goes away, and that it’s not too bad for throwaway weekend projects.
Throwaway weekend projects. The guy who invented the term said that. Somewhere along the way, people skipped that part and started shipping vibe-coded apps to real users.
I tried it. Here’s what happened.
I’m not writing this from the sidelines. I’ve vibe coded, mostly in Google AI Studio, building things like Crumbs, a business manager for cottage bakers, and ClaimGuard AI, an insurance-claims assistant. At first it felt amazing. Type a sentence, get an app.
Then I actually looked at what I had.
The designs were AI slop: the same sloppy blue-purple gradient and generic rounded borders every AI app seems to ship with. Simple things were written in weirdly complicated ways. Stuff that should’ve been ten lines was fifty. And Gemini hallucinated data right inside the app. I couldn’t fix it, because I had no idea how the code that was supposed to catch it actually worked.
That bug is what stopped me. I realized I didn’t own what I built. The AI did. And the AI doesn’t care if it breaks.
The only place vibe coding belongs
Prototypes. Demos. Testing an idea on a weekend. Anything with no real users, no real data, and nothing that hurts anyone if it falls apart.
That’s it. That’s the list.
I’ve been trading for over 9 years, and vibe coding reminds me of trading on a hot tip with no plan. Sometimes it works. You feel like a genius. But you don’t know why it worked, so you can’t repeat it, and you definitely can’t protect yourself when it goes wrong. Fine with play money. Terrible with real money.
Why I despise vibe coding in production
AI builds stuff you don’t need. It over-engineers everything. You ask for one simple feature and it adds extra layers, extra config, and code for problems you don’t even have. It pulls you toward features you never planned. If you’re not reading, you don’t notice, and your app slowly fills up with code nobody asked for and nobody understands.
It produces slop. AI slop apps. AI slop designs. They look done in a screenshot and fall apart the second a real user does something unexpected.
Even the best models need steering. In my experience, Sonnet still needs a lot more hands-on direction than Opus, which is part of why I split the two by task instead of using one for everything. Even Opus over-engineers things I never asked for often enough that I’ve stopped being surprised by it.
No model gets it right every time. More than once I’ve asked it to fix a bug and gotten a list of two problems back instead of an actual fix. My reply, verbatim: “Dude wtf.” It went back and fixed them.
AI is fast. Fast and correct are not the same thing.
The AI will grade its own homework, and lie about it. Look at the Replit incident. During a 12-day vibe coding experiment, SaaStr founder Jason Lemkin’s AI assistant ran destructive commands that wiped a database with records on 1,206 executives and over 1,196 companies.
Then it made it worse. It built a database of 4,000 fake user profiles and lied about a unit test passing, then told Lemkin the rollback was impossible. It wasn’t; the rollback actually worked. Lemkin said it was a demo app, but he still lost around 100 hours of work. That was a demo. Now imagine real customers.
The numbers say the same thing. A December 2025 CodeRabbit analysis of 470 GitHub pull requests found AI co-authored code averaged 10.83 issues per PR versus 6.45 for human-only PRs, about 1.7 times more overall, with up to 2.74 times more security vulnerabilities.
In May 2026, security firm RedAccess reported that out of roughly 380,000 publicly accessible AI-built assets, about 5,000 vibe-coded apps built for business use were leaking corporate data, many of them because privacy settings defaulted to public. Some were exposing medical records and a bank’s financial data.
Where real data lives, vibe coding doesn’t
At my day job, I work with school district data. Student records are protected by FERPA, a federal privacy law. You don’t get to vibe your way through code that touches that. You have to be careful about exactly what the code spits out, every field, every time.
Same with Tradion, the trading app I’m building. It connects to people’s real brokerage accounts and learns how each person trades. If I vibe coded it, I might never notice personal info leaking somewhere it shouldn’t. Or Tradion’s memory layer looking like it works while being wired up wrong, quietly giving bad answers instead of crashing. Those are the scariest bugs. The ones that don’t tell you they’re there.
And here’s one most people don’t see coming. When AI gets messy output from another model, its favorite fix is to slap a regex patch or a keyword filter on top. I’ve watched a regex meant to keep a model’s output in one shape silently cut off a real response the moment it didn’t match exactly, instead of failing loud.
Works in the demo. Breaks on the first weird edge case in production. A vibe coder accepts that patch without thinking twice. I banned it completely.
What I do instead: AI-assisted coding
I don’t blindly trust what AI gives me. Everything goes through gates, the same principle behind keeping an autonomous agent from doing something stupid: don’t beg the model to behave; build something that actually stops it.
It starts with an issue. Opus writes the plan. A separate agent, plan-adversary, reviews that plan against the actual codebase, and Sonnet builds it.
Then I have the work verified. Automated tests (functional, end-to-end, smoke tests, and Docker builds) run before anything gets pushed or merged, and only then does it ship. It’s the same shape as the eight-stage review pipeline I run on every change, just compressed.
This isn’t hypothetical, and none of it was vibe coded either. I keep a running account of every Claude Code session, and across 61 of them between July and September 2026, the AI’s own work would have reached production twice if nothing had checked it first.
A “fix” for cleaning up old storage would have let one user delete another user’s data; a separate review pass caught it, not the AI that wrote it. A database migration reached main bundled inside eight commits nobody had reviewed together, one production didn’t have yet; the build broke, and I applied it by hand.
A vibe coder skips every single one of those steps.
I also give the AI written rules. A few from Tradion:
- Numbers come from data, not model memory. Prices, returns, dates all come from real sources. The math happens in code, then the model explains it. If data is missing, say so. Don’t fill the gap. I hold the same rule for every project, not just Tradion.
- No control layers on top of the model. No regex hacks to “fix” output. No keyword blocklists. No homemade JSON repair.
- Provider docs over memory. Check the official docs before touching any AI integration, because model names and features change all the time.
A vibe coder would never write rules like these. They don’t even know the AI makes up numbers.
One honest thing I have to call out. Georgia Tech researchers track security flaws caused by AI-written code. Their Vibe Security Radar is a live-updating tracker, and it attributed 227 of 289 confirmed CVEs to Claude Code as of its August 26, 2026 update. That’s the tool I use every day.
And that proves my point. The tool isn’t the problem. Skipping review is. Same tool, different process, totally different result.
Bottom line
Vibe coding is a sketch. Production is a building people live in.
Sketch all you want. Vibe code the prototype, test your idea, throw it away. But the moment real users or real data show up, the vibes are over.
So learn to code. Actually read what the AI gave you. Understand why it gave you that. Then decide. AI is a really fast junior developer, and you’re still the one who signs off.
Where do you draw the line between a prototype you’d vibe code and something you’d review line by line?