Decomposition

Why decomposition matters

A language model has a fixed amount of computation per token and no scratch space beyond the text it has already written. When you hand it a problem with several interacting parts — "audit this auth module for vulnerabilities, then propose fixes that don't break the existing session contract" — you are asking it to discover the structure of the problem and solve every part of it in a single forward pass. It will often skip a part, conflate two parts, or commit early to an approach and rationalize the rest.

Decomposition removes that pressure. You make the structure explicit yourself, or you ask the model to make it explicit first, and only then solve. This is the same reason Chain-of-Thought works, but applied at a higher altitude: instead of eliciting intermediate reasoning steps within one answer, you are carving the work into distinct sub-problems, each of which gets its own focused generation. Schulhoff's Prompt Report treats decomposition as one of the highest-leverage technique families precisely because it compounds with everything else — each sub-problem can have its own examples, its own format, its own verification.

How to do it

There are two dominant patterns, and they are worth keeping distinct.

Least-to-most prompting

Least-to-most has two phases. First you prompt the model to list the sub-problems in dependency order, simplest first. Then you solve them one at a time, feeding the answer to each earlier sub-problem into the prompt for the next. The key property is that later steps get to see the concrete results of earlier steps, not just the plan. This is what separates it from ordinary planning and is why it helps on compositional tasks where step N genuinely needs the output of step N-1.

Worked example. Suppose you need to compute the total cost of a multi-leg trip with currency conversions and a loyalty discount. A monolithic prompt tends to drop the discount or apply it before conversion. Least-to-most instead does:

1. Decompose: "List the sub-questions you must answer in order to compute the final cost, simplest first." The model returns: (a) cost of each leg in its local currency, (b) each leg converted to USD, (c) subtotal, (d) discount applied.
2. Solve sub-problem (a) in its own turn; capture the answer.
3. Solve (b) with (a)'s numbers pasted in; and so on.

Each step is small enough that errors are visible and correctable before they propagate.

Plan-then-execute

The lighter-weight cousin: ask for a plan, optionally review or edit it, then ask the model to execute the plan it just wrote. The plan acts as a commitment device — once written, the model tends to follow it rather than wandering. A reliable scaffold:

Before writing any code, produce a numbered plan:
- the files you will change and why
- the order of changes
- one risk per step and how you'll check it
Stop after the plan. Do not implement yet.

You then either run each step in its own message or let an agent execute the plan with verification between steps. The deliberate "stop after the plan" is what gives you a chance to catch a wrong approach for the price of one cheap generation instead of a full implementation you have to throw away.

How agentic tools operationalize this

Modern coding agents have turned decomposition into a product surface. Kiro's spec mode refuses to jump straight to code: it first generates a requirements document, then a design, then a task list, and only executes tasks once you've approved the upstream artifacts — least-to-most applied to software, with human review at each boundary. Traycer works similarly, producing a structured plan of file-level changes that you inspect and adjust before any edits land. The pattern is identical to what you can do by hand in a chat window; the tools just enforce the phase boundaries and persist the artifacts so later steps can reference earlier ones.

Pitfalls

• Decomposing problems that don't need it. For a single-step task, adding a planning phase just adds latency, cost, and a surface for the plan to be wrong. Decomposition earns its keep on compositional problems — those where parts depend on each other. The empirical prompt-engineering literature is consistent that more scaffolding is not free, so reach for this when the problem is genuinely multi-part.
• Letting the plan drift from execution. If you generate a plan and then execute in a long, separate context, the model may quietly deviate. Carry the plan forward in each step and ask it to flag any departure.
• Bad decomposition is worse than none. If the model carves the problem along the wrong seams, every downstream step inherits the mistake. Treat the decomposition itself as a reviewable artifact — read it before you spend tokens executing it.
• Over-trusting the dependency ordering. Models sometimes list steps in a plausible but incorrect order. For least-to-most, sanity-check that step N actually only needs the outputs of steps before it.
• Error accumulation. Sequential solving means a wrong early answer poisons everything after it. This is a feature when you verify each step (errors are localized and catchable) and a bug when you don't (they compound silently). Verify between steps.

The honest summary from the empirical work: decomposition reliably helps on multi-step, compositional tasks and is roughly neutral-to-harmful on simple ones. Decide which kind of problem you have before you reach for it.