Vibe Coding: Endgame

A developer recounts the rise and fall of 'vibe coding'—using AI to generate code from simple prompts—and explains why the approach breaks down on larger projects. The engineer found that without upfront requirements, architecture, or constraints, AI-generated code becomes unreliable, introducing bugs and regressions as the project grows. The solution, they argue, is to bring back traditional software engineering practices like planning, testing, and clear requirements before prompting AI.

A few months ago, my AI coding workflow looked something like this. Prompt. Generate. Copy. Run. Error. Prompt again. Generate. Break something else. Fix that. Celebrate. If you've ever built something with AI, you've probably lived this cycle. And honestly I loved it and I still do. Vibe coding made building fun again. Ideas that once took me weeks to prototype suddenly came to life in a single evening. Instead of spending hours setting up boilerplate, I could jump straight into creating. It felt like having a senior engineer sitting beside me 24/7. For a while, I thought this was the future of software development. Then I tried building something bigger. That's when everything fell apart. Let's quickly recap what vibe coding actually is. If you've ever opened Claude, Codex, Gemini, Cursor, Windsurf, or your favorite AI coding tool and typed something like, "Build me a dashboard," congratulations. You're officially a vibe coder. The workflow is beautifully simple. You write a prompt, AI generates the code, you copy it, run it, notice something that's slightly off, tweak the prompt, generate again, and repeat until everything looks good enough that you convince yourself you'll "clean it up later." Spoiler alert. You never clean it up later. And honestly, that's not a criticism. That's exactly why vibe coding became so popular in the first place. It removed the boring part of getting started. Ideas that once lived in a notebook for months suddenly became working prototypes over a weekend. Instead of spending hours writing boilerplate, we could jump straight into building. It genuinely felt like software development had unlocked creative mode. Everything is amazing until the project grows. You ask AI to change a button. It changes the navbar. You ask it to fix the navbar. Now authentication breaks. You fix authentication. Half the styling disappears. By this point, your chat history looks less like software development and more like a couple's therapy session. "I asked you to change one thing." "I know, but I thought this would be better." "I never asked for this." Sound familiar? The funny thing is, I blamed AI for a long time. Then I looked at my prompts. "Build me a project management app." That was it. No requirements. No architecture. No constraints. Just vibes. Looking back, I was expecting AI to read my mind. Turns out, it skipped that feature update too. Traditional software development has never started with code. It starts with understanding the problem. Who are the users? What are we building? Which features actually matter? What can wait until version two? That's what the Software Development Life Cycle SDLC has always encouraged us to do. With vibe coding, many of us including me accidentally flipped that process upside down. We generated code first and figured out what we wanted halfway through the conversation. For a quick prototype? That's perfectly fine. For a project that's going to grow? That's where the cracks start to show. I also noticed something else. As the conversation got longer, AI started forgetting context, fixing one issue while introducing another, or confidently generating something I never asked for. At first, I called it hallucination. Now I think many of those moments had another cause. I hadn't given it a clear plan to begin with. As AI-generated projects became larger, developers naturally started bringing more engineering practices back into the workflow. Testing became more important. Instead of accepting whatever AI generated, we'd verify it, write tests, fix issues, and iterate. That made projects much more reliable and reduced a lot of unexpected bugs. For the first time, it felt like AI had a safety net. But I still felt like something was missing. Testing tells you whether you've built the thing correctly . It doesn't tell you whether you're building the right thing . I was still planning after writing the code instead of before it. That was the real problem. The funny thing is, I didn't wake up one morning and think, "Today's the day I become a spec-driven developer." It happened by accident. While building one of my recent projects, I found myself spending almost an hour writing down requirements before generating a single line of code. What features did I actually need? What should never change? Which components should be reusable? What did success even look like? Only after answering those questions did I ask AI to write code. The result surprised me. It wasn't perfect. It's still AI but instead of regenerating the same screen ten times, I was making small improvements instead of complete rewrites. Then it finally clicked. My prompts weren't getting better. They were getting longer. And they weren't really prompts anymore. They were specifications. Without realizing it, I had stopped asking AI to figure things out for me. I had started giving it a blueprint. At least from my perspective, Spec-Driven Development isn't about replacing vibe coding. It's about giving vibe coding a direction. Instead of starting with: "Build me a portfolio website." I now start by answering questions. Who is this portfolio for? Which pages should it include? What technologies should it use? Which components should stay reusable? What shouldn't be changed later? What does a successful result actually look like? Some AI workflows capture these decisions in files like spec.md , requirements.md , tasks.md , or similar planning documents. The filename isn't the important part. The thinking is. You're no longer asking AI to figure everything out. You're handing it a blueprint instead of an empty plot of land. And surprisingly, AI becomes a much better developer when you become a better planner. That's when the title of this article finally made sense to me. The endgame wasn't Claude. It wasn't Gemini. It wasn't Codex. It wasn't a better prompt. It wasn't even AI. The endgame was learning to think before asking AI to think for me. Nowadays, before I ask AI to write code, I usually spend time creating or reviewing an implementation plan. Sometimes I write it myself. Sometimes I let AI generate the first draft, then I edit it. I remove unnecessary features, add missing requirements, and define constraints before a single line of code is generated. Ironically, spending more time before coding has made me finish projects faster. I regenerate less. I waste fewer tokens. I spend less time saying, "No... not like that." And more time reviewing code that actually moves the project forward. I don't think vibe coding is going anywhere. Honestly, I hope it doesn't. It's still one of the fastest and most enjoyable ways to explore ideas, prototype products, and learn new technologies. If I get an idea at 2 AM, I'm still opening an AI coding tool before I open my IDE. That hasn't changed. What has changed is my expectation. I no longer expect AI to magically understand everything from a single sentence. The more capable AI becomes, the more valuable clear thinking becomes. We've already evolved from writing every line of code ourselves to collaborating with AI. Maybe the next evolution isn't becoming a better prompt engineer. Maybe it's becoming a better software engineer who knows how to use AI to their advantage. Thanks for reading I'm curious has your workflow changed over the last few months? Are you still fully vibe coding, or have you started planning more before asking AI to generate code? I'd genuinely love to hear how you're building with AI these days. Feel free to connect with me on LinkedIn https://www.linkedin.com/in/konarksharma13/ . I'd genuinely love to hear how you're building with AI. P.S. The vibes will return.