Anthropic CCA-F: Refining Claude Code Changes Safely

Claude Code patches an invoice formatter and makes one failing test pass, but the change alters rounding for negative credits. A second patch corrects that case and quietly changes the shared API response shape. More attempts will not fix a workflow that lacks a stable definition of success. The iterative-refinement problem in Anthropic CCA-F is to turn the business requirement into explicit input/output examples, test interacting regressions together and reject unrelated changes. When the acceptance rule is missing, the productive next step is an engineer’s answer to a precise question, not another speculative patch.

Start with a test that describes the business result

The best first question is not “Which file should Claude change?” but “What outcome would prove the change correct?” For a currency formatter, the objective might be to preserve exact amounts, display the correct currency symbol, and use a defined rounding rule for both positive and negative values. A unit test can make those outcomes visible before any code is edited. It can also expose a shared helper consumed by another service, turning an apparently isolated formatting change into a compatibility concern. When the request has no measurable acceptance condition, the assistant can produce a polished patch without a defensible completion criterion.,A useful initial test set should distinguish ordinary input from boundaries and failure cases.

Three examples are often more instructive than a long paragraph: a normal USD amount, a negative amount at the rounding boundary, and a missing currency code that must be rejected or explicitly marked unresolved. These examples constrain the transformation while leaving room for the engineer to choose an implementation. They also provide an immediate regression baseline: the old behavior is recorded, the proposed new behavior is stated, and the team can run the same checks after every revision. The model’s final summary is secondary to the observed results.,For example, consider these illustrative requirements for a service that returns a normalized money object rather than a locale-formatted string. The numbers and rejected outcomes below are a deliberately chosen business contract, not a description of an Anthropic API.

Make input/output examples carry real distinctions

Examples should show which decision boundary matters. If every demonstration uses a simple positive amount, Claude may produce code that passes those examples while failing on a negative balance, a value with too many decimal places or an absent field. A contrasting example teaches the assistant what to preserve and what to reject. Keep source and expected result separate. The prompt should make it clear that these are controlled reference cases, not arbitrary output that can be redefined after a test fails.,For invoice reconciliation, the distinction may be more subtle than number formatting. A purchase order can authorize one currency while the supplier invoices in another; the model must not “correct” the observed invoice currency merely to satisfy a downstream schema.

A targeted example can demonstrate that the extracted value remains faithful to the source while validation records the contractual mismatch. This ties iterative programming to semantic output validation: a well-formed value still has to mean the right thing, and a failing business check should lead to investigation rather than fabricated data.,Examples are especially valuable when prose descriptions have already led to inconsistent interpretations. They are less useful for an authorization failure, an unavailable dependency or a broken build environment. In those cases, better instructions will not replace missing access or restore a service. The engineer should classify the failure first, then choose examples, a source lookup, a test-fixture correction or escalation according to its actual cause. Repeating the same generic example after an external-service timeout does not move the investigation forward.

Use the interview pattern when the requirement is missing

Suppose the requester says, “Handle overseas invoices properly.” A developer may assume the desired change is currency symbol formatting, while finance may mean settlement-date exchange rates, tax treatment or approval routing. Claude Code can help interview the requester before implementation. The useful questions are the ones that change a design decision: Is the source currency preserved separately? Which exchange-rate date governs? What happens when the rate is unavailable? Which system owns the authoritative amount? If several answers are possible, do not silently choose the easiest behavior to implement.,Avoid an interrogation containing every conceivable question. Start with two or three high-impact uncertainties, present the plausible alternatives in ordinary business language and explain the consequence of each.

If finance confirms that the system must store the original currency and convert only for reporting, the assistant can turn that answer into concrete acceptance tests. If the user cannot decide, the right next step may be a documented hold or a short design proposal instead of a speculative patch. The interview is an engineering tool for resolving missing constraints, not a ceremonial approval stage.,This is related to, but distinct from, choosing Claude Code plan mode. Plan mode controls when to explore rather than edit. The interview pattern obtains missing human requirements. An assistant can be in a read-only planning phase and still ask poor questions, or it can interview effectively before a small direct edit. The architect should choose each mechanism for the uncertainty it actually addresses.

Fix interacting issues together, independent issues separately

An engineer receives feedback that invoice rounding is wrong, that the error message exposes internal details, and that an unrelated dashboard label is misspelled. The first two concerns may be coupled: the formatter and its validation error contract could share code, tests or a public API response. Fixing one without considering the other may create a contradictory interface. Provide Claude with both interacting issues and a common acceptance contract so the resulting change can be checked as one coherent unit.,The dashboard typo is different. It can be handled in a separate, small task with its own scope and tests. Bundling every issue into a giant instruction increases the risk of changes crossing unrelated modules and makes failed verification harder to interpret.

A good coordinator asks whether two issues share state, implementation, test fixtures or a release invariant. If they do, they may require a combined design review. If not, prefer a bounded sequence so each outcome remains independently reversible and attributable.,The same principle governs the order of feedback. If a first patch fails because the business rule is wrong, resolve the requirement before fixing four formatting details that depend on it. If tests expose two independent import errors, addressing them separately can make regression diagnosis clearer. The decision is not “always send feedback all at once” or “always correct one thing per turn.” It is to group changes according to real dependency, then keep the artifact and tests aligned.

Read the failure before requesting another edit

Test-driven iteration only helps when the failure report changes the next hypothesis. A failing assertion should identify the input, expected output, actual output and relevant code path. For the negative-amount bug, that might mean a rounding helper applies the positive-number rule before applying the sign. Claude can then inspect the helper, propose a narrow correction and rerun the targeted test. A prompt that says “tests failed, do better” hides the evidence necessary to choose the right fix.,Do not let the assistant modify a test merely to make the output green. Test changes may be appropriate if requirements genuinely evolved, but they require review against the business contract. If a payment calculation test expects a particular amount and the implementation differs, the model must not simply replace the expected value with whatever the current code produces.

Run the original regression cases after each change and add a new case that reproduces the failure. Check the resulting diff for unrelated edits and examine test execution logs rather than trusting a generated assertion that all checks passed.,A failed command is not always a failed product. A missing test dependency, wrong working directory, expired credential or unavailable sandbox can prevent the suite from running. Report those states separately from an assertion failure. If the environment blocks testing, keep the change unverified until the required checks can run. This is especially important in noninteractive CI workflows, where a confident final message must never become the only release gate.

Protect scope, evidence and permissions across iterations

Each iteration should retain the target revision, changed files, command outputs and outstanding issues. The developer needs to know which edit produced a new test result and whether the test ran against the actual proposed commit. A scratchpad or structured checkpoint can preserve that chain when the conversation becomes long. It should include authoritative facts and file references, not simply the assistant’s opinion that the problem has almost been solved. This also helps another reviewer reproduce the investigation without replaying the entire chat.,Permission boundaries survive refinement. If the fifth attempt suddenly requires production credentials or a database migration, the model’s desire to complete the task does not grant that authority. Stop, update the plan and obtain appropriate approval. A previous successful change to a test fixture does not authorize editing billing records.

When an error arises after a write with an ambiguous outcome, reconcile the external state before trying again. A well-run iteration loop improves a controlled artifact rather than expanding its own privileges each time it encounters resistance.,Avoid endless refinement after the acceptance conditions are met. The assistant can always propose another simplification, documentation adjustment or speculative performance optimization. These might be useful later, but they should not silently expand a production patch that was intended to correct one customer-facing defect. Define a stopping rule: the required examples pass, relevant regression tests run, the diff is within authorized scope and unresolved material risks have an owner. If the evidence cannot support completion, say what remains open rather than declaring victory.

A release walkthrough that can actually be reproduced

A finance engineer reports that an invoicing API mishandles negative credits. Claude first asks whether credits should be represented as signed amounts and which rounding convention finance approves. The developer provides three concrete input/output cases, including one at the rounding boundary and another with a missing currency. Claude inspects the formatter, writes failing tests for the agreed behavior and proposes a minimal patch. The first test run reveals that the formatter shares a helper with a reporting route. The assistant reports this dependency and extends the regression plan instead of quietly rewriting the route. The next revision fixes the original credit case but produces a malformed error when currency is absent. That is an interacting issue, so the team resolves the output contract in the same bounded task. A separate dashboard-label typo is deferred.

The final patch is tested against the updated examples and relevant existing API consumers, and a reviewer checks that no unauthorized data migration or deployment setting changed. If the test service is unavailable, the engineer records an open verification item instead of trusting the assistant’s verbal confidence.,The relevant judgment is whether each iteration follows a verified requirement and whether its side effects have been checked. Concrete examples clarify ambiguous transformations, an interview surfaces missing requirements, tests expose the difference between a plausible patch and correct behavior, and feedback is grouped according to dependency. The coding agent helps form and revise hypotheses, but the business contract, test runner, permissions and reviewer decide whether the resulting artifact is ready. See the broader Claude Code workflow for repository context and execution boundaries.