🧩 Instruction Decomposition

Instruction decomposition is the technique of breaking a complex task into smaller, manageable sub-tasks before asking the AI to solve the whole thing. Instead of giving one massive prompt, you divide the work into clear steps — each simple enough for the AI to handle accurately. It's the "divide and conquer" approach applied to prompt engineering.

Think of it like building a house: you don't say "build me a house." You plan the foundation, then the framing, then the plumbing, electrical, and so on.

Why This Matters

Complex prompts fail for predictable reasons:

1. Context overload — When you ask the AI to do 10 things at once, it often drops some or does them poorly
2. Quality per sub-task increases — A focused prompt on one task produces better results than a scattered prompt on many
3. Errors are isolatable — If step 3 goes wrong, you fix step 3 without redoing everything
4. Reusability — Individual sub-task prompts can be reused across different projects
5. Parallel execution — Independent sub-tasks can be run simultaneously, saving time

Studies show that decomposed prompts consistently outperform monolithic prompts on complex tasks by 15-30% in quality metrics.

Two Types of Decomposition

Sequential Decomposition

Each step depends on the previous one. Output from Step 1 feeds into Step 2.

Step 1: Analyze the requirements → Output: requirement list
Step 2: Design the architecture (using requirement list) → Output: design doc
Step 3: Write the code (using design doc) → Output: code
Step 4: Write tests (using code) → Output: tests

Parallel Decomposition

Steps are independent and can run at the same time.

Task: Create a product landing page

Parallel sub-tasks:
├── Write the headline and hero copy
├── Write feature descriptions (3 features)
├── Write customer testimonial prompts
└── Write the FAQ section

Final step: Combine all outputs into a cohesive page

Prompt Example

I need to create a complete REST API design document for a task
management app. Let's break this into steps.

STEP 1 — Define the data models:
List all entities (User, Task, Project, etc.) with their fields,
types, and relationships.

[Wait for output, then continue to Step 2]

STEP 2 — Define the API endpoints:
Based on the data models above, list all REST endpoints with
HTTP method, path, request body, and response format.

STEP 3 — Define authentication and authorization:
What auth strategy should be used? Define which endpoints need
which permissions.

STEP 4 — Combine into a final API design document.

❌ Bad Example

Create a complete REST API design for a task management app including
data models, all endpoints, authentication, authorization, error
handling, pagination, rate limiting, and documentation.

Problem: This asks for 8+ things at once. The AI will produce a surface-level response for each, missing important details on all of them.

✅ Improved Example

I'm designing a REST API for a task management app.
Let's tackle this step by step. Start with Step 1 only.

STEP 1: Data Models
Define the following entities with fields, data types, and
relationships:
- User (include roles: admin, member)
- Project (belongs to users)
- Task (belongs to projects, assigned to users)
- Comment (belongs to tasks and users)

For each entity, include:
- Field name and type
- Required/optional
- Relationships (one-to-many, many-to-many)
- Any constraints or validations

Output as a clear table for each entity.
I'll ask for Step 2 after reviewing this.

Why it works: By focusing on one step at a time, the AI gives comprehensive, detailed output. You can review and correct before moving on, preventing errors from propagating.

🧪 Try It Yourself

Edit the prompt and click Run to see the AI response.

I need to write a blog post about machine learning. Let's decompose this into sub-tasks and start with the first one. Sub-task 1 (NOW): Write an engaging introduction (2 paragraphs) that explains what machine learning is in simple terms, using an everyday analogy. Sub-task 2 (NEXT): Explain the 3 main types of ML with one real-world example each. Sub-task 3 (LATER): Write a simple Python code example showing a basic ML model. Sub-task 4 (LATER): List 3 pros and 3 cons of ML adoption. Sub-task 5 (LATER): Write a conclusion with key takeaways. Please complete Sub-task 1 now.

Practice Challenge

Decompose this complex task into 4-5 clear sub-tasks:

Task: "Create a comprehensive competitor analysis report for a new coffee shop opening in downtown Seattle."

For each sub-task, write:

1. What it focuses on
2. What input it needs
3. What output it produces
4. Whether it depends on another sub-task (sequential) or can run independently (parallel)

Label each sub-task as Sequential or Parallel.

Real-World Scenario

Decomposing a Code Migration Task:

Instead of "Migrate our Express.js app to FastAPI," break it down:

Migration Plan — Express.js to FastAPI

Phase 1 (Analyze):
"List all Express.js routes in our app, including HTTP method,
path, middleware, request/response types. Format as a table."

Phase 2 (Map):
"For each Express route from Phase 1, show the equivalent FastAPI
code pattern. Map Express middleware to FastAPI dependencies."

Phase 3 (Models — Parallel):
"Convert these Express/Mongoose models to FastAPI/SQLAlchemy models:
[paste models from Phase 1]"

Phase 4 (Routes — Parallel):
"Convert these Express route handlers to FastAPI endpoints:
[paste routes from Phase 1, patterns from Phase 2]"

Phase 5 (Tests):
"Write pytest tests for each FastAPI endpoint from Phase 4.
Test the same scenarios the original Express tests covered."

Phase 6 (Combine):
"Review all converted files. Check for missing imports, inconsistent
naming, or broken references. Create a migration checklist."

Each phase produces a clear deliverable. Phases 3 and 4 can run in parallel because they're independent. Phase 5 needs Phase 4's output, so it must wait.

Interview Question

Q: When would you decompose a prompt into sub-tasks instead of using one large prompt?

A: I decompose whenever the task involves multiple distinct outputs, when a single prompt produces shallow or incomplete results, or when different parts of the task require different expertise levels. The rule of thumb: if the prompt has more than 2-3 distinct requirements, break it up. Sequential decomposition works when steps depend on each other — like requirement analysis before coding. Parallel decomposition works when parts are independent — like writing different sections of a document. The trade-off is more prompts and more manual orchestration, but the quality per sub-task is significantly higher. In production systems, this approach also improves debuggability since you can pinpoint exactly which step produced a bad result.

Summary

• Instruction decomposition = breaking complex tasks into focused sub-tasks
• Sequential: each step feeds into the next
• Parallel: independent steps that can run simultaneously
• Quality improves 15-30% compared to monolithic prompts
• Each sub-task should have a clear input, output, and scope
• Errors are isolatable — fix one step without redoing everything
• Mark sub-tasks as NOW, NEXT, LATER to control execution order
• Use for any task with 3+ distinct requirements