How to Write Prompts When You’re Vibe Coding
Source: Dev.to
Why prompts matter
A few years ago, coding felt like a solo sport: you, the keyboard, and Stack Overflow when things went sideways.
Now there’s an assistant in the editor, a chat tab, and sometimes a whole builder that spits out UI before you’ve finished your coffee.
The model can code, but most of the pain now comes from communication, not syntax. The job has shifted toward directing: you say what you want, something gets drafted, you react, and you iterate.
In “vibe coding,” the boring, unsexy hero is the prompt—a clear ask written like you mean it.
Guidelines for effective prompts
Be specific
Name what you’re building in plain pieces: features, rough layout, vibe of the UI, and what “done” looks like.
“Three KPIs on top, one line chart for the last 30 days, table below with sortable columns, calm spacing like Notion, no neon gradients.”
Give it structure
Split the prompt into chunks with headers or bullets so neither of us has to hunt. A typical structure:
- Goal
- Must‑haves
- Nice‑to‑haves
- Hard limits (tech, performance, “do not do”)
- Definition of done
It reads like a tiny ticket.
Point at examples
If you have a screenshot, a product you like, or even a single phrase—e.g., “dense like Linear,” “quiet like Stripe’s docs”—include it. You’re not asking for a clone; you’re giving a target so the model stops free‑styling typography and spacing you’ll hate.
Work in steps
Don’t ask for the whole castle in one message.
- Skeleton and main user path.
- CRUD or filters.
- Polish.
Big all‑in‑one prompts feel productive for sixty seconds and expensive for the rest of the afternoon.
Refine like you mean it
Treat the first output as a draft. Review it like a code review: note what’s wrong, missing, or structurally off. If the same mistake appears twice, fix the prompt—not just the line—because the spec was probably thin.
Bad vs. Better examples
Landing page
Bad
Make a nice landing page for my SaaS.
Better
Single-page site for a B2B analytics tool, audience = small ecommerce teams.
Sections:
- Hero with headline, subhead, primary CTA, screenshot placeholder
- Logo strip
- Three feature blocks
- One quote for social proof
- Pricing with two tiers
- FAQ accordion
- Simple footer
Look: lots of whitespace, neutral background, one accent color, Inter font, thin borders—no glassmorphism.
Must be responsive. Proper heading order, visible focus states on buttons.
Use placeholder copy; don’t invent fake customer names.
I’m happy when mobile scroll has zero horizontal junk.Dashboard
Bad
Create a dashboard with charts.
Better
Admin shell:
- Sidebar (Dashboard / Users / Settings)
- Top bar with search + user menu
Dashboard body:
- Four KPI cards: Revenue, Orders, Conversion, Refunds
- 30‑day line chart
- Bar chart for top products
- Sortable orders table (id, customer, total, status, date)
Data from mocked JSON in a `data/` folder.
Show loading skeletons; empty state when the table has no rows.
No paid chart APIs.
Small components, semantic HTML.
This step is only layout + fake data + route placeholders—no real auth yet.User profile
Bad
Add user profiles.
Better
Profile screen from the user menu.
Fields:
- Name (required)
- Avatar URL (optional)
- Bio (max 240 chars)
- Timezone dropdown
Inline validation; Save disabled until valid; toast on success.
Optimistic updates optional—don’t block on that.
Out of scope: password, email, billing.
Match spacing and components the app already uses; if there’s no form primitive, add a single `ProfileForm` instead of copy‑pasting markup everywhere.Prompt template I use when I’m blanking
Goal:
Who it’s for:
Main happy‑path (a short paragraph):
Must ship:
Nice if there’s time:
Visual refs (apps, screenshots, adjectives):
Tech / limits / “do not”:
Empty & error behavior:
Definition of done:Blank lines mean “model will improvise here” on purpose. I only leave them blank when I’m fine with that.
Spend the extra minute crafting a clear prompt. Your future self—who isn’t diff‑hunting at midnight—will thank you.