What you’ll be able to do
- Choose prompt chaining for predictable multi-aspect reviews and dynamic decomposition for open-ended investigation
- Split a large code review into per-file local analysis passes plus a separate cross-file integration pass
- Decompose an open-ended task by mapping structure, identifying high-impact areas, and building a prioritized plan that adapts
What you need to know
Two decomposition patterns, two kinds of workflow
Complex work has to be broken into pieces. The question is whether you can know those pieces in advance.
- Fixed sequential pipeline (prompt chaining) — the steps are decided at design time and run in order, each a focused prompt whose output feeds the next. It fits predictable work where the aspects to cover are known: a code review that always checks correctness, then security, then style; an extraction that always classifies, then extracts, then validates.
- Dynamic adaptive decomposition — the agent generates subtasks as it goes, based on what each step discovers. It fits open-ended investigation where you can't list the steps until you've seen the terrain: "find out why checkout latency doubled," "add comprehensive tests to this legacy codebase."
Mismatches fail in both directions. A fixed chain applied to open-ended investigation either does steps the situation doesn't need or misses the ones it does, because the list was written before anything was learned. Adaptive decomposition applied to a predictable review adds variability where you want consistency: two runs over similar code check different things.
Prompt chaining for large code reviews
Review a twenty-file pull request in a single pass and attention gets spread thin: some files get careful analysis, others a skim, and subtle issues in the middle of the change are missed. This is attention dilution, and the fix is to chain focused passes:
- Per-file local passes — analyze each file on its own, with full attention on that file's logic, error handling, and local correctness.
- A separate cross-file integration pass — with the per-file findings in hand, look at how the files interact: a changed function signature in one file and its callers in three others, a new config key read in one place and never set in another, data-flow assumptions that span modules.
Both halves are required. Per-file passes alone are thorough locally but structurally blind — they can't see an interface mismatch that only exists between two files. The integration pass is where those issues surface.
Dynamic decomposition for open-ended tasks
"Add comprehensive tests to a legacy codebase" has no meaningful fixed step list. You don't yet know which modules matter, which are already tested, or what depends on what. An adaptive investigation plan works in stages:
- Map the structure first — modules, entry points, existing test coverage, dependency relationships.
- Identify high-impact areas — code that's heavily used, recently changed, business-critical, or currently untested.
- Create a prioritized plan — which areas to test first, and why.
- Adapt as you go — when writing tests for the billing module reveals it depends on an untested currency utility, that utility moves up the plan. Subtasks are generated from what each step discovers.
The value of the adaptive plan is that it responds to the codebase as it actually is, not as someone guessed it was before looking. Writing tests file-by-file in alphabetical order, or committing to a fixed list on day one, both ignore what the investigation reveals.
Choosing between them
Ask: could I write down every step before starting, and would those steps be the same next time? If yes — a multi-aspect review, a standard extraction — use prompt chaining for consistency and focused attention. If no — debugging, investigation, open-ended improvement work — use dynamic decomposition that maps first and adapts. Many real workflows combine them: an adaptive investigation may run a fixed chain as one of its steps.
Key concept
Predictable multi-aspect work gets a fixed prompt chain; open-ended investigation gets dynamic decomposition that maps the terrain, prioritizes, and adapts. For large reviews, chain per-file local passes with a separate cross-file integration pass to avoid attention dilution.
When a scenario says a large review is inconsistent — deep on some files, shallow on others — the fix is splitting into per-file passes plus an integration pass, not a bigger model or a longer prompt.
Practice scenario
Work it through, then open this
The uneven depth is attention dilution from a single pass over many files. Reviews are predictable multi-aspect work, so a fixed prompt chain fits better than open-ended investigation: run a focused pass per file, then a separate cross-file integration pass using the per-file findings to check interface changes against callers. The integration pass is what would have caught the renamed parameter breaking callers in other files.
Build exercise — Decompose one review and one investigation
Intermediate · 35 min
What you’ll learn
- Telling predictable work from open-ended work
- Building a per-file plus integration chain
- Writing an adaptive plan that changes on discovery
-
Take two tasks — reviewing a multi-file pull request, and “add tests to an untested module” — and for each, try to write the complete step list before starting.
- Why: Whether you can enumerate the steps up front is the signal for which pattern fits.
- You should see: A complete, reusable list for the review, and a list for the testing task that’s mostly guesses.
-
Implement the review as a chain: one prompt per file, then an integration prompt given all per-file findings. Seed the PR with one cross-file bug (a changed signature with an unchanged caller).
- Why: Per-file passes give each file full attention; the integration pass catches issues that only exist between files.
- You should see: Consistent per-file depth, and the seeded cross-file bug reported by the integration pass rather than the per-file passes.
-
For the testing task, have the agent map structure and coverage first, propose a prioritized plan, and record each plan change it makes as it discovers dependencies.
- Why: Open-ended tasks need subtasks generated from what’s found, not fixed in advance.
- You should see: At least one reprioritization driven by a discovered dependency.
Exam traps
Reviewing a large multi-file change in one pass and expecting consistent depth across every file
Attention dilutes across many files. Split into per-file local passes.
Splitting a review into per-file passes and dropping the cross-file integration pass
Per-file passes can’t see interface mismatches and data-flow issues that span files. The integration pass is required.
Fixing a complete subtask list up front for an open-ended investigation
Open-ended tasks need subtasks generated from what each step discovers.
Using open-ended adaptive decomposition for a review whose steps are known and repeatable
Predictable multi-aspect reviews benefit from a fixed prompt chain’s consistency.
Starting an open-ended task by producing output before mapping the codebase’s structure
Map structure and identify high-impact areas first, then build the plan.
Treating the initial plan as final instead of revising it as dependencies are discovered
The adaptive plan’s value is that it changes when the investigation reveals something new.
Sources
- Claude Developer Platform Docs
- Anthropic, Claude Certified Architect – Foundations Exam Guide v1.0 (July 2026)