A developer renames a database column from user_name to display_name in one message, then separately asks Claude to update the API serializer in a follow-up. After both changes, the application crashes — the ORM model still references user_name while the serializer expects display_name. The ORM model fell through the gap between two messages.
These were interacting changes submitted as independent ones. The column rename, ORM model update, and serializer change all connect through the same data structure. They should have been one message.
The Rule
Interacting issues — changes where fixing one affects another — go in a single message. Claude handles them atomically, seeing all sides of the change at once.
Independent issues — changes with no shared code, data structures, or interfaces — go in separate sequential messages. Each gets focused attention, and the developer reviews before moving on.
What Makes Issues Interact
Issues interact when they share:
- Functions or interfaces — Renaming a function requires updating all callers
- Data structures — Adding a field to a model affects every file that reads or writes the model
- Files — Two changes touching the same files may conflict or overlap
- Contracts — Changing an API response format affects both the handler and all consumers
A function rename across 8 files and a new field addition affecting 5 files interact if 3 of those files overlap. They should be submitted together.
A CSS fix in styles/button.css and an API validation fix in api/users.ts share nothing. They are independent.
The Data
A team compared two strategies for submitting 20 issues over a sprint:
| Strategy | Messages | Follow-up fixes needed |
|---|---|---|
| All-in-one (5 issues/message) | 4 | 35% of issues |
| Classified grouping | 12 | 8% of issues |
Classified grouping used more messages but reduced follow-up fixes by 77%. The total time including rework was lower despite the additional messages.
The improvement is not from having more messages. Randomly splitting 20 issues into 12 messages would not achieve 8%. The improvement comes specifically from keeping interacting issues together and independent issues apart.
The Classification Step
Before submitting anything to Claude, classify each issue:
- For each pair of issues, ask: does fixing one affect the other?
- Group issues that interact into single-message batches
- Handle independent issues as separate sequential messages
For a backlog of 15 issues with 4 auth module issues (interacting), 3 validation layer issues (interacting), and 8 unrelated issues (independent):
- Message 1: all 4 auth issues together
- Message 2: all 3 validation issues together
- Messages 3-10: each independent issue separately, with review between
Common Mistakes
Splitting interacting changes across messages. The DB column rename example. Also: changing a function signature in one message, updating callers in another. Claude’s second message focuses on its specific task without revisiting files from the first.
Batching everything in one message. Mixing 5 unrelated issues dilutes Claude’s focus. Independent issues get better treatment when Claude can concentrate on one at a time.
Ordering by severity or complexity instead of interaction. A critical independent fix and a minor interacting fix have different grouping needs. Severity determines priority order; interaction determines grouping. Both matter, independently.
Using markers within a single message. [ISSUE 1] and [ISSUE 2] labels in one message still require Claude to context-switch between unrelated problems. Separate messages provide true focus separation.
One-liner: Interacting issues go in one message for atomic consistency; independent issues go in separate messages for focused attention — classify before submitting, and follow-up fixes drop from 35% to 8%.