What is least-to-most prompting, and how does it differ from a fixed pipeline?

## The technique Least-to-most prompting attacks problems that are hard mainly because they are compositional: the final answer depends on several intermediate results that must be established in the right order. It runs in two phases. **Phase one, decomposition.** The model is prompted to restate the problem as an ordered list of simpler subproblems, easiest and most foundational first. Nothing is solved yet; the output is a plan. **Phase two, sequential solving.** Each subproblem is solved in turn, and each solved subproblem, with its answer, is carried into the context for the next. By the time the model reaches the final subproblem, the facts it needs have already been established in front of it rather than having to be derived in one leap. The name captures the ordering principle: start with the least complex piece and work up to the most complex, which is usually the original question restated. ## Why the ordering matters The reason this helps is not that the model gets more tokens to think with. It is that each solving step faces a problem strictly simpler than the original, with its prerequisites already resolved to concrete values. Consider a multi-clause tax question: gross income from two sources, one allowance that phases out above a threshold, and a band structure applied to what remains. Answered in one leap, the model frequently applies the allowance to the wrong base or bands the pre-allowance figure. Decomposed, the first subproblem yields a total, the second yields the allowance given that total, the third bands the residual. Each step is arithmetic a weaker model can do, and the dependency order stops the classic error of using a value before it exists. ## Against a fixed engineered pipeline A fixed pipeline hard-codes the same idea. You decided in advance that the stages are total, then allowance, then banding, and you wrote a prompt for each. The difference is authorship of the plan, and it drives every practical tradeoff. **Predictability.** A fixed pipeline has a known number of calls, so cost and latency are budgetable and a p95 is meaningful. Least-to-most may emit three subproblems for one input and eleven for another; the tail is unbounded unless you cap it. **Testability.** Fixed stages can each have a golden set and a validator, and a regression can be attributed to a stage. With a model-generated plan, the unit under test is the plan itself, which is harder to score than a field extraction. **Generality.** The fixed pipeline is brittle exactly where the input shape varies. If some questions involve a credit rather than an allowance, the fixed pipeline either has a stage that does nothing or needs a branch. Least-to-most handles heterogeneous inputs without you enumerating the cases, which is its real selling point. **Failure mode.** In a fixed pipeline, failure usually looks like a stage doing its job badly. In least-to-most, the dangerous failure is a confidently wrong plan: a missing subproblem, an inverted dependency, or a decomposition that quietly changes the question. Every downstream step then executes faithfully and the output is wrong in a way that looks reasoned. ## Making it survivable in production Treat the plan as an artifact, not as invisible scaffolding. Log it, and where a real pipeline exists, validate it: check that the number of subproblems is within a sane range, that required subproblems appear for known input classes, and that no step references a value not produced by an earlier step. A cheap deterministic check on the plan is worth more than extra prompting on the solving steps, because the plan is the single point of leverage. Sampling the decomposition more than once and comparing plans is a reasonable smoke test during development: if three samples produce structurally different plans for the same input, the problem statement is ambiguous or the task is at the edge of the model's competence, and no amount of downstream care will fix that. A pragmatic middle position is common in real systems. You fix the stages you understand and are willing to test, and you let the model decompose only inside the one stage that faces genuinely open-ended input. That keeps the budget and the evals of a pipeline while buying adaptivity exactly where it is needed. ## When it is not the answer When the model already solves the problem reliably in a single call, decomposition adds calls and latency for nothing, and modern models handle many compositional tasks that used to require it. When the task is not compositional at all, such as summarising, decomposition has nothing to order and tends to fragment the output. And when the problem needs several candidate decompositions to be explored and compared rather than one committed to, that is a different family of methods entirely; least-to-most commits to its first plan and executes it.