Going from an idea to a working application using AI code generation — the spec-first approach, tool selection, and iteration strategy.

## Key Points

- Feature 1: [one sentence]
- Feature 2: [one sentence]
- Feature 3: [one sentence]
- Frontend: [framework]
- Backend: [framework or "none"]
- Database: [type or "none"]
- Auth: [approach or "none"]
- [Thing you are tempted to build but should not yet]
- [Another thing]
- Forces you to decide what you are building before the AI starts generating
- Prevents scope creep ("while we're at it, let's add...")
- Gives the AI clear constraints (tech stack, features)

## Quick Example

```
Add a task list page at /tasks that:
- Fetches all tasks from the database
- Displays them in a table with columns: title, status, priority, created date
- Add a status filter dropdown above the table
- Use server components for the data fetch
```

```
Add error handling to the task list page:
- Show a friendly error message if the database query fails
- Add a loading skeleton while data is being fetched
- Handle the empty state (no tasks) with a message and a "Create your first task" button
```

Prompt to App

Going from an idea to a working application using AI code generation — the spec-first approach, tool selection, and iteration strategy.

---

The Spec-First Approach

The single most important practice in vibe coding: write a spec before you write a prompt.

A spec is not a 20-page requirements document. It is a concise description of what you are building, written for the AI (and for yourself). Without it, you will wander, the AI will guess, and your project will drift.

What a Good Spec Contains

# App: [Name]

## What it does
[2-3 sentences. What does the user do? What problem does it solve?]

## Core features (MVP)
- Feature 1: [one sentence]
- Feature 2: [one sentence]
- Feature 3: [one sentence]

## Tech stack
- Frontend: [framework]
- Backend: [framework or "none"]
- Database: [type or "none"]
- Auth: [approach or "none"]

## Out of scope (for now)
- [Thing you are tempted to build but should not yet]
- [Another thing]

Why Spec-First Works

• Forces you to decide what you are building before the AI starts generating
• Prevents scope creep ("while we're at it, let's add...")
• Gives the AI clear constraints (tech stack, features)
• Creates a reference document you can point back to when the project drifts
• Makes it easy to split work into sequential prompts

Spec Anti-Patterns

Too vague: "Build me a social media app." The AI will make 100 decisions you did not intend.

Too detailed: A 5-page spec with pixel-level UI descriptions. You will spend more time writing the spec than building the app. Save detail for the prompts.

No constraints: Forgetting to specify tech stack, auth approach, or database. The AI will choose for you, and its choices may not be what you want.

Including "nice to haves" in MVP: Every feature you add multiplies complexity. Be ruthless about what makes the cut.

---

Choosing the Right Tool

Different AI coding tools excel at different things. Choosing wrong wastes hours.

Claude Code (CLI)

Best for: Backend services, CLI tools, complex logic, full-stack apps where you want full control, working in existing codebases.

Strengths: Understands project structure deeply, can read and modify many files, works with any language or framework, excellent at refactoring.

Weaknesses: No visual preview, requires terminal comfort, steeper learning curve.

Use when: You are a developer who wants AI assistance without leaving your workflow. You have an existing codebase. You need complex multi-file changes.

Cursor

Best for: Full-stack development with visual feedback, working in existing codebases, developers who want IDE integration.

Strengths: Inline editing, codebase-aware completions, chat + edit in one interface, supports .cursorrules for project context.

Weaknesses: Subscription cost, can be slow on large codebases, learning curve for effective .cursorrules configuration.

Use when: You want AI-assisted development inside an IDE. You are working on a medium-to-large project. You want granular control over what gets changed.

Bolt / Lovable

Best for: Frontend-heavy apps, rapid prototyping, non-developers building apps, visual-first development.

Strengths: Instant preview, deploy in one click, good for standard web app patterns, low barrier to entry.

Weaknesses: Limited backend capabilities, hard to customize deeply, vendor lock-in risk, struggles with complex state management.

Use when: You want a working app in under an hour. You are building a standard web app. You prioritize speed over control.

v0 (Vercel)

Best for: UI components, landing pages, React/Next.js interfaces, design-to-code.

Strengths: Beautiful default styling, shadcn/ui integration, one-click deploy to Vercel, excellent for component-level work.

Weaknesses: Narrow tech stack (React/Next.js focused), limited backend, not ideal for full applications.

Use when: You need a polished UI component or page. You are in the Next.js ecosystem. You want design-quality output quickly.

Replit Agent

Best for: Quick prototypes, learning projects, apps that need hosting, collaborative development.

Strengths: Integrated hosting, database, and deployment. End-to-end environment. Good for beginners.

Weaknesses: Limited to Replit's environment, performance constraints, less control over infrastructure.

Use when: You want everything in one place. You are building a prototype you want to share immediately. You do not want to manage infrastructure.

Decision Heuristic

Ask yourself:

1. Do I need a backend? (If no: v0 or Bolt. If yes: continue.)
2. Do I have an existing codebase? (If yes: Claude Code or Cursor. If no: continue.)
3. Do I want full control? (If yes: Claude Code. If no: continue.)
4. Do I want instant preview and deploy? (If yes: Bolt or Lovable. If no: Cursor.)

---

The Build Sequence

Once you have a spec and a tool, follow this sequence:

Phase 1: Scaffold (1-3 prompts)

Generate the project structure, install dependencies, set up the basic layout.

Example prompt:

Create a new Next.js 14 app with TypeScript, Tailwind CSS, and shadcn/ui.
Set up the folder structure with:
- /app for pages
- /components for shared components
- /lib for utilities and database
Use SQLite with Drizzle ORM for the database.
Do not add any features yet, just the scaffold.

Key principle: Get a running app before adding features. Verify the scaffold works (starts without errors, shows a page) before moving on.

Phase 2: Data Model (1-2 prompts)

Define your database schema and basic data access.

Add a database schema for a task management app:
- tasks table: id, title, description, status (todo/in-progress/done),
  priority (low/medium/high), created_at, updated_at
- Create the Drizzle schema in /lib/db/schema.ts
- Add a db connection helper in /lib/db/index.ts
- Run the migration

Phase 3: Core Feature Loop (1 prompt per feature)

Build each feature from your spec, one at a time.

Add a task list page at /tasks that:
- Fetches all tasks from the database
- Displays them in a table with columns: title, status, priority, created date
- Add a status filter dropdown above the table
- Use server components for the data fetch

Do not combine features. "Add the task list and the task creation form and the edit page" will produce worse results than three separate prompts.

Phase 4: Polish (multiple small prompts)

Fix styling, add loading states, handle errors, improve UX.

Add error handling to the task list page:
- Show a friendly error message if the database query fails
- Add a loading skeleton while data is being fetched
- Handle the empty state (no tasks) with a message and a "Create your first task" button

---

Iterating Without Losing Coherence

The biggest risk in prompt-to-app development is coherence loss: after 20 prompts, the codebase feels like it was written by 20 different people (because effectively it was).

Maintain Coherence With

A project instruction file: Update it as you establish patterns. "All API routes return { data, error } format. All components use the cn() utility for class merging."

Consistent prompt structure: Use the same format for similar requests. If you always say "Add a [feature] page at [route] that [does X]," the AI will generate consistent output.

Periodic consolidation: Every 5-10 features, pause and prompt: "Review the codebase for inconsistent patterns. List any files that handle errors differently, use different naming conventions, or duplicate logic."

Explicit references: "Follow the same pattern as the task list page" is better than re-describing the pattern.

Common Coherence Failures

• Two different API response formats in the same app
• Some pages use server components, others use client components for no reason
• Multiple utility functions that do the same thing in different files
• Inconsistent naming (camelCase in some files, snake_case in others)
• Different error handling approaches across routes

---

Managing Scope Creep

Scope creep is the primary way vibe coding projects fail. It is easy to add features when each one is "just one prompt."

The Rule of Three

Your MVP should have at most 3 core features. If you have more than 3, you are building too much.

The "Later" List

Keep a list of features you want but will not build yet. When you think "it would be nice if..." add it to the list and keep going.

Scope Creep Warning Signs

• Your "quick prototype" is on its 40th prompt
• You are adding features no one asked for
• The app does 5 things adequately instead of 1 thing well
• You keep saying "just one more thing"
• You have spent more time on edge cases than core features

How to Say No (to Yourself)

Before each prompt, ask: "Is this in my spec?" If not, add it to the Later list. Revisit the Later list only after the MVP is complete and tested.

---

Debugging the Build Process

When things go wrong during prompt-to-app development:

The app will not start after a generation:

• Check the terminal output for the actual error
• Give the AI the exact error message: "I get this error when running npm run dev: [error]"
• Do not add context or interpretation, just the error

The AI changed something you did not ask it to:

• Use git diff to see exactly what changed
• Revert unexpected changes: git checkout -- path/to/file
• Re-prompt with more specificity: "Only modify [file]. Do not change any other files."

Generated code does not match your tech stack:

• The AI may use React patterns in a Vue project or Express patterns in a Fastify project
• Explicitly remind it: "This project uses Vue 3 with Composition API. Do not use Options API."

Features conflict with each other:

• Usually caused by building too much at once
• Revert to the last working commit
• Add features one at a time, testing between each

---

Launch Checklist

Before showing your vibe-coded app to anyone:

1. Test every feature manually. Click every button, fill every form, try every flow.
2. Check mobile responsiveness. AI often generates desktop-only layouts.
3. Try to break it. Empty inputs, special characters, rapid clicking, back button.
4. Check the console. Look for JavaScript errors, failed network requests, warnings.
5. Review environment variables. Make sure no secrets are hardcoded.
6. Test with real-ish data. Not just 3 items — try 100. Not just "test" — try actual content.
7. Check loading states. Slow network, large datasets, initial load.
8. Verify auth flows. Login, logout, session expiry, unauthorized access.

---

Anti-Patterns Summary

Anti-Pattern	Consequence	Fix
No spec	Project drifts, features conflict	Write a spec first, even a short one
Wrong tool choice	Fighting the tool instead of building	Match tool to project type
Multi-feature prompts	Partial implementations, conflicts	One feature per prompt
No testing between prompts	Bug compounding	Test after every generation
Unlimited scope	Never ships, mediocre at everything	MVP with 3 core features max
No project instruction file	Inconsistent code patterns	Create and maintain one from prompt 1
Ignoring git	Cannot undo bad generations	Commit after every working change