A few months ago, my AI coding workflow looked something like this.
Prompt.
Generate.
Copy.
Run.
Error.
Prompt again.
Generate.
Break something ...
For further actions, you may consider blocking this person and/or reporting abuse
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.
lol I am looking forward to see your article cover based on this! It would make it unique :D
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.
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.
Appreciate the honesty here, Konark. The "large projects break down" thesis resonates — I've seen the same pattern where the first 80% feels magical and the last 20% turns into debugging someone else's assumptions. What I'm most curious about: when you hit the wall, did you find specific project characteristics — codebase size, team size, architectural complexity — that seemed to correlate with the breakdown? Trying to figure out where the line actually is.
Well said, Debashish. From my experience, the last 20% hits when AI loses it's memory. As earlier it was developing great and following and understanding all the context. But when suddenly it hits the wall of memory full then it tends to hallucinate and make changes in other files as well. I have never found these - codebase size, team size, architectural complexity as I keep my project light. I think vibe coded relies more on memory and prompts so if both of these aren't working properly then I might hit the debugging wall.
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.
The failure mode you'll hit next is the spec drifting from the code. You write a beautiful spec.md, the AI implements 80% of it, then over the next twenty edits the code quietly grows features and constraints that were never written down — and now your spec lies. Six weeks later you hand the spec to the model as ground truth and it "fixes" things back to a state the app hasn't been in since day three.
The thing that actually saved this for me wasn't writing the spec, it was treating it like code that rots: the spec is only trustworthy if something forces it to stay honest. Tests are that forcing function, but pointed backwards — not "does the code work" but "does the code still match what the spec claims." When those diverge, one of them is wrong and you have to decide which, on purpose, instead of letting the model decide silently.
So I'd push your conclusion one step further. The endgame isn't thinking before you ask — it's keeping the artifact that captured your thinking synchronized with reality, because a stale blueprint is more dangerous than no blueprint. An empty plot of land at least doesn't lie to you about what's already built on it.
Valid Point, Wren. You are right, The next 20 edits are done without the spec file. Just prompting and adding more features. The testing point is valid as well to add test cases to test whether the code still match what the spec claims. I'm still new to spec-driven architecture. But your points compelling me to read more about before acting on it. Your conclusions are spot-on. Thank you for pushing my conclusions to one step further.
No problem at all. I hope you have a great day!!!
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.
One thing I'd add is that the endgame isn't about writing less code, it's about making better engineering decisions. As implementation becomes easier with AI, architecture, validation, security, and understanding business context become the real differentiators. The value shifts from producing code to ensuring the right solution is built.
Exactly, Glen. When implementation is easier business context become difficult. Before building we have to do research whether this is a great build, what could my MVP and the vulnerabilities. When developing with AI, AI mostly focuses on building rather than securing so we get the best output with least security. So, while developing we need to keep architecture, validation, security, and understanding business context in mind as well.
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.
There are no non-developers in this thread, so I'll take that seat.
I'm a physiotherapist. I've shipped 20+ internal tools that a hospital runs on, and AI wrote nearly all of the code. Spec-driven development is right, and I want to add the part that only becomes visible from here.
For a developer, a spec is a plan. For me it is also the only thing standing where code review would be, and that's a much heavier load than it looks. You can write a spec and then read the diff to see whether you got it. I can't. So my failure mode isn't wasted tokens or rewrites — it's a system that satisfies the spec I wrote while quietly violating the one I meant, with nothing in the loop able to tell me the difference.
What actually moved the needle wasn't better specs. It was making verification mechanical, precisely because I'm structurally unable to do it by reading. I plant known-bad files and require the scanner to still catch them. I deliberately break each guard and require it to go red for its own reason, not just to fail. The last time I ran that, my scanner caught seven of ten planted defects — a number I would never have guessed, and one no spec could have produced.
So I'd put it this way: spec-driven development assumes you can evaluate compliance. If you can't, the spec is necessary and nowhere near sufficient.
Very valid points. Breaking guardrails and planting bugs deliberately to check the vulnerabilities is the best idea to test a product.
You are right in saying this: spec-driven development assumes you can evaluate compliance. If you can't, the spec is necessary and nowhere near sufficient.
Thanks — and your post actually changed my spec template yesterday, so let me hand back the concrete version.
My specs already had a "definition of done" line, written as something checkable: "log in as admin, click X, Y appears." Reading your piece made me notice every one of those was a success sentence. Nothing in the spec asked whether that check would fail if the feature broke.
So the field is now a pair. Left column: what passes. Right column: what it should look like when I break it on purpose — "drop the role to department lead and Y disappears with a permission error." And the rule is that I have to run the right column before I'm allowed to call it done.
The useful surprise is how hard the right column is to write. When I can't say what broken looks like, it turns out I don't understand the requirement yet — which is a spec problem you can catch during planning, not a testing problem you find in production. That part is entirely your thesis; I'd just been stopping one column too early.
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.
Interesting take on vibe coding. I think the real tension isn't between "vibe coding" and "real engineering" — it's between two very different workflows that both have legitimate use cases.
Vibe coding (AI-assisted rapid prototyping) is incredibly powerful for exploration: testing ideas, building MVPs, and learning new patterns. The problem is when people treat it as the entire development lifecycle rather than just the starting point.
What I've found in practice is that the most effective approach is a hybrid: use AI tools for the "vibe" phase (rapid iteration, boilerplate generation, exploration), then apply traditional engineering rigor for the "endgame" phase (testing, security review, performance optimization, maintainability).
The real skill gap isn't "can you code without AI?" — it's "can you tell when the AI-generated code is good enough vs. when it needs manual refinement?" That judgment comes from understanding fundamentals, not from more prompting.
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.
I enjoyed this article. I think there's one more piece to the puzzle.
Specs make AI far more effective because they reduce ambiguity. But I don't think specs are the endgame either.
If an AI builds a project from a brilliant specification and tomorrow that AI disappears, can you confidently extend it, debug it, or rebuild critical parts without starting over?
Production has a way of exposing what reviews can't. Bugs, scaling, performance issues, and changing requirements don't ask whether the code came from a spec—they ask whether the engineer understands the system.
To me, AI is shifting the bottleneck. Syntax is becoming less important than reasoning, architecture, and debugging. Those are the skills that survive when requirements change or production throws something unexpected at you.
So I'd say the evolution isn't just:
Vibe Coding → Spec-Driven Development.
It's:
Vibe Coding → Spec-Driven Development → Understanding-Driven Engineering.
Specs help AI generate better code. Understanding helps humans keep that code alive.
Valid point Ekong.
It's: Vibe Coding → Spec-Driven Development → Understanding-Driven Engineering.
This could be the future and another evolution for vibe coding. If AI starts understanding the intent then maybe we might have achieved the perfect AI to build something. Maybe like Jarvis for Tony Stark.
Konark, I could definitely relate to the part about spending more time planning before asking AI to write code.
I've noticed that the clearer the requirements are, the fewer times I end up saying, "No... not like that" 😄 It feels like a little more thinking upfront saves a lot of back-and-forth later. Thanks for sharing!
Very well said, Hemapriya. The back-and-forth feels like teaching a kid how to play but each time it forgets some instructions and go wandering off on it's own, making us feel helpless and then start teaching from zero. Like you said "The clearer the requirements are, the fewer times you say". It's like I typed a big paragraph to explain it but then it completely forgets it and do something on it's own. Wasting my time and tokens.
This perfectly describes my current workflow struggles! I love the idea of giving AI a blueprint instead of an empty plot of land.
Out of curiosity, when you write your implementation plan, do you usually do it entirely by hand, or do you ask AI to help you structure the spec first? Would love to hear your thoughts. Thanks for the great post!
Hi, I'm glad you liked it.
Now to answer your question, I try to avoid writing with hands as I have limited memory and can't go better at defining specs than AI so I leverage my tasks to AI and ask it to create by giving it specifications and if I don't like anything I tell it to reiterate the spec file. What's your flow looks like? You create by hands or use AI?
Hey Konark,
Remember that video of Peter on LinkedIn? You should totally add it to your article about vibecoding — it fits perfectly. Hehehe :)
That's such a great idea, Ben. I'll use that in my next article. Maybe, till then you might also find your Luis 😆.
Yes, I will bring Luis with me. I will have another Peter. hehehee....:).
ngl the shift to just describing the vibe instead of writing boilerplate is wild. wonder how this handles complex state management though.
ngl my workflow is basically just vibing and hoping the LLM doesn't hallucinate the entire state management lol
That sounds like a cool plan. You can also read and try spec driven architecture, that way you won't have to rely on LLM's hallucinations and you can get even better results.
finally someone talking about the actual flow, the "vibe" part is basically just high-level orchestration at this point lol
Developers need requirements, so does AI. It's obvious but sometimes we need someone saying the obvious.
Exactly, Victor. We need sometimes need someone to point the obvious. But, the initial requirements were a nightmare for me, the context window, AI hallucinating and giving wrong outputs and the changes I suggest broke the code in another file. The requirements and AI models are getting better.
Totally agree!