Why Your AI Prompt Fails, and the Seven Fixes That Work

Quick answer: Most prompts fail for one of seven reasons: the instruction is vague, you said what you wanted but not why, you gave no examples, you asked for an answer instead of the reasoning, your instructions and your data are tangled together, you expected the same output every time, or you were never measuring quality in the first place. The fixes are specific and mostly take minutes. Anthropic's own guidance offers a test worth memorising: "Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too."

The failure underneath all the others

Before the seven, there is one that causes most wasted effort: you have no way of telling whether a change made things better.

Anthropic's prompt engineering guide assumes three things before you even start tuning a prompt: a clear definition of what success looks like, some way to test against it empirically, and a first draft to improve (Claude docs). Most people skip the first two, change a word, read one output, decide it feels better, and move on.

You do not need anything elaborate. Ten saved examples of the task, with a note on what a good answer looks like, is enough to stop you fooling yourself. Without it you are not engineering a prompt, you are gambling repeatedly.

Failure 1: The prompt is vague

This is the most common by a distance. "Write a summary", "make it better", "analyse this data" all assume the model knows a standard it was never told.

The Claude documentation suggests thinking of the model as "a brilliant but new employee who lacks context on your norms and workflows". A new hire handed "write a summary" would ask: how long, for whom, what matters, what format. The model does not ask. It guesses, and the guess is generic.

The fix: be explicit about the output format, the audience, the length and the constraints. If order or completeness matters, give the steps as a numbered list. And apply the golden rule above: hand the prompt to a colleague and see if they would be confused.

Failure 2: You said what, but not why

This one is counter-intuitive, and it is in the documentation as explicit guidance: explaining the reason behind an instruction produces better results than the instruction alone.

The example Anthropic gives is precise. "NEVER use ellipses" is less effective than "Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them." The documentation's reasoning is that the model "is smart enough to generalize from the explanation" (Claude docs).

A rule covers the case you thought of. A reason covers the cases you did not.

The fix: add one clause explaining why the constraint exists. It costs a few tokens and it handles the edge cases your rule missed.

Failure 3: You gave no examples

If you want a specific format, tone or structure, describing it is weaker than showing it. Examples, also called few-shot or multishot prompting, are described in the Claude docs as "one of the most reliable ways to steer Claude's output format, tone, and structure".

The guidance is specific about how to do it well. Include 3 to 5 examples. Make them relevant, mirroring your real use case. Make them diverse, covering edge cases and varying enough that the model does not latch onto an unintended pattern. And make them structured, wrapped in tags so the model can tell an example from an instruction.

That middle point is the one people miss. If all your examples share an accidental trait, such as every one being short, the model will copy the accident as faithfully as the intent.

The fix: add three to five varied examples of a good answer, including at least one awkward case.

Failure 4: You asked for the answer, not the working

For anything involving multi-step logic, comparison or calculation, demanding the final answer immediately tends to produce confident errors. Asking the model to work through its reasoning before answering tends to fix them.

This is why "think step by step" became well known, and the underlying reason is mechanical rather than magical: the model generates text sequentially, each token conditioned on what came before, so producing intermediate reasoning gives the final answer better material to be conditioned on. Skip the working and the answer is generated with nothing to stand on.

The fix: for reasoning-heavy tasks, ask for the steps first and the conclusion last. For simple lookups and rewrites, do not bother, as it only adds cost and delay.

Failure 5: Instructions and data are tangled together

Paste a long document straight after your instructions and the boundary blurs. The model has to infer which part is the task and which is the material, and sometimes it infers wrong, especially when the document itself contains instruction-like sentences.

The documented fix is to wrap each kind of content in its own tag, such as <instructions>, <context> and <input>, which "reduces misinterpretation". There is a second, less known point for long inputs: put the long document near the top, above your query and instructions, which the docs state "improves performance across all models".

The fix: long material first, clearly tagged, then your instructions, then your question.

Failure 6: You expected the same answer every time

People report this as a bug constantly: the same prompt, two different answers. It is not a bug, it is how the technology works. The model samples from a probability distribution rather than selecting one fixed output, and the temperature setting controls how much variation there is.

Worth knowing precisely, because it surprises engineers: Anthropic's documentation notes that "Even with temperature set to 0, the results will not be fully deterministic and identical inputs may produce different outputs across API calls" (Claude docs).

The fix: lower the temperature for tasks that need consistency, and design around variation rather than wishing it away. If your system breaks when the wording changes, ask for structured output and validate it, rather than parsing prose and hoping.

Failure 7: You overloaded the context window

The context window is the model's working memory for a single request, distinct from what it learned in training. Everything competes for that space: your instructions, your examples, your pasted documents, the conversation so far.

Two practical consequences. First, pasting an entire handbook to ask about one clause makes the relevant passage compete with thousands of irrelevant ones. Second, in a long conversation, instructions you gave at the start carry less weight than you assume.

The fix: give the model the part that matters rather than everything you have. If you cannot know in advance which part matters, that is no longer a prompting problem and you need retrieval, which we cover in RAG vs fine-tuning vs prompt engineering.

The order to fix them in

1. Build a small test set

   Ten real examples of the task with a note on what good looks like. Everything after this depends on being able to tell whether a change helped.

2. Make the instruction explicit

   Format, audience, length, constraints. Add the reason behind each constraint. This alone fixes a large share of failing prompts.

3. Add three to five varied examples

   Relevant, diverse, clearly separated from instructions. Include an awkward case.

4. Separate instructions from data

   Tag each type of content. Put long material at the top.

5. Add reasoning steps if the task needs them

   Only for genuine multi-step work, since it costs tokens and time.

6. Then tune settings

   Temperature last, once the prompt itself is sound. Settings cannot rescue an unclear instruction.

When the problem is not the prompt

Some failures cannot be prompted away, and recognising them saves days.

• The model does not know your data. No prompt can tell it about documents it has never seen. That is a retrieval problem.
• It needs current information. Training data has a cutoff. Retrieval or a tool call is the answer.
• It must take actions, not just answer. Checking a database or sending something requires tools, which is where agentic systems begin.
• The format drifts no matter what. If it is right most of the time but must be right every time, that is the narrow case for fine-tuning.

Anthropic's own documentation makes the same point about scope: "Not every success criteria or failing eval is best solved by prompt engineering."

Learning this properly

The seven failures above are diagnosable because they come from how the model works, not from a list of magic phrases. That is the difference between collecting prompts and being able to engineer them: a prompt you copied solves one task, while understanding why it works solves the next one too.

Our self-paced prompt engineering course teaches that mechanism in 15 lessons, from how models predict the next word through tokens, context windows, temperature and sampling, with a graded project where you diagnose and fix a prompt for a task you actually repeat. It needs no programming. If you want to build systems rather than use them, the RAG course is the usual next step.

Sources

• Anthropic, Claude prompting best practices: the "brilliant but new employee" framing, the golden rule for testing a prompt, guidance on explaining the reason behind instructions, the 3 to 5 examples recommendation with relevant, diverse and structured criteria, XML tag structuring, and placing long-form data at the top: platform.claude.com.
• Anthropic, prompt engineering overview: the prerequisites of success criteria and empirical tests, and the note that not every failing evaluation is best solved by prompt engineering: platform.claude.com.
• Anthropic, Claude documentation glossary: definitions of context window, tokens and temperature, and the statement that results are not fully deterministic even at temperature 0: platform.claude.com.
• All sources were read directly at the time of writing. Model behaviour and vendor guidance change, so check current documentation before relying on any specific detail. Written 4 October 2026.