Skip to content
AI Coding GuildAI Coding Guild
Sign InGet Started Free

Breaking Big Ideas into Small Tasks — The Decomposition Pattern

Learn why small, focused prompts produce better code than trying to build everything at once.

12 min readai-tools, prompt-engineering, decomposition, workflow

Here's the most common mistake vibe coders make: trying to build everything in one prompt.

"Build me a project management app with user authentication, team collaboration, task boards with drag-and-drop, file attachments, real-time notifications, Stripe billing, and an admin dashboard."

The AI will try. It will produce something. And that something will be a tangled mess of half-working features, inconsistent patterns, and bugs that are nearly impossible to untangle.

The fix is simple but counterintuitive: ask for less, more often.

Why Big Prompts Fail

AI coding tools have three fundamental limitations that make big prompts unreliable:

Context Window Limits

Every AI has a maximum amount of text it can consider at once (its "context window"). When you ask for a massive feature set, the AI has to hold your entire prompt, the code it's generating, and its understanding of how the pieces fit together — all at the same time. When this exceeds the context window, the AI starts "forgetting" earlier parts of your request.

Compounding Errors

When the AI makes a decision about Feature A, that decision affects Features B, C, and D. If the decision was wrong, every downstream feature inherits the problem. In a big prompt, these errors compound. In small prompts, you catch and fix each error before it affects the next step.

Ambiguity Multiplication

Every vague part of your prompt is a decision the AI makes on its own. If one prompt has five vague points, the AI makes five independent decisions. The chance that all five align with what you wanted is much lower than the chance any single one does.

The Decomposition Pattern

Decomposition means breaking a big idea into small, sequential tasks. Each task builds on the last, and you verify the result before moving to the next step.

Instead of one giant prompt, you write a sequence of focused prompts:

Prompt 1: Create the project structure and basic layout
Prompt 2: Build the data model and database tables
Prompt 3: Add the task list with create and delete
Prompt 4: Add task editing and status changes
Prompt 5: Add drag-and-drop reordering
Prompt 6: Add user authentication
Prompt 7: Connect tasks to authenticated users
...and so on

Each prompt is small enough that the AI can handle it well. Each builds on working code from the previous step.

How to Decompose

There's a simple framework for breaking down any project:

Step 1: List the Features

Write down everything you want your application to do. Don't worry about order yet.

- User signup/login
- Create projects
- Add tasks to projects
- Assign tasks to team members
- Track task status (to-do, in progress, done)
- File attachments on tasks
- Due dates and reminders
- Dashboard with project overview

Step 2: Identify Dependencies

Some features depend on others. You can't assign tasks to team members without user accounts. You can't add tasks to projects without projects existing. Draw the dependency chain.

Base: Project structure, layout, and navigation
  → Create projects
    → Add tasks to projects
      → Task status tracking
      → Due dates
      → File attachments
      → Assign to team members (requires users)
  → User signup/login
    → Dashboard

Step 3: Order by Foundation First

Start with the features that other features depend on. Build the foundation before the details.

1. Project structure, layout, navigation (skeleton)
2. Database schema and data layer
3. User authentication
4. Create/read projects
5. Create/read tasks within projects
6. Task status tracking
7. Due dates
8. Dashboard overview
9. Task assignment
10. File attachments
11. Reminders/notifications

Step 4: Write One Prompt per Step

Each item becomes a focused prompt. The prompt references the existing code (which the AI already knows about) and adds one clear piece of functionality.

A Full Example: Building a Recipe App

Let's walk through decomposition for a recipe sharing application.

The Big Idea

"A website where people can share recipes, search by ingredients, save favorites, and leave ratings."

The Decomposition

Prompt 1 — Foundation:

Create a Next.js project with TypeScript and Tailwind CSS. Set up the basic
layout with a navigation bar (Home, Browse Recipes, My Recipes, Sign In)
and a footer. The home page should have a hero section with a search bar
and a "Featured Recipes" section (use placeholder data for now).

Build. Review. Fix any issues. Move on.

Prompt 2 — Data Model:

Define the TypeScript types and Supabase table schema for this recipe app.
We need:
- recipes: id, title, description, ingredients (text[]), instructions (text[]),
  cook_time_minutes, difficulty (easy/medium/hard), image_url, author_id, created_at
- users: id, name, avatar_url (synced from auth)
- favorites: user_id, recipe_id
- ratings: user_id, recipe_id, score (1-5), comment
 
Create the SQL migration file and the TypeScript types.

Build. Review. Fix any issues. Move on.

Prompt 3 — Recipe Display:

Create the Browse Recipes page. It should:
- Fetch recipes from Supabase
- Display them as cards in a responsive grid (3 columns desktop, 2 tablet, 1 mobile)
- Each card shows: image, title, difficulty badge, cook time, and average rating
- Clicking a card goes to /recipes/[id]
 
Also create the recipe detail page at /recipes/[id] that shows the full recipe
with ingredients list, step-by-step instructions, and ratings.
 
Use seed data — create 6 sample recipes so we can see the pages working.

Build. Review. Fix any issues. Move on.

Prompt 4 — Search:

Add search functionality to the Browse Recipes page.
- Search bar at the top that filters by recipe title and description
- Ingredient filter: text input that matches against the ingredients array
- Difficulty filter: checkboxes for easy, medium, hard
- Cook time filter: "Under 30 min," "30-60 min," "Over 60 min"
- Filters combine with AND logic
- Client-side filtering (all recipes are already loaded)

Build. Review. Fix any issues. Move on.

Prompt 5 — Authentication:

Add Clerk authentication to the app.
- Sign in and sign up pages at /sign-in and /sign-up
- Protect these routes: /my-recipes, /recipes/new
- Show the user's avatar and name in the navigation (replace "Sign In" link)
- Create a webhook handler that syncs Clerk users to the Supabase users table

And so on. Each prompt is focused, testable, and builds on a solid foundation.

The 20-Minute Rule

Here's a practical heuristic: if you think a prompt will take the AI more than 20 minutes to implement from scratch, it's probably too big. Break it down.

This isn't a hard rule, but it's a useful gut check. Complex prompts lead to complex bugs. Simple prompts lead to simple fixes.

Decomposition for Different Project Types

For a SaaS Application

1. Project setup and layout
2. Database schema
3. Authentication
4. Core CRUD operations
5. Business logic (the thing that makes your app unique)
6. Payments/billing
7. Dashboard/analytics
8. Email notifications
9. Polish and edge cases

For a Portfolio or Marketing Site

1. Layout and navigation
2. Hero section
3. Features/services section
4. About/team section
5. Contact form
6. Blog or case studies
7. Responsive adjustments
8. Animations and polish

For an Internal Tool

1. Layout and auth
2. Data model
3. Data import/entry
4. Main data view (table or list)
5. Filtering and search
6. Export/reporting
7. User roles and permissions

AI Prompt: Planning Your Decomposition

Before you start building, you can use AI to help plan the decomposition itself:

I want to build [describe your app]. Help me break this down into
a sequence of focused implementation steps. Each step should:
- Build on the previous step
- Be small enough to implement in one prompt
- Produce something I can test
- Start with foundations and add complexity gradually
 
List the steps in order, with a one-sentence description of what
each step produces.

This gives you a roadmap before you write your first line of code.

Try this now

Pick one feature you have been postponing because it feels too big. Break it into five steps where each step ends with something you can run, click, or test before moving on.

Prompt to give your agent

Use this before you start building a multi-part feature: "I want to build [feature or app idea]. Break it into 8-12 implementation steps.

Requirements for each step:

  • It must build on the previous step
  • It must produce something testable
  • It must avoid mixing auth, billing, schema, and UI redesign into one step
  • It must name the files or systems likely to change
  • It must include a short verification check before the next step

Start with foundations first. Tell me which steps need my approval before an agent should continue."

What you must review yourself

  • That each step is genuinely small enough to review in one pass
  • That foundation steps come before feature polish
  • That risky work like migrations, permissions, and billing is isolated instead of bundled
  • That the verification check after each step is something you can actually perform

Common mistakes to avoid

  • Breaking work into slices that are still too large. "Build auth and onboarding" is still a bundle.
  • Going so small that progress stalls. Each step should end in a meaningful checkpoint, not a cosmetic change.
  • Skipping validation between steps. The advantage disappears if you queue five prompts and inspect none of them.
  • Letting the sequence drift. If the plan changes halfway through, regenerate the roadmap instead of stacking ad hoc requests on top.

Key takeaways

  • Decomposition keeps the agent focused and the review loop manageable
  • Good sequencing starts with foundations, not the flashiest feature
  • Each step should produce a working checkpoint you can verify
  • Small prompts are not just easier for the model; they are safer for you

What's Next

Next up: Few-Shot Prompting — Teaching AI by Showing Examples. Once you can break work into clean steps, the next leverage point is showing the agent exactly what a good step looks like in your codebase.