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% 𝘰𝘱𝘵𝘪𝘮𝘪𝘻𝘦𝘥"

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. 😸

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

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.

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?

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

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.

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.