Adjusting Approach Based on Feedback & Results.

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.

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.