Two patterns, and one question that decides between them:
- Fixed sequential pipeline (prompt chaining) — appropriate when the aspects needing coverage are knowable in advance. Analyzing each file in a known set, then running one cross-file integration pass, is the standard shape.
- Dynamic adaptive decomposition — appropriate when the actual work depends on what gets discovered along the way. "Add comprehensive test coverage to an untested legacy billing module" can't be pipelined up front, because you don't yet know which areas are high-impact; the right approach maps the module's structure first, identifies high-impact areas, and builds a plan that adapts as dependencies surface.
The discriminator: is the subtask set knowable up front? Knowable → pipeline. Discovered as you go → adaptive. Getting this backwards produces two distinct failure modes: adaptive decomposition applied to genuinely predictable, enumerable work is over-engineering; a fixed pipeline applied to open-ended investigation produces exactly the shallow, uniform, gap-riddled output you'd expect from forcing a discover-as-you-go task into pre-planned stages (e.g., sixty shallow tests covering trivial getters while the actual payment-retry logic goes untested).
Left: the subtask set is already known, so it's staged once. Right: each step's findings reshape the next step, so the plan loops and adapts instead of being fixed up front.
Underneath both patterns is attention dilution: one prompt holding many files' worth of material produces shallower findings and sometimes outright contradictory conclusions across files, which is the practical reason per-file passes exist as a pattern at all, independent of which decomposition strategy is chosen.