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.
The Infinity Prompt
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.
The Multiverse of Broken Navbars
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.
We Needed a Better Plan
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.
Rise of the Specs
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.
Endgame
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.
Post-Credit Scene
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. I'd genuinely love to hear how you're building with AI.
P.S. The vibes will return.







Top comments (35)
Love the title and the article lol.
I have been doing a hybrid where I use AI, but also discipline myself to do the manual work in some circumstance that allows me to learn and grow. Takes practice, but it works out.
Thank you so much for your kind words, Francis.
Going hybrid is a good choice, it helps us be a better developer and use AI to our advantage. This way, we can write code and also understand the code to be generated. Lovely approach keep it up.
Your suggestion sounds interesting. I love it in your articles how you integrate all of the cool gifs and title. Your recent Doctor Doom with Top7 is an amazing example. I would love to try and learn from you, Sensei.
You may call it as Spec driven development or whatever that sounds good in the age of AI; Ultimately, it all boils down to Behavior Driven Development (BDD).
Welcome to the old age with the new fancy terminologies 😂
BDD is the real name of it. Sounds interesting. Everyone have their own terminologies for new tech. Thanks for pointing it out.
Spec Driven Development this was starting point to learn and know about it and they coined it so I have used it.
Thank you for providing the reference for the Spec Driven Development. Here is one more authentic one - martinfowler.com/articles/explorin...
Totally agree! We've definitely moved away from the traditional 'vibe coding' approach. Now, it's all about focusing on specs and planning before letting the AI execute the code. That's exactly why we're seeing features like GitHub Spec Kit and Plan Mode becoming standard in AI tools right now.
By the way, I actually created an SDLC (Software Development Lifecycle) workflow skill around this concept. I shared it in my recent article here: Accelerating Your SDLC with AI: Awesome Copilot ID v1.7.0 Released!
Feel free to check it out! It might make your AI coding experience even smoother and more fun.
That's actually sounds good and the article is amazing to read. I'll surely check it out in my next AI session. Thank you for creating this and elevating our use with AI.
Personally, I don't want to use AI-generated code entirely especially if I don't understand what the code is all about. I don't like adding a line of code that I can't explain myself (I feel like I'm just lying to myself and I hate liers). But I always take advantage of the super advanced search feature of AI whenever I have questions and I kinda liked that. But I still have to double check it myself for best practices and officials docs just to be sure. My process is slow but I 100% assure you, it is genuine learning.
For my workflow, I always have a "discussion" first with the AI so that context building is not forced such as creating
TASKS.mdorSPEC.md. The point is to be conversational and that naturally builds up what I want to do with my project. Sometimes the AI gives good points, some bad ones, it's like taking tradeoffs one after another in a meeting.Once I have the features listed, I move forward to building them one by one, and the pattern revolves again. I get to learn and upskill slowly but consistently. It worked for me and at the same time it boosted my communication skills, so two birds with one stone.
Lovely explanation, Elmar. I'm truly honoured to have read such a beautiful comment. The way you have explained your workflow and how you are using AI to your own advantages shows how good of a developer you are.
Rome wasn't built in a day. Your progress feels the same, it's slow and burning but ultimately it is providing you the utmost features and making you a better developer by doing everything in your hands and taking the control from AI and just using it as an observer to help you find mistakes and get better. Congrats on killing two birds with one stone, being a better developer and getting good at communication. This shows how dedicated you are to this field. I hope and pray for your success even more. Hope you become the best of the best.
Thank you @konark_13. It really means a lot.
This was an interesting read. I'm not a vibe coder since I like to type everything by hand, and I was always kind of wondering how vibe coders made their apps. I knew vibe coders couldn't just say "Build me an app." So I was expecting the prompting to be around the "test-driven architecture." So seeing the "spec-driven architecture" style was pretty interesting to me, I learned something new.
I'm not sure if I'm going to be applying any of this since, again, I like writing code by hand (it'll help me stand out as an aspiring SOC Analyst, too). But I'm sure knowing how spec-driven prompts work could help me in the future, should I see myself using AI agents. Thanks! :]
Wow, SOC Analyst. Lovely and congrats and god bless on your journey. I hope you becomes the best SOC Analyst. I'm glad I was able to add values to your knowledge-base.
You can definitely try this architecture and build some cool side projects that way you can learn and be able to find vibe coding useful to you or not.
I love your sharing and I had a similar experience with Vibe Coding!
I really like your analogy comparing couple's therapy session to the communication between you and the AI. Actually, I now realize that establishing clear guidelines with the AI and asking each other questions to define the framework before making any requests is actually quite similar to how couples communication~
Thank you so much Sarah.
Yes, Couple's therapy session analogy came from re-reading the chats with AI where I tell it to do one thing and it behaves like a girlfriend for me and does the opposite. I asked it to do some changes and suddenly button stopped working and when button started working something broke. So, I needed to evolve and get better at it and started using spec driven development.
Healthy post. As for me I have for some reason been a lazy syntaxer but more interested in architecture which over the years built an intuition that supports my now vibes in coding 👍, Even WhatsApp meta can build a sophisticated platform depending on how you use it 😉
Yeah, great line WhatsApp meta can build a sophisticated platform depending on how you use it then it will have connectors to Instagram, Meta, Facebook, WhatsApp and all of them can be hacked with one prompt injection. 😆
The platform matters less than how you use it 😀"
The "endgame" framing is interesting but I think it misses the real tension. Vibe coding works great for prototyping and greenfield side projects — I've shipped entire weekends worth of ideas in hours using AI assistants. But the moment you hit a production bug at 2am involving race conditions in async code, or a subtle memory leak in a long-running service, vibe coding hits a wall. The issue isn't whether AI can write code — it's whether the person directing it understands enough to verify correctness. The endgame isn't vibe coding replacing engineering; it's vibe coding becoming a power tool that requires even more engineering judgment to use safely.
Excellent Point, Alex. Yes, exactly at 2am bugs vibe coding hits the wall. A perfectly valid point "The issue isn't whether AI can write code — it's whether the person directing it understands enough to verify correctness." Yes, I agree with your points of vibe coding becoming a power tool, but if it got engineering judgement than it will not be vibe coding anymore. Vibe coding was introduced so that anyone can generate whatever they want, if we add engineering judgement to it then non-technical person wouldn't be able to judge perfectly and let the AI hallucinate or generate wrong text. The way it is headed is good, if we generate spec file and tell our specifications then we might get a better output.
Great read! Spot on about how quickly "vibes-only" coding hits a wall once complexity scales.
I’m curious—how granular do you usually make your initial specs before handing them to AI? Do you keep it high-level (like a brief architecture outline) or break it down into detailed step-by-step task lists per component?
Thank you so much for your kind words, Mia.
Currently, I'm exploring the initial spec files. I use AntiGravity to vibe code so it generates the Implementation Plan and I do an overview of it that what tasks needs to be updated or removed. I like to break it into architecture based and detailed as well. I explain in the prompt what architecture it should use and technologies to build on and some specific details as well and then I verify the steps and move the production forward if I like the implementation plan. But, I have seen and read spec files that are used in Claude as well they are a bit specific and detailed.
yeah. my own test for when it is time to stop vibing is when a requested change needs a paragraph of 'but don't touch...' context. that is usually not a prompt problem anymore, it is a missing contract. specs do not have to be heavy, but a few invariants and a clear success condition save a ridiculous amount of backtracking.
Great lines, Mike. Ofcourse, mentioning every file name and then adding don't change this is stressful act. Exactly, spec file don't have to be heavy, but rather a fix instructions and how you want AI to follow the steps. If there will vagueness in the spec file, AI might hallucinate.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.