--- slug: vibe-coding-why-planning-matters title: "Vibe Coding: Why Planning Still Matters" excerpt: "Vibe coding doesn't mean no planning. The people who ship with Cursor, Lovable, or Claude do ten minutes of thinking first — here's what that looks like." primaryKeyword: "vibe coding" publishedAt: 2026-04-02 readingTimeMin: 6 author: "Robert Boylan" tags: - vibe-coding - ai-coding-tools - planning - indie-dev --- It's 10:47pm. You've opened Cursor with a clear idea: a little app to track your weekend hiking plans. Ten minutes in, the AI has given you a beautifully styled landing page for a hiking app… that's now somehow also a booking platform for tour operators. You didn't ask for that. Prompt six brings it back to solo use. Prompt seven re-introduces the calendar view you had at prompt three but then lost at prompt four. By prompt eleven, you're rewriting the same description you started with, just more carefully this time. **This is what vibe coding without a plan looks like.** "Vibe coding" has become shorthand for building apps by describing them to an AI tool instead of writing most of the code by hand. It's real, it's useful, and it's a lot of fun when it works. This post is for anyone doing it who's hit the wall, and for anyone curious about whether it needs any planning at all. Spoiler: it does. Less than you might think, but a lot more than nothing. ## What vibe coding actually is (and what it isn't) A quick definition for the non-coders in the room. Vibe coding means you write an app mostly by describing it to tools like Cursor or Claude Code if you're a developer, or Lovable, v0, or Bolt.new if you'd rather not touch code. (The short version: an AI tool writes code from your description, and the better you describe, the better the code.) The AI writes most of the lines. You steer, correct, test, and keep going. It's not lazy. It's not "cheating," the same way using a calculator wasn't cheating in 1983. It's a different relationship to code: instead of writing it, you describe the thing you want to exist and direct the machine as it builds. People are shipping real products this way, with real revenue, in weeks instead of months. What it isn't: a mind-reading service. The AI only knows what you tell it, and it quietly forgets half of that by the fifth prompt. ## The wall most vibe-coders hit around prompt four Here's the pattern that plays out a thousand times every weekend. You describe the app. The AI builds something close, but not quite. You describe the fix. It makes the fix, but undoes a small thing you liked. You describe the fix for the fix. Now it's drifted on the styling. You ask it to restyle. The styling's back, but the feature you added at prompt two is gone. Around prompt four or five, you find yourself writing the same description you started with, because you realise the AI has been working from an incomplete version of your idea the whole time. You've been discovering what you actually wanted one correction at a time, in public. The fix isn't "better prompts." **You can't prompt your way out of not having decided what you're building.** The fix is deciding a handful of things before you type the first one. ## A mini-PRD beats a hundred prompts The resistance to this is real: "I'm vibe coding. I don't want to write a 40-page product spec. That's the whole point." Nobody's asking for 40 pages. What you need is a [mini-PRD: the same shape a product manager hands an engineer before code gets written, shrunk to the size of a weekend project](/what-is-a-prd). Same thinking, same sections. Just one page instead of thirty, and written in the time it takes to drink a coffee. It needs to cover: - one paragraph saying what the app is - a list of three to five features, ranked - a one-line note on who's using it and why - a quick list of what you're specifically _not_ building That's the whole shape. The point isn't the artifact on the page. It's the thinking that happens before you open the tool to build the product. And the hard part isn't the thinking itself. It's remembering what to think about, in the right order, when nobody's there to prompt you. Compare the prompts you'd write with and without it: **Without plan:** "Build me a hiking app." **With plan:** "Build me a web app for one person (me) to plan weekend hikes. Core features in order: (1) save a list of hikes I want to do, (2) add notes and photos to each, (3) mark one as 'next weekend' and show it on the dashboard. Not building: booking, social features, multi-user, or anything with a map API for now." The second prompt is maybe forty seconds longer to write. It saves the next two hours of drift. ## What goes in a mini-PRD for a weekend project Same five sections a real PRD has, just scoped down. Ranked roughly by return on time: 1. **One-sentence description.** What's the app? If you can't say it in a sentence, the AI can't build it in ten prompts. Example: "A personal weekend hike planner with notes and photos." 2. **Top three features, in priority order.** Not all features are equal. Order matters, because the first feature becomes the skeleton everything else hangs on. 3. **The user.** Even if the user is just you. "For me, on my phone" is a different app than "for me and my climbing partner, on desktop." 4. **What you're not building.** This is the one people skip and regret. Writing it down stops the AI from helpfully adding a "social sharing" feature you never wanted. 5. **Anything you feel strongly about.** Design mood ("minimal, warm, not corporate"), stack opinions ("no backend, local storage is fine"), constraints ("has to work offline"). Five sections. Not hours of work, but not thirty seconds either. Each one sounds obvious written down. Making them in the right order, for an idea you haven't built yet, without missing the one about what you're _not_ building, is exactly the kind of product-thinking work that's easy to put off. So people put it off. They open the AI tool, type the one-sentence version, and discover the rest at prompt four. ## Why planning makes vibe coding more fun, not less The word "planning" has bad associations: stiff meetings, bullet-point documents, "waterfall." Nothing in this post is that. A mini-PRD is not a plan in the enterprise sense. It's a shared reference you and the AI can both hold onto, sized for one person building one app in one weekend. Here's what actually changes when you do it: - You prompt _less_, not more. A clear plan means fewer re-prompts because the first one already contains the important constraints. - You stay in flow. The "oh no, it lost the calendar view" context-switching is what kills a weekend build. A plan cuts that in half. - You ship. This is the big one. The indie devs who finish things with AI tools aren't necessarily the best prompt engineers. They're the ones who picked a clear thing to build and didn't rewrite it mid-flight. This is actually why [Draftlytic exists: it's built around the idea that the before-you-prompt part matters more than the prompt itself](/about). You describe your idea, answer a few quick questions, and come out the other side with the sentence, the features, the "not this" list, and a spec you can paste straight into Cursor, Lovable, v0, or whichever tool you build in. ## The takeaway The reason most vibe coding sessions drift at prompt four isn't that the AI is bad at listening. It's that nobody gave the AI a real plan to listen to. The sentence, the three features, the "not building" list. That's the difference between a weekend of shipping and a weekend of re-prompting. That pre-prompt thinking is the part Draftlytic is built to handle. You describe the idea, answer a few quick questions, and come out with a spec that pastes cleanly into Cursor, Lovable, v0, or whichever tool you build in. All the magic of vibe coding. None of the prompt-four rewrite loop.