Vibe coding process - do we jump in or plan it out?

I would definitely never jump into an AI development tool without having these 2 things cleared out:

• What is the problem im trying to solve (clearly written down)

• How I am solving this problem (clearly written down)

Jumping into vibe coding without these 2 things, you are probably rich. Cause it means you have a lot of time to waste iterating, fixing, debugging, cleaning etc. And especially when no one is watching. That's a luxury of the rich person. Only if we had infinite amount of time right?

I personally use v0.dev due to my tech knowledge being around JS/TS/NodeJS/NextJS.

I use this prompt to kick things off fast, ONCE i have the things i mentioned earlier clear.

" 𝘊𝘳𝘦𝘢𝘵𝘦 𝘢 𝘷𝘦𝘳𝘺 𝘤𝘭𝘦𝘢𝘳 𝘢𝘯𝘥 𝘧𝘶𝘭𝘭𝘺 𝘳𝘦𝘴𝘱𝘰𝘯𝘴𝘪𝘷𝘦 𝘢𝘤𝘳𝘰𝘴𝘴 𝘢𝘭𝘭 𝘥𝘦𝘷𝘪𝘤𝘦𝘴 𝘢𝘱𝘱 𝘵𝘩𝘢𝘵 𝘩𝘢𝘴 𝘵𝘩𝘦 𝘧𝘰𝘭𝘭𝘰𝘸𝘪𝘯𝘨 𝘧𝘶𝘯𝘤𝘵𝘪𝘰𝘯𝘢𝘭𝘪𝘵𝘺:
1. 𝘈𝘶𝘵𝘩𝘦𝘯𝘵𝘪𝘤𝘢𝘵𝘪𝘰𝘯 𝘸𝘪𝘵𝘩 𝘚𝘶𝘱𝘢𝘣𝘢𝘴𝘦 𝘢𝘯𝘥 𝘢 𝘷𝘦𝘳𝘺 𝘮𝘪𝘯𝘪𝘮𝘢𝘭 𝘋𝘉 𝘴𝘤𝘩𝘦𝘮𝘢 𝘵𝘰 𝘴𝘵𝘰𝘳𝘦 𝘶𝘴𝘦𝘳 𝘪𝘯𝘧𝘰.
2. 𝘈 𝘮𝘪𝘯𝘪𝘮𝘢𝘭 𝘣𝘶𝘵 𝘷𝘦𝘳𝘺 𝘣𝘦𝘢𝘶𝘵𝘪𝘧𝘶𝘭 𝘜𝘐 𝘵𝘩𝘢𝘵 𝘪𝘴 𝘢𝘭𝘪𝘨𝘯𝘦𝘥 𝘵𝘰 𝘵𝘩𝘦 𝘪𝘮𝘢𝘨𝘦 𝘐 𝘢𝘮 𝘢𝘵𝘵𝘢𝘤𝘩𝘪𝘯𝘨 (𝘩𝘦𝘳𝘦 𝘪 𝘢𝘵𝘵𝘢𝘤𝘩 𝘢𝘯𝘥 𝘪𝘮𝘢𝘨𝘦 𝘸𝘪𝘵𝘩 𝘯𝘢𝘮𝘦: 𝘪𝘥𝘦𝘢𝘭𝘶𝘪)
3. 𝘛𝘩𝘦 𝘢𝘱𝘱 𝘪𝘴 𝘢𝘣𝘰𝘶𝘵___________________________ .
4. 𝘛𝘩𝘦 𝘤𝘰𝘥𝘦 𝘴𝘩𝘰𝘶𝘭𝘥 𝘣𝘦 𝘤𝘭𝘦𝘢𝘯, 𝘸𝘪𝘵𝘩 𝘢 𝘧𝘶𝘯𝘤𝘵𝘪𝘰𝘯𝘢𝘭 𝘱𝘳𝘰𝘨𝘳𝘢𝘮𝘮𝘪𝘯𝘨 𝘱𝘢𝘳𝘢𝘥𝘪𝘨𝘮 𝘧𝘰𝘤𝘶𝘴, 𝘢𝘯𝘥 𝘸𝘪𝘵𝘩𝘰𝘶𝘵 𝘶𝘯𝘯𝘦𝘤𝘦𝘴𝘴𝘢𝘳𝘺 𝘳𝘦𝘳𝘦𝘯𝘥𝘦𝘳𝘴 (𝘵𝘩𝘪𝘴 𝘪𝘴 𝘷𝘦𝘳𝘺 𝘙𝘦𝘢𝘤𝘵/𝘕𝘦𝘹𝘵𝘑𝘚 𝘳𝘦𝘭𝘦𝘷𝘢𝘯𝘵) .
5. 𝘔𝘢𝘬𝘦 𝘴𝘶𝘳𝘦 𝘵𝘩𝘦 𝘜𝘟 𝘰𝘧 𝘵𝘩𝘦 𝘢𝘱𝘱 𝘪𝘴 𝘷𝘦𝘳𝘺 𝘤𝘭𝘦𝘢𝘳 𝘢𝘯𝘥 𝘵𝘩𝘦 𝘷𝘢𝘭𝘶𝘦 𝘦𝘹𝘵𝘳𝘢𝘤𝘵𝘦𝘥 𝘣𝘺 𝘵𝘩𝘦 𝘶𝘴𝘦𝘳 𝘪𝘴 100% 𝘰𝘱𝘵𝘪𝘮𝘪𝘻𝘦𝘥"

Back in my coding days, we used to get a Software Requirements Specification (SRS) document from a software analyst. That doc had everything we were supposed to code, from the user-facing stuff to the hardcore implementation details.

In vibe-coding, we're essentially the software analysts, and the AI is the developer. Why not send SRS-prompts?

• Functional requirements (what the software should do)

• Non-functional requirements (performance, security, database, etc.)

• Use cases or user stories

• Constraints and assumptions

• Glossary of terms

• Business logic

• User flows and interactions

This systematic approach is exactly what we teach in Enlighter!

As nervous first-time launchers, seeing you break down gives us much hope that we're actually solving a problem real people have.

@gabe, what's one thing you'd tell us to improve before our launch?

Coming soon page: https://www.producthunt.com/products/enlighter

Thanks for the gold! 🙏

Great points Gabe! I think curor and Bolt.new are targeting developer as audience for their daily works, especially for coding. However, business owners and UI/UX designers/PMs have different use cases. For business owners, the perfect use case is to use one prompt only to generate a working and functional website prototype instead of generating coding for a website then modify the codes. Those are totally different markets and target audience.

So far per my experience, Claude Sonnet 3.7 is much, much better than ChatGPT for code generation. So for SMBs or other non-coding background free lancers or solopreneurs, a tool can be used to generate an app with pure human language is much desired. And I think it is a bigger and incremental market than developers.

1. What's the problem?

2. What other solution(s) have been solved?

3. How is my solution different?

Bonus: WHO is my solution different and better for?

Always use an instructions.md or AI-Instructions file to dictate house style, give your AI assistant some ground rules, etc...

Like Notorious BIG (Biggie) said: I wrote a 10 step booklet for ya'll to read. https://eoncodes.substack.com/p/how-i-built-an-ai-wrapper-saas-in I can repost here on p/vibe if ya'll want? Let me know. TL;DR: I think neither dive in or plan it out. Start with something your extremely passionate about. Then adrenaline will take you from zero to one. Vibe code or no vibe code. Thats how it works for me at least. Time and space just vanish around you and before you know it, you have something working in no time. 😸

Please don't jump in. Always plan it out.

Added benefits of planning out is that the end outcome will always be more polished and you will get to the end out come sooner rather than later.

As a PM, I've found that mimic-ing how IRL product teams build products is what seems to strangely also work best for vibe coding. After much iteration I've landed on:

• A 'PM agent' that kicks off things by asking me 3 things - what's the problem i'm looking to solve, who's the user i want to solve for, and what are the initial features I'd like to start from.

• Agent's output is a PRD, and a set of User Stories with acceptance criteria.

• Use these User Stories as input, and ask to start coding from a small subset of these for the initial version.

• Finesse by talking with LLM until I get this right.

• Iteration: Inputs are entire set of User Stories again + code + instructions on which story to build next.

I must add I build prototypes primarily, so don't care at all about backend/ security etc as goal is to validate concepts with users fast. Throwaway code is perfect for prototyping.

I bounce of ideas with grok or chatGPT and come up with a plan. What features the MVP will have, etc. then start vibe coding. But I use @Replit to vibe code, not bolt or cursor.

First jump into Claude and ask it to generate a prompt for Cursor about the project.
Then jump into Cursor and ensure Agent mode is on and enter the prompt from Claude.

Great workflow! I would only add:

1.) Dont be afraid to bring in other opinions early (Claude, Gemini, Grok) to validate/question the approach. Lots can be learned here, saving you days (weeks?) of frustration later. Worth spending a few hours. Ive seen GPT recommend an approach that was outdated by a few months - Grok caught the issue and directed me to a new SDK that GPT wasn't aware of.

2.) Cursor rules (.mcp)

3.) Feed your agent official documentation for the tech stack you are building in. Your AI Agent will absolutely lie to you and tell you its read the documentation. Pro -tip: It hasn't, lol.

Measure twice, cut once as they say!

Thinking about what you're trying to do, writing it down, and then iterating on it is probably the best way to be productive, rather than using the hunt-and-peck method of coding.

Slow is fast, as they say.

What you're describing also sounds like the Reasoning step that LLMs now use to plan out their next steps — so if it's good enough for LLMs, it should be a lesson to humans too!

Lastly, maybe give ChatPRD a try?

Totally relate to the part about dumping all your ideas into ChatGPT first—I do the same. It helps so much to just get the chaos out of your head and let the AI turn it into a clean plan. Makes jumping into Cursor way less overwhelming.

Just plan it out pls, no one needs more tech debt and someone snooping in their data or being a proxy for bad actors or data waiting to be added to some shady DB someone will sell for a quick buck. The quick buck quest has given way to bad practices in hiring and misuse in employment, everyone is unemployed and soon no one will be able to buy your stuff. This way you are just helping to big bros and small biz is screwed up. Ofc they give AI credits to “innovative” startups - they will just suck you all in and throw you away. Be empathetic and aware of the effect of “fast shipping” and the hype around it.

@gabe Love this breakdown. Super helpful for someone like me, ust kicked off a 30-day build with zero coding experience, trying to turn an idea into something real with AI as my co-pilot.

At first I was all in on the “just prompt and go” vibe, but I hit walls fast. I’ve started doing something similar: framing the problem clearly, rough-sketching how the flow should feel, and using ChatGPT to translate my chaos into semi-logical steps.

Still early days, but this thread is helping me rethink how to keep things focused without killing momentum. Appreciate you sharing your process, bookmarking this for every future panic spiral.

usually when i vibe code i do it for work on my thesis project in python data analysis, i created an app that uses my scripts in a user friendly way, to do that i used cursor, integrating a defined and niche specific .cursorrules file and also recently i updated a new version of memory-bank-cursor repo that uses also task master for task generation and subsequent buiding. this system helps me having a very good workflow with memory of my project constantly saved in order to make the AI more context aware and make it easier for it to generate working code having accurate step b step instructions. of course this method wont create you the final app of your dreams, but for sure you will have a solid starting point or even an MVP depending on your goals and difficulty of the concept

Hope i helped you!

Hey, super agree with your points, as a backend engineer (in the past, now I'm an engineering manager), I believe every vibe coder has to understand data flow and storage at the conceptual level. You can always rewrite frontend logic or tweak the UI, but once your customers start using the product and you realise a week later that the data model isn’t right, migrating it becomes a real headache, and no AI tool can save you from that 😀.

It might sound simple, but you must understand how your project works and be able to explain the data flow to someone else.

Curious to hear your opinion, I might be biased by my backend experience

I completely agree with your approach to structure before coding. The most critical step that's often overlooked in vibe coding is defining a solid architecture before writing your first prompt.

What I've found essential is maintaining strict control over this architecture - don't let Cursor or any AI make architectural decisions on the fly. When the AI suggests structural changes, take significant time to evaluate them before implementation. The fundamental challenge with vibe coding is that its default objective is "make it work at any cost" rather than "build something scalable, maintainable, and modular."

This distinction became crystal clear when I built my document retrieval system. I've spent over a year developing an internal API that offers a fundamentally different approach to document retrieval - moving beyond traditional vector or full-text search to an AI-first methodology. While I never initially planned to release it publicly, I recently decided to test vibe coding by building an admin UI for this API.

The results were honestly astonishing - in just one week I was able to complete the entire frontend system for https://spyk.io. However, it's important to note that the AI didn't write any backend code (except adding documentation comments). The core functionality required careful human architecture and implementation.

The key takeaway: stay ahead of the AI, understand every piece of your codebase, and maintain control over why things are built a certain way. When you establish these guardrails, the speed at which you can ship becomes truly remarkable.

For me it depends... of course! 😉

@Cursor with a thinking model is able to figure out a lot on its own meanwhile. But I put dedicated project cursor rules in place to guide it. They keep evolving and get expanded over time, they might for example including instructions on which testing framework to use, what copy I want in the app or instruction to avoid pitfall with some libraries (e.g. when it tends to use a deprecated or even abandoned API).

In addition to that, I really like to work with it like I would with a team. What I mean by that is that I create markdown artifacts for the product roadmap, feature requirements and all kind of other documents. Then I include these in the context as needed, or have Cursor operate on them ("Group features from this or that markdown and create a sequence of 4 releases").

I try to stay within Cursor most of the time though, just because it is a great workflow, the standard models are powerful enough and the UI/UX also works for me, especially with the inclusion of markdown files for output and input (in addition to Cursor's own history in the Chats, which are hard to manage over time and become too messy).

And one other super useful technique is to tell the agent to ask any questions it might have before making changes. This gives it an opportunity to get missing information from the user instead of making (bad) assumptions, so it can play a more active role in gathering requirements easily as well. 💪

Hi Gabe,
Love this breakdown — it really resonates!

I used to jump straight into prompting too and ended up in this messy loop of rework and confusion. What changed the game for me was switching to a workflow tool that mirrors the exact structure you're describing — it's called Vybcoder.

It simplifies the "plan → prompt → build" cycle into 3 clean steps:

🔹 PLAN: I define the problem + goal in plain English, select only the files/folders that matter, and Vybcoder helps convert this into a precise AI prompt.

🔹 GENERATE: I run that prompt on my preferred AI (GPT-4o, Claude, Gemini—you’re not locked in), and the responses are way sharper thanks to better planning.

🔹 APPLY: Vybcoder parses the AI output and updates multiple files instantly, safely, and locally. No manual edits. Just apply and move forward.

It’s great because I stay in control while getting consistent structure. Plus, it’s repo-native, cross-platform, and doesn’t force me to change how I code — just enhances it.

Curious to know if anyone else here has tried structured prompting with file context? It’s been a game-changer for me.
https://www.producthunt.com/products/vybcoder?utm_source=other&utm_medium=social
It’s built for devs, indie builders, and anyone who wants to move fast without losing control of their code.

Would love your thoughts, feedback, or questions!

🔗 https://vybcoder.com