[Feature Request] Default to per-project vertical execution instead of cross-project horizontal batch execution for multi-module tasks

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 9, 2026

Bug Description
--- Subject: Claude Code defaults to "horizontal" batch execution across multi-project tasks, where per-project ("vertical") completion is almost always the right approach Summary When a task spans several projects or modules that need the same kind of change, Claude Code's strong default is to write a script/loop and apply each step across all of them at once. In my experience this is the wrong default for source code, and I'd like to see the model prefer finishing one project end-to-end before starting the next. Terminology Say four sub-projects A, B, C, D each need the same change, and that change has four steps 1–4. - Vertical (what I want): A1 → A2 → A3 → A4, then B1 → B2 → B3 → B4, then C, then D. - Horizontal (what Claude Code does): A1 → B1 → C1 → D1, then A2 → B2 → C2 → D2, … Observed behavior Concretely, when I asked Claude Code to upgrade a shared library across its downstream consumers and make them adopt the new version's features, it immediately: 1. Wrote a shell script with a loop to bump the dependency in every repo, 2. Ran that script in the background for several minutes, 3. Then ran a second sweep to check compilation everywhere, 4. Then produced a summary table of "which repos need which change," 5. Then proposed applying one repo's fix pattern to the rest. I had to interrupt and ask it to work one repo at a time. Once it did, the picture changed completely — see below. Why this is a problem 1. The script itself is pure overhead. Vertical execution needs no script at all: run one command in project A, then edit project A. Horizontal execution requires authoring a loop, debugging it, waiting for it, and often re-running it. The automation "saves" work that vertical execution never creates. 2. Batch sweeps produce confidently wrong results. In the case above, the model's scripted audit produced three incorrect verdicts about which repos were "missing" something. When it finally opened one repo and read the code, it found that each supposed defect was in fact a documented, deliberate choice — with a comment in the source explaining why. Of the repos it had flagged, only one genuinely needed a change, and the reason was only discoverable by reading a neighbouring test file. No script would ever have surfaced that. 3. It destroys the learning gradient. Finishing A teaches you where the pitfalls are, so B goes smoother and C smoother still. Horizontal execution walks every project into every pitfall simultaneously, then requires cleanup everywhere. 4. Rollback cost is multiplied. If a batch-applied change turns out to be wrong, every project must be reverted — often on top of unrelated uncommitted work. Vertical execution fails cheaply in one place. 5. It removes the natural abort point. If upgrading project A reveals the new dependency version is incompatible, the correct outcome is "stop and report — this doesn't fit us." Horizontal execution has already mutated all four projects before that fact is known. 6. It optimizes for the floor, not the ceiling. Batch-and-then-compile treats "nothing errors out" as success. That's the lowest possible bar. A good engineer changing a feature also reads the surrounding context and smooths out whatever is awkward there. Mechanical substitution across N repos structurally cannot do that. 7. Automation is self-reinforcing. Roughly 80% of real code work requires reading and judgment; maybe 20% is genuinely mechanical. Once the model commits to the automated path, it keeps reaching for automation on the 80% too. Choosing horizontal at the start is effectively choosing the wrong mode for the whole task. 8. It doesn't match how humans work. A developer opens one project, finishes it, closes it, opens the next. Nobody runs a command in window 1, copy-pastes it to windows 2–4, then goes back to window 1 to start editing. The horizontal pattern loses context on every switch. 9. It wrecks interaction pacing. A long background sweep blocks the conversation: I can't ask anything useful while it runs, and then a large batch of review work lands all at once. Vertical execution interleaves naturally with dialogue — small step, quick check, next step — which is both a better use of my attention and a smoother load profile on your service. What I'd like instead - Default to vertical for code tasks. Complete one project/module/file end-to-end, report it, then move to the next. - Treat "write a script to do this across N repos" as requiring justification, not as the obvious first move — especially when N is small (under ~10) and the items are source code rather than uniform data. - Reserve batch/scripted execution for genuinely tabular, independent, homogeneous items — filling cells in a spreadsheet, renaming assets, processing records. Code is not that: items look similar but differ in the details that…
Note: Content was truncated.

View original on GitHub ↗