AnthropicClaude Certified Architect – Foundations2026-103.5 Apply iterative refinement techniques for progressive improvement
Interview before choosing an unfamiliar design
Completed by the knowledge check
Learning objective
Use an interview to surface requirements, architectural alternatives, and failure modes before work in unfamiliar areas.
Core idea
When you cannot yet specify the right behavior, ask Claude Code to interview you before it implements. Examples and tests help communicate decisions you already know. An interview helps expose decisions you have not considered, especially in a larger feature or an unfamiliar domain.
Anthropic documents this pattern using the AskUserQuestion tool. Start with a brief feature description, ask for questions about implementation, edge cases, concerns, and trade-offs, and have Claude write the resulting specification to SPEC.md. The value is the discovery of missing requirements, not the number of questions asked.
Answer from known requirements, identify unknowns, and make those distinctions visible in the specification. Claude’s questions can surface invalidation alternatives; you decide the business tolerance for stale data.
How it works
Start with the goal rather than an invented design
Suppose a developer productivity team wants a cache in front of a legacy customer service but has little experience with caching. “Add a cache” omits decisions about freshness, invalidation, failure handling, and what data may be retained. A detailed implementation request based on guesses can hide those omissions under technical specificity.
Give Claude the purpose, relevant components, and known constraints. Then request an interview using AskUserQuestion, including architectural alternatives and failure modes. Anthropic’s best-practices page specifically recommends asking about the hard parts you might not have considered and avoiding obvious questions.
For this scenario, the opening request says that customer lookup latency is the problem, identifies the existing lookup interface, and asks Claude to explore freshness and outage behavior before proposing an implementation. It asks for a complete specification in SPEC.md after the answers resolve the design. Review that specification as the workflow’s implementation artifact.
Use AskUserQuestion to collect decisions
The Claude Code tool reference describes AskUserQuestion as a multiple-choice tool for decisions and clarification. You can pick an option or provide your own text through the Other row or notes field. If none of the alternatives captures the requirement, write the actual requirement rather than accepting the closest option.
Run the interview in the main conversation. Claude Code removes AskUserQuestion from ordinary delegated subagents, even when listed in their tools field; session forks skip that filter and inherit the main conversation’s tool pool. The dontAsk permission mode denies AskUserQuestion even if the tool is explicitly allowed.
Questions stay open until answered by default. With askUserQuestionTimeout set to 60s, 5m, or 10m, an unanswered question can close automatically, submitting selected options and letting Claude proceed on its own judgment. The timer pauses while the terminal window is focused and never starts in background sessions, screen reader mode, or Remote Control. If a timed-out question leaves a requirement unresolved, record it as unresolved in SPEC.md rather than treating Claude’s continuation as an owner decision.
Require a reason for consequential questions. “How stale may a customer address be?” reveals a correctness choice. “Which invalidation approach fits the available write events?” connects an architectural alternative to infrastructure the team actually has. “What does a lookup return if the legacy service is unavailable?” establishes the failure behavior that tests must later check.
Turn alternatives into requirements
The following interview topics are illustrative requirements for this cache, not prescribed Anthropic caching behavior:
| Topic | Question that exposes the decision | What the specification must resolve |
|---|---|---|
| Freshness | How long may a lookup return an unchanged cached record? | An approved freshness rule and the point at which a value is unacceptable |
| Invalidation | Can writes publish a reliable invalidation signal, or must reads rely on expiry? | A selected approach and the assumptions that make it viable |
| Service outage | Should the caller receive an error or an approved stale value? | The allowed response for each relevant failure condition |
| Cache failure | What happens if the cache is unavailable but the legacy service is healthy? | The fallback behavior and its acceptance evidence |
| Isolation | Which record identity and access context determine a reusable value? | The lookup interface and the conditions under which reuse is valid |
The interview should compare alternatives instead of asking you to approve a single assumed design. For example, event-based invalidation requires an event source whose behavior the team can establish. Expiry-based reuse requires an acceptable freshness interval. The question is not which sounds more sophisticated; it is which can meet the agreed requirement with the interfaces available.
When you do not know an answer, say so. Ask Claude to identify the code or interface that needs investigation and keep the unresolved decision visible. An unanswered question should not become an undocumented default. If an alternative depends on a capability nobody has verified, that dependency belongs in the specification as unresolved rather than as an implementation promise.
Write a self-contained specification and change context
Anthropic recommends a specification that names involved files and interfaces, states what is out of scope, and ends with an end-to-end verification step. Review SPEC.md for those elements and for the requirement, alternative, and failure-mode decisions surfaced by the interview.
A useful specification for this cache states which lookup path changes, which callers retain the same interface, which freshness behavior is accepted, how failure responses work, and how the team proves those outcomes. It also identifies decisions requiring further evidence. “Use the approach discussed earlier” is not self-contained because a fresh session cannot recover the intended choice from that phrase.
Once the specification is complete, Anthropic recommends starting a fresh session to execute it. Reference the reviewed specification in the implementation request so the coding context is centered on the approved design. See 3.5.2 for preparing tests from the specification before implementation. Do not reopen the entire interview merely because implementation begins; unresolved design decisions should already be explicit in the artifact.
Key distinctions and trade-offs
An interview versus codebase questions: Asking how an existing module works explains available behavior. Asking Claude to interview you elicits requirements and choices for behavior you want to build. Both can support discovery, but their outputs differ.
Requirements versus alternatives: “Addresses may be stale for at most the approved interval” is a requirement. Event invalidation or expiry is an architectural option for meeting it. Record the requirement separately so a later design change does not silently change correctness.
Exploration versus implementation: The interview ends in a reviewed specification. It is not evidence that the feature has been implemented or verified. That evidence comes from executing the resulting acceptance checks.
The pattern adds conversation and review overhead. Anthropic recommends it for larger features. A small, understood edge-case repair already has a known input and required output; use 3.5.3 for that case instead of conducting a broad design interview.
Architecture / decision scenario
A team uses Claude Code to plan a customer lookup cache. It knows the affected interface and its latency concern, but has not decided invalidation or outage semantics. The developer requests an AskUserQuestion interview before implementation and asks for alternatives as well as failure-mode questions.
The interview reveals that the legacy writer cannot supply a reliable invalidation event. It also reveals that some lookups tolerate bounded staleness while another caller requires a fresh value. These are scenario findings supplied by the team, not facts Claude should invent. The specification must therefore distinguish those caller requirements and record the selected reuse behavior for each.
The developer rejects a blanket “serve cached data during outages” assumption and answers which callers may accept stale data. Claude writes the involved files, interface behavior, selected alternatives, outage responses, exclusions, and verification requirements into SPEC.md. After review resolves the remaining questions, a fresh session receives that artifact for test-first implementation. The interview has surfaced a correctness distinction that a one-line cache request would have left implicit.
Common exam traps
- Asking for implementation before exploring unfamiliar requirements and failure modes.
- Supplying a guessed detailed design and treating it as a complete requirement set.
- Using only obvious questions that never expose trade-offs or alternatives.
- Treating a selected option as proof that an external system supports it.
- Letting unknown answers become invisible defaults in the specification.
- Assuming an interview or written plan proves the implementation works.
What to remember
Use AskUserQuestion to surface the hard choices before implementing a larger, unfamiliar feature. Separate requirements, alternatives, and failure behavior, then review a self-contained SPEC.md with files, interfaces, exclusions, and verification. Start implementation in a fresh session using that approved artifact.
Knowledge check
A team must put a cache in front of a slow legacy customer service and has never built one. Claude Code’s first implementation keeps missing considerations nobody specified, such as invalidation and outage behavior. What is the most effective next step?
AskUserQuestion interview and record the decisions in SPEC.mdA team defines an ordinary, non-fork custom subagent for requirements gathering and lists AskUserQuestion in its tools field. The main session runs in Manual mode, yet when Claude delegates to that subagent, no question ever reaches the developer. What explains it?
AskUserQuestion from the delegated subagent’s toolsAskUserQuestion requires askUserQuestionTimeout before a subagent can use itAskUserQuestion until an allow rule names the toolAskUserQuestion is on the short list of tools Claude Code removes from every ordinary subagent, whatever its tools field says, so the interview belongs in the main conversation. The timeout only lets an unanswered question close, and the mode that denies the tool even when allowed is dontAsk , not Manual.With askUserQuestionTimeout set to 5m, a question about what lookups return during a legacy-service outage closes unanswered, and Claude continues on its own judgment. How should SPEC.md record outage behavior?
References
- Anthropic, Best practices for Claude Code
- Anthropic, Tools reference
- Anthropic, Create custom subagents