Task Decomposition
Breaking a big job into small ones — which reliably helps, and reliably multiplies your failure rate.
When not to use it
- When subtasks can't be verified. Errors propagate silently and everything downstream is confidently built on them.
- Past the point of checkability. More steps is not more rigour; it's more exponent.
- Dynamically, when you know the structure. Static decomposition beats model decomposition consistently.
- On tasks the model handles whole. You've added failure modes for nothing.
Reach for something else instead
- A single well-scoped prompt — if it fits in the model's competence, don't split it.
- Map-reduce over data — independent subtasks, no compounding. The safe form.
- A hard-coded pipeline — static decomposition with the model filling steps.
- Human decomposition — a person splits, the model executes. Currently better than the model splitting.
Sources & further reading
- Zhou et al. (2022), Least-to-Most Prompting Enables Complex Reasoning in Large Language Models — decomposition enabling easy-to-hard generalisation.
- Khot et al. (2022), Decomposed Prompting: A Modular Approach for Solving Complex Tasks — decomposition as composable modules.
- Wu et al. (2022), AI Chains: Transparent and Controllable Human-AI Interaction via Chaining Large Language Model Prompts — the human-factors case for chaining, and its costs.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Decomposing without verification, and getting the exponent for free.
- Assuming decomposition improves reliability. It improves each step and worsens the whole.
- Letting the model decompose when you know the structure. You plan better than it does.
- Confusing independent with sequential subtasks. Only the second compounds.