CCAR-F - Claude Code Configuration & Workflows - Section 3.5

Apply iterative refinement techniques for progressive improvement.

Concrete input and output examples communicate an expected transformation better than prose that gets read inconsistently. Test-driven iteration writes the suite first and then feeds failures back. The interview pattern has Claude ask questions that surface considerations the developer had not anticipated. Candidates should give every interacting issue in one detailed message and fix independent issues sequentially, which is the reverse of the intuitive ordering.

concrete input and output examplestest-driven iterationinterview patterninteracting versus independent issuesedge case test cases

Practice question for this objective

Free sampleClaude Code Configuration & Workflowsmedium

A logistics platform team uses Claude Code to refactor a shipment date parser in a Node service. The engineer's prompt reads, in full, that the parser should handle more formats and be tidier. Across five attempts the model returns a different function signature each time, and on two of those attempts it changes the return value from a Date object to an ISO string. The engineer discards every attempt after reading it, losing about forty minutes. Which change most effectively addresses the wasted iterations?

  • ARaise the extended thinking budget for the session so the model reasons for longer about the refactor before it starts writing the replacement parser.
  • BRewrite the prompt with three concrete input strings, the exact value each should return, and the required return type, then iterate the parser against those examples. Correct
  • CRun the refactor in plan mode so the model presents a written plan for approval, and reject any plan that proposes work beyond the parser file itself.
  • DAdd a line to the project CLAUDE.md stating that refactors must preserve the existing exported function signature unless a change is explicitly requested.
Anchor an iterative refinement loop with concrete input and output examples so each attempt has a checkable target. Iteration converges when the target is fixed and checkable. A prompt describing a preference gives the model latitude on signature, return type and accepted formats, so each attempt samples a different reasonable interpretation. Supplying specific inputs with their expected outputs removes that latitude, turning subjective review into a comparison the engineer can complete in seconds.

Why A is wrong: More reasoning time is a genuine lever on hard problems, so it feels like the obvious upgrade, but the model is not failing to reason. It is reasoning correctly towards an underspecified target, and a longer think produces another plausible signature the engineer did not want.

Why B is correct: Concrete input and output pairs convert an unstated preference into a checkable specification, so each iteration has a fixed target and the engineer can judge an attempt without re-reading the whole function.

Why C is wrong: Plan mode does surface intent before code is written, which would shorten each wasted cycle, but the plan is drafted from the same vague instruction. The engineer would be approving or rejecting guesses about the output shape rather than stating it.

Why D is wrong: Project memory is the right home for a standing convention and would help on later tasks, but it pins down one attribute while leaving the accepted formats and expected outputs unstated, so the attempts still diverge on everything the rule does not cover.

See more CCAR-F practice questions, answers explained.

More in this domain

Back to all Claude Code Configuration & Workflows objectives, or the CCAR-F cert hub.

Examworthy is not affiliated with or endorsed by Anthropic. Original, blueprint-aligned practice material only.