Task Decomposition

Context

Code has structure. But so does the work of building code. Task decomposition is the practice of breaking a larger goal into bounded units of work, each with clear acceptance criteria. It operates at the architectural scale, not because it’s about code structure, but because the way you decompose work shapes the structure of what gets built.

This pattern sits at the intersection of project planning and technical design. In traditional development, tasks map to tickets or stories. In agentic coding, tasks map to the instructions you give an AI agent, and the quality of the decomposition directly determines the quality of the agent’s output.

Problem

How do you turn a large, vague goal into a sequence of concrete, completable steps, especially when the person (or agent) doing the work can’t hold the entire goal in mind at once?

Forces

• Large tasks are overwhelming. Humans procrastinate on them, and agents produce unfocused output.
• Tasks that are too small create coordination overhead and lose the thread of the larger goal.
• The right decomposition depends on who’s doing the work. A senior engineer and a junior engineer (or an AI agent) need different granularity.
• Some tasks have hidden dependencies that only become visible after you start.

Solution

Break the goal into tasks that are:

• Bounded — each task has a clear start and end.
• Testable — you can verify whether it’s done.
• Independent (as much as possible) — completing one task doesn’t require another to be finished first.
• Right-sized ��� small enough to hold in one context window or one work session, large enough to be meaningful.

For agentic workflows, right-sizing is critical. Each task should fit within a single agent session: the agent should be able to read the relevant code, make the changes, and verify them without running out of context. If a task requires the agent to understand the entire codebase, it is too big. If it requires the agent to make a one-line change that only makes sense in the context of five other changes, it is too small.

A practical approach:

1. Start with the end state: what does “done” look like?
2. Identify the major parts (often mapping to components or modules).
3. For each part, define what needs to change.
4. Order the tasks by dependency — what must exist before other things can build on it?
5. Write acceptance criteria for each task: when is it done?

How It Plays Out

A team needs to add a new reporting feature. The lead decomposes it: (1) define the data model for report configurations, (2) build the query layer that generates report data, (3) create the API endpoint that serves reports, (4) build the UI component that displays them, (5) add tests for each layer. Each task is scoped to a single module, has clear inputs and outputs, and can be assigned independently.

A developer using an AI agent decomposes the same feature differently — optimized for agent sessions. Each task includes specific files to read, the interface to implement, and a test to verify the result. The first prompt: “Read models/report.py and add a ReportConfig dataclass with fields for name, query, and schedule. Add a test in tests/test_report.py that creates a ReportConfig and verifies its fields.” The task is small, concrete, and verifiable. The agent completes it in one pass.

Consequences

Good task decomposition makes work predictable, parallelizable, and measurable. It reduces the risk of wasted effort: if one task goes wrong, the others are unaffected. In agentic coding, it’s often the single biggest factor in success. A well-decomposed set of tasks produces better results than a more capable agent given a vague goal.

The cost is the effort of decomposition itself. It requires understanding the problem well enough to know where the seams are, which is itself a skill. Poor decomposition (tasks that are too coupled, too vague, or missing acceptance criteria) creates the illusion of progress without the reality. Over-decomposition wastes time on planning that could be spent building.

Related Patterns

• Applies to work what: Decomposition applies to code — same principle, different domain.
• Scoped by: Boundary, Module, Component — code structure informs task boundaries.
• Requires awareness of: Dependency — tasks have dependencies just as code does.
• Supports: Composition — well-decomposed tasks compose into completed features.