Why Vibe Coding Will Hurt Your Career (And What to Do Instead)

Last week I wrote about how AI tools transformed my work as a Product Manager. I build prototypes in Cursor. I ship demos in v0. I've saved hundreds of hours. But there's a dangerous trap I see people falling into—and I almost fell into it myself. It's called **vibe coding.** ## So What is Vibe Coding?? Andrej Karpathy, co-founder of OpenAI and former AI leader at Tesla, coined the term in February 2025. He described it as a new kind of coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." His exact words: "I 'Accept All' always, I don't read the diffs anymore." The workflow looks like this: You prompt the AI. It generates code. You accept it without reading. It runs. You ship. Karpathy himself noted it's "not too bad for throwaway weekend projects." That is because the key word there is "throwaway." Here's what happens when vibe coding meets real projects. ## The 80% Problem This is where vibe coding falls apart. You're building a feature. The AI generates code. It works in your demo. You feel like you're 90% done. Then suddenly—nothing works. That is because AI doesn't handle edge cases. It doesn't optimize for scale. It doesn't think about production concerns. That last 20%? It's not a junior dev's job anymore. You need someone who actually understands the code. And here's the painful truth: fixing someone else's mess is harder than writing from scratch. Your first engineer hire will probably want to burn everything down and start over. ## Security Vulnerabilities You Can't See This is the one that scares me most. A recent audit of apps built with Lovable (a popular vibe coding tool) found that **170 out of 1,645 applications had security vulnerabilities**—exposed API keys on the frontend, hardcoded credentials, SQL injection vectors, insecure authentication patterns. The developers didn't know these were problems because they never looked at the code. They lacked the architectural understanding to spot the issues. The AI generated plausible-looking code, but plausible isn't the same as correct. For eg., I recently reviewed a prototype a colleague built with AI assistance. The code looked clean. It worked. But the API key was being sent in the frontend JavaScript. Anyone with browser dev tools could extract it. They had no idea. They hadn't read the code. ## Debugging Becomes Practically Impossible Here's a scenario I've seen play out multiple times: Code breaks in production. The developer who built it tries to fix it. But they didn't write the code—the AI did. They have no mental map of how the logic flows. They don't understand why certain decisions were made. One experienced engineer described debugging AI-generated code at scale as "practically impossible." Unlike traditional debugging—where you analyze call stacks, state transitions, and system logs—vibe coding reduces the process to guesswork. You're prompting the AI to fix something you don't understand, hoping it gets it right this time. This undermines reliability and reproducibility. When you can't explain why something broke, you can't guarantee it won't break again. ## Technical Debt Compounds Exponentially This is where the math gets ugly. Each "vibed" solution becomes a black box. You don't understand what's inside. But you build on top of it anyway. Then you add another black box. And another. Soon you're building on foundations you don't comprehend. Dependencies become a mess. Subtle bugs creep in. The AI doesn't track overall design—it doesn't remember that the function it generated three prompts ago is incompatible with the module it's generating now. Technical debt compounds exponentially when you don't understand your own code. In September 2025, Fast Company reported that the "vibe coding hangover" had arrived. Senior software engineers were citing "development hell" when working with AI-generated vibe-code. The speed of initial development had created maintenance nightmares. API evangelist Kin Lane put it bluntly: "I don't think I have ever seen so much technical debt being created in such a short period of time during my 35-year career in technology." ## The Paradox: It Works Best for Those Who Don't Need It Here's the irony of vibe coding: Experienced developers can use AI coding tools effectively because they know what to look for. They can spot security issues, architectural problems, and anti-patterns. They can review the generated code and catch mistakes. Junior developers—the ones who most want the shortcut—are the most vulnerable. They lack the pattern recognition to distinguish good AI-generated code from plausible-but-dangerous code. When AI generates code with security vulnerabilities, performance bottlenecks, or architectural inconsistencies, junior developers often can't spot the issues. They're not familiar enough with common pitfalls to know what to look for. The tool that promises to make coding accessible actually requires deep expertise to use safely. ## The Critical Distinction Simon Willison, a well-respected developer and AI commentator, makes a crucial distinction: "If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else—that's not vibe coding, it's software development. The usage of an LLM to support that activity is immaterial." This is the key. Using AI to write code isn't the problem. Accepting AI-written code without understanding it is the problem. ## What to Do Instead Here's how I use AI coding tools without falling into the vibe coding trap: **1) Never Accept Blindly** Treat AI-generated code like code from a new hire. Review every line. Make sure you understand it. If something doesn't make sense, don't assume the AI knows better—often it doesn't. **2) Build to Learn, Then Hand Off** I use AI prototypes to validate ideas and discover constraints. But those prototypes aren't production code. Engineering rebuilds them properly, with the insights I gathered from the prototype. **3) Use AI for Acceleration, Not Abdication** AI tools are incredible for speeding up work you already understand. They're dangerous for doing work you don't understand. **4) Maintain Your Mental Map** If you can't explain how your code works, you don't own it. Make sure you can trace the logic, identify the failure modes, and debug without AI assistance. **5) Know When to Go Slow** For throwaway prototypes and weekend experiments? Vibe away. For anything that will see production, have users, or need maintenance? Slow down and understand what you're shipping. ## In a Nutshell Vibe coding is seductive. It feels like a superpower. You're shipping features in hours instead of days. But you're not building software. You're accumulating time bombs. The developers and PMs who thrive in the AI era will be those who use AI as a tool—not a replacement for understanding. And the best part? When you stay in control, AI tools are genuinely incredible. They accelerate everything. They handle boilerplate. They help you explore possibilities faster than ever. Just don't let the vibes replace the thinking. Excited to delve deeper? In next week's post, I will share my framework for reviewing AI-generated code—the specific checks I run before accepting anything into a codebase. Additional documents to read on this: - [Karpathy's Vibe Coding Considered Harmful](https://nmn.gl/blog/dangers-vibe-coding) - Namanyay Goel - [Understanding Vibe Coding Limitations](https://graphite.com/guides/limitations-of-vibe-coding) - Graphite - [The Case Against Vibe Coding](https://www.theserverside.com/tip/The-case-against-vibe-coding) - TheServerSide - [Vibe Coding Wikipedia](https://en.wikipedia.org/wiki/Vibe_coding) - Overview and history - [Simon Willison on Vibe Coding](https://simonwillison.net/2025/Mar/19/vibe-coding/) - Critical distinction Stay tuned!!