Group corrections by how fixes interact

Learning objective

Bundle interacting problems into one coherent correction request but fix independent issues sequentially.

Core idea

Group correction requests by their behavioral dependencies. If repairing one problem changes what another repair must do, give Claude Code both problems in one detailed message. If the problems are independent, fix them sequentially so each round has a clear scope and verification target.

The CCAR-F exam guide explicitly distinguishes interacting problems from independent problems. Anthropic’s Claude Code best practices provide the supporting feedback discipline: correct early, give specific context and constraints, and require evidence from checks. The grouping decision organizes that feedback around the requirements each repair needs.

The question is “Does fixing A change the requirements or assumptions of B?” File proximity alone does not answer it. Two defects in one file can be independent; a parser in one file and its serializer in another can share one behavior contract.

How it works

Identify what each fix changes

Suppose a migration parser misreads month/day order and returns a timestamp without its agreed offset. The parser repair must return the correct date with the fixed UTC−05 offset attached. The serializer still applies a manual five-hour shift intended for the parser’s zone-less output. Once the parser returns an offset-aware value, that shift applies the offset twice. The serializer repair therefore depends on the parser’s changed output contract.

A third problem is an inconsistent label in the migration’s summary log. For this scenario, that label does not affect parsing, conversion, or output records. It belongs to a separate correction round. The classification is based on actual behavior, not on the fact that all three findings came from the same review.

Build a small dependency table before composing the request:

This table makes the reasoning inspectable. If a log label actually controls downstream processing, it is not merely reporting text and the classification changes. Inspect the relevant path rather than assuming independence from a finding’s title.

Send one contract for interacting corrections

A coherent request lists each symptom, states the shared expected behavior, and explains the dependency. It does not merely paste two unrelated complaints together. Identify the affected files and approved source-format assumptions, then provide the specific failing case and complete expected result.

For this illustrative migration, the source string 03/04/2021 09:00 means March 4 at 09 under an explicitly agreed fixed UTC−05 offset. The required serialized result is 2021-03-04T14:00:00Z. The fixed offset is a scenario assumption; it is not a rule for any named geographical time zone.

The correction message states the source month/day convention, fixed offset, and parser output contract together. It asks Claude to attach the offset in parsing and remove the serializer’s manual shift, then verify the required UTC string. If the parser is repaired alone, the serializer shifts the offset-aware value again and produces 2021-03-04T19:00:00Z. A later request to apply a five-hour shift would be wrong for the repaired parser. Give Claude both constraints in one correction so it changes the interface and its consumer together.

A parser-only repair applies the offset twice; repairing the parser and serializer together converts to UTC once.

Retain any agreed null behavior and populated-record checks that the correction could affect. See 3.5.3 for constructing the individual reproduction packet and 3.5.2 for the verification loop. This Bite adds the reason to put both timestamp findings into that packet rather than teach those mechanisms again.

Make independent rounds small and verifiable

After the timestamp correction passes its agreed checks, send the log-label correction with its own required output and relevant file. Ask Claude to make that scoped change and show its verification result before proceeding to another independent issue.

Sequential rounds make attribution clearer. If a result fails after one independent correction, there is one stated behavior to inspect. A request containing many unrelated changes makes it harder to tell whether a failed check belongs to the intended repair or incidental expansion of the task.

Independence does not mean “no verification required.” It means the check and scope can stand on their own without withholding another constraint Claude needs to solve the problem. If the repair reveals a shared interface assumption, revise the grouping rather than force an artificial one-issue rule.

Correct promptly and preserve useful context

Anthropic recommends course correction as soon as Claude goes off track. In interactive Claude Code, Esc stops the action while preserving context so you can redirect. Use it when you notice an incorrect assumption during a correction rather than waiting for more work to accumulate around it.

Within an interacting group, keep the full shared contract available. Do not replace the request with “fix the other part” after a partial repair; name the remaining failure and restate the constraints that the repair must preserve. That avoids treating the previous partial result as an approved specification. If a partial repair goes wrong, use Esc + Esc or /rewind to open the rewind menu and restore the previous conversation and code state before retrying the coherent request. Code checkpoints cover Claude’s file-editing tools; they do not capture changes made through Bash or external processes.

Between unrelated tasks, Anthropic documents /clear for resetting context. It also recommends /clear and a more specific prompt if you have corrected the same issue more than twice in one session. Reintroduce the actual requirements and observed failures in that fresh prompt. Clearing the conversation is not itself a repair, and a clean session still needs the coherent correction request.

Key distinctions and trade-offs

Interacting versus numerous: A long list does not automatically need bundling. Bundle the findings whose repairs depend on the same behavioral assumptions, regardless of how many findings the review contains.

Sequential versus withholding context: Independent issues benefit from separate rounds. Separating the parser’s offset-aware output change from removal of the serializer’s manual shift leaves the consumer using the wrong input assumption. Both repairs need the changed contract.

One coherent request versus one large request: A coherent request defines a shared expected outcome and its acceptance evidence. A large request can still be incoherent if it mixes unrelated goals and leaves each expected result vague.

Bundling increases the amount of context in a single correction but reduces contradictory partial fixes. Sequential independent rounds cost more exchanges but make scope, evidence, and review easier to attribute. Choose based on the dependency, not on minimizing message count alone.

Architecture / decision scenario

A developer productivity team reviews a Claude Code migration implementation and finds the parser-contract defect, the serializer’s manual shift, and the independent summary-label defect. The developer confirms that the parser repair attaches UTC−05 to its output, which requires the serializer to stop applying its own five-hour shift. The log label is reporting text with no effect on migrated values.

The developer sends one timestamp request with both findings, the fixed-offset and month/day assumptions, the offset-aware parser contract, the source string, observed output, required UTC string, affected files, and the end-to-end check. Claude must change the parser and serializer together to produce 2021-03-04T14:00:00Z. A parser-only repair leaves the double shift and produces 2021-03-04T19:00:00Z.

Once the timestamp result and affected existing cases pass, the developer sends the log-label issue as a separate round. If Claude starts broad logging refactoring, the developer stops it with Esc and redirects to the approved label change. The final evidence remains attributable: one result proves the shared timestamp contract and another proves the independent reporting correction.

Common exam traps

• Bundling every finding because it came from one review.
• Splitting interacting fixes so each round lacks a necessary constraint.
• Assuming fixes interact merely because they edit the same file.
• Assuming fixes are independent because they edit different files.
• Providing several symptoms without stating their shared required outcome.
• Treating /clear or a smaller message as a substitute for failure evidence.

What to remember

Ask whether one repair changes what another must do. Bundle dependent fixes with their shared contract and end-to-end verification; handle independent fixes in separate verified rounds. Correct promptly and carry the approved constraints into every request that needs them.

Knowledge check

References

• Anthropic, Best practices for Claude Code
• Anthropic, Claude Certified Architect – Foundations Exam Guide