DEV Community

Cover image for Vibe Coding: Endgame
Konark Sharma
Konark Sharma

Posted on

Vibe Coding: Endgame

Explores why large projects break down

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.
Enter fullscreen mode Exit fullscreen mode

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.

falling apart


The Infinity Prompt

infinity-stones

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.

couple-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

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.

mind

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

3-different-architecture

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.

mevsAI


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 (53)

Collapse
 
francistrdev profile image
FrancisTRᴅᴇᴠ (っ◔◡◔)っ

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.

Suggestion: I would recommend using existing GIFs/images/videos that are not AI Generated and mush them together using CapCut and Pixlr. Both are free and it's fun to do! (Just to stand out more) :)

Collapse
 
konark_13 profile image
Konark Sharma

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.

Collapse
 
francistrdev profile image
FrancisTRᴅᴇᴠ (っ◔◡◔)っ

lol I am looking forward to see your article cover based on this! It would make it unique :D

Collapse
 
codingwithjiro profile image
Elmar Chavez

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.md or SPEC.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.

Collapse
 
konark_13 profile image
Konark Sharma

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.

Collapse
 
codingwithjiro profile image
Elmar Chavez

Thank you @konark_13. It really means a lot.

Collapse
 
ranjancse profile image
Ranjan Dailata

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 😂

Collapse
 
konark_13 profile image
Konark Sharma

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.

Collapse
 
ranjancse profile image
Ranjan Dailata

Thank you for providing the reference for the Spec Driven Development. Here is one more authentic one - martinfowler.com/articles/explorin...

Collapse
 
gulajavaministudio profile image
Gulajava Ministudio

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.

Collapse
 
konark_13 profile image
Konark Sharma

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.

Collapse
 
debashish_ghosal profile image
Debashish Ghosal

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.

Collapse
 
konark_13 profile image
Konark Sharma

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.

Collapse
 
sarahpan profile image
Sarah Pan

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~

Collapse
 
konark_13 profile image
Konark Sharma

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.

Collapse
 
wrencalloway profile image
Wren Calloway

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.

Collapse
 
konark_13 profile image
Konark Sharma

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.

Collapse
 
wrencalloway profile image
Wren Calloway

No problem at all. I hope you have a great day!!!

Collapse
 
quinticus profile image
Quinticus

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! :]

Collapse
 
konark_13 profile image
Konark Sharma

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.

Collapse
 
glenallen profile image
Glen Allen

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.

Collapse
 
konark_13 profile image
Konark Sharma

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.

Collapse
 
mia_keller_ffd2584c046ecb profile image
Mia Keller

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?

Collapse
 
konark_13 profile image
Konark Sharma

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.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.