# Adjusting Approach Based on Feedback & Results > When a Claude output misses the mark, the fix Anthropic teaches is diagnostic, not a re-roll: define what a good answer looks like, compare the actual output against that bar, change one input at a time, and re-test before deciding it worked. Treating "ask again" or "ask Claude to redo it" as the fix skips the step that actually tells you whether anything changed. **Domain:** CCAOF-D7 · Troubleshooting & Optimization (10% of the exam) **Canonical:** https://claudearchitectcertification.com/concepts/adjusting-approach-from-feedback **Last reviewed:** 2026-05-04 ## Quick stats - **Adjustment loop steps:** 4 - **Exam domain:** CCAOF-D7 - **Domain weight:** 10% - **Console eval grading scale:** 5-point - **Inputs changed per iteration:** 1 ## What it is When a Claude response misses the mark, the fix is rarely "ask again and hope." Anthropic frames prompt engineering as an empirical loop: define what a good answer looks like, run the prompt, compare the actual output against that bar, then change one thing at a time and re-test. For a business user without engineering tooling, this means treating a disappointing output as diagnostic information, not a dead end, the gap between what you got and what you needed tells you exactly what to change in the next prompt. This is a mindset shift as much as a technique. A re-roll, running the identical prompt again, can only reveal randomness in the model's output; it cannot fix a prompt that is missing context, has an ambiguous instruction, or specifies the wrong format. Adjusting approach means identifying which specific input caused the gap, then changing that input, not the whole prompt, and not by re-running it unchanged. ## How it works Start from a success criterion, not a vibe. Anthropic's own guidance says prompt engineering should start from "a clear definition of the success criteria for your use case" and "some ways to empirically test against those criteria," without that baseline, there is no way to tell whether a change actually helped, only whether the new output feels different. Isolate the actual gap before changing anything. A response that is technically accurate but too jargon-heavy for its audience is not a factual error, it is an audience-and-tone gap. The correct adjustment targets that specific input, an explicit audience description, a tone constraint, not a wholesale prompt rewrite that risks fixing one thing while breaking another. The Claude Console has tooling built for exactly this loop, even though a business user working in chat does the same thing manually. A prompt improver tool takes an existing prompt and automatically refines it, described as letting a user "quickly iterate and improve your prompts through automated analysis and enhancement." Separately, an Evaluate feature generates test cases (manual, CSV, or Claude-generated), runs a prompt against all of them, and compares two or more prompt versions side by side, including a subject-matter expert grading output quality on a 5-point scale to confirm a change actually improved results, rather than just feeling better. A latency or cost problem is not automatically a "switch the model" problem - prompt content is a direct lever on both. Input tokens are what you pay for and what the model has to process before it can respond, so a bloated prompt (unnecessary repetition, an oversized system prompt, redundant few-shot examples, more context than the task needs) directly inflates both cost and latency, the same way a rewrite fixes an accuracy or tone gap. Anthropic's own guidance is narrower than "prompt content is irrelevant to latency/cost": it says latency and cost can *sometimes* be more easily improved by selecting a different model, not that prompt trimming never helps. The correct diagnostic order is: first measure what's actually driving the token count (is the prompt itself lean, or is it carrying dead weight?), trim it if it isn't, and only reach for a model swap once the prompt is already lean and the model's per-token speed or price is the remaining bottleneck. ## Where you'll see it in production ### PM drafting release notes Diagnoses a jargon-heavy draft as an audience-and-tone gap, adds an explicit audience description and tone constraint to the prompt, then compares the two outputs side by side before shipping. ### Ops team scaling a working prompt Uses the Console's Evaluate feature to run an updated prompt against a generated test set and confirm the change improved output quality on a 5-point SME scale, rather than assuming it did. ### Budget-constrained pipeline running slow and over cost Checks the prompt's token composition first, trims a bloated context block and redundant few-shot examples, since input tokens drive both cost and latency directly, then reaches for a smaller/faster model tier only if the now-lean prompt is still the bottleneck. ## Decision tree 1. **Is the actual problem output quality (wrong content, tone, or format) rather than speed or cost?** - **Yes:** Adjust the prompt, identify the specific input responsible (missing context, ambiguous instruction, wrong format constraint) and change only that. - **No:** It's a latency/cost problem, but check the prompt's token composition first (see next question) before assuming a model swap is the only lever - input tokens drive both cost and latency directly. 2. **For a latency or cost problem: is the prompt itself lean, or is it carrying unnecessary length (redundant context, oversized examples, repeated instructions)?** - **Yes:** The prompt isn't the bottleneck; selecting a different model (faster/cheaper tier) is the more direct lever here, per Anthropic's guidance that latency/cost can sometimes be more easily improved by model choice. - **No:** Trim the prompt first, fewer input tokens reduce both cost and latency directly - this is a legitimate fix for a speed/cost problem, not just for quality, and should be tried before switching models. 3. **Can you point to the exact input that caused the gap (e.g. no audience described, no format specified)?** - **Yes:** Change that one input and re-run, isolating the fix makes the before/after comparison meaningful. - **No:** Re-read the output against your success criteria first, changing several things at once makes it impossible to tell which change worked. 4. **Did you define what a good answer looks like before you ran the prompt the first time?** - **Yes:** Compare the new output against that same criterion, not against how the previous output felt. - **No:** Define the success criterion now, retroactively, before judging whether the new output is actually better. 5. **Are you comparing the old and new output side by side before deciding the change worked?** - **Yes:** This is verified improvement, the Console's Evaluate feature does this systematically, with SME grading on a 5-point scale. - **No:** A response that feels better without being checked against the original criteria is not verified improvement, it is guessing. ## Exam-pattern questions ### Q1. A PM re-runs the exact same prompt three times hoping for a better release-notes draft, and picks the version that reads best. What is the flaw in this approach? Re-running an identical prompt can only surface randomness in the model's output, it cannot fix a prompt that is missing context or has an ambiguous instruction. The distractor "running it multiple times and picking the best one is a valid adjustment strategy" mistakes sampling variance for a fix, nothing about the input changed, so nothing about the underlying gap was addressed. ### Q2. Claude's release notes draft is accurate but too technical for the intended customer audience. What is the correct next step? Isolate the actual gap, an audience and tone mismatch, not a factual error, and add an explicit audience description plus a tone constraint to the prompt, then compare the two outputs. The distractor "rewrite the entire prompt from scratch" risks fixing the tone while accidentally breaking something that already worked, and makes it impossible to tell which change helped. ### Q3. A team member says a new prompt version is clearly better after one manual read-through, with no defined criteria beforehand. Is this a verified improvement? No. Without a success criterion defined before the run, a response that feels better has not been checked against anything, it is guessing, not verification. The distractor "a confident read-through by an experienced user is sufficient verification" substitutes subjective impression for the empirical comparison this objective tests. ### Q4. An associate's prompt produces correct, well-formatted answers but takes too long and costs more than the team's budget allows. The prompt carries a large repeated context block and several redundant few-shot examples. They spend an hour trimming it down to only what the task needs. Did they adjust the right lever? Yes. Input tokens directly drive both cost and latency, so trimming a prompt that was carrying unnecessary length is a legitimate, often first-line fix for a speed/cost problem, not just for an accuracy or tone problem. The distractor "prompt content cannot affect latency or cost, only switching models can" is false: Anthropic's own guidance is that a different model can *sometimes* more easily improve latency/cost, not that prompt content is irrelevant to either. A model swap becomes the more direct lever once the prompt is already lean and the token count itself isn't the bottleneck. ### Q5. In the Claude Console, a team wants to confirm that Prompt Version B is actually better than Prompt Version A before shipping it, not just different. What feature is designed for this? The Console's Evaluate feature, it runs both versions against the same generated test cases and supports side-by-side comparison, including SME grading on a 5-point scale. The distractor "just ship Version B since it looks more polished" skips the empirical comparison step that turns a hunch into a verified result. ## FAQ ### Q1. Is re-running the same prompt a form of adjusting approach? No. A re-roll can only reveal randomness in Claude's output, it cannot fix a prompt that is missing context, has an ambiguous instruction, or specifies the wrong format. Adjusting approach means changing the specific input responsible for the gap. ### Q2. What if the problem is that Claude is too slow or too expensive, not wrong? Check the prompt's token composition first - input tokens directly drive both cost and latency, so trimming an unnecessarily long prompt is a legitimate fix. Anthropic's own guidance is that a different model can sometimes more easily improve latency/cost, not that prompt content is irrelevant to them; reach for a model swap once the prompt is already lean. --- **Source:** https://claudearchitectcertification.com/concepts/adjusting-approach-from-feedback **Last reviewed:** 2026-05-04 **Evidence tiers**, 🟢 official Anthropic doc / API contract · 🟡 partial doc / inferred · 🟠 community-derived · 🔴 disputed.