Common Prompt Anti-Patterns

Recognizable prompt design mistakes the exam tests: negative-only instructions, task overload, and self-review in one call.

Prompt Engineering·Lesson 6 of 6·7 min

This lesson collects recurring prompt-design mistakes that show up across exam scenarios. Recognizing the pattern by name is often faster than re-deriving the fix from first principles during the exam.

Negative-only instructions

Telling the model what not to do ("don't include a preamble," "don't use markdown," "don't mention pricing") without stating the positive alternative leaves the model to guess what to do instead, which produces inconsistent results. "Don't use markdown" is weaker than "respond in plain prose sentences, no headers or bullet lists." The fix is always to pair or replace the negative instruction with a concrete positive instruction describing the desired behavior directly.

Overloaded prompts

A single prompt asking the model to do several unrelated things at once — summarize a document, translate it, extract structured data from it, and critique its tone — tends to produce weaker results on each sub-task than separate, focused prompts would. This is different from a genuinely multi-step task where the steps depend on each other (which chain-of-thought or a structured multi-part prompt can handle well); the anti-pattern specifically refers to bundling unrelated tasks that don't need to share context, purely to save API calls. The fix is to split unrelated tasks into separate calls, each with a focused, single-purpose prompt.

Self-review in one call

Asking a single call to generate an answer and then check its own work in the same turn tends to rubber-stamp the generation, because the same reasoning that produced the (possibly flawed) answer is what's being asked to evaluate it — there's no independent perspective. The fix is a multi-pass review: a separate call, ideally with a differently framed prompt (and sometimes a different persona or explicit adversarial framing, "find problems with this output"), reviewing the first call's output. Separating generation and review into different calls produces meaningfully more critical review than asking one call to do both.

Other patterns worth knowing

Vague success criteria (asking for "a good summary" instead of specifying length, audience, and what to include/exclude) forces the model to guess at implicit requirements. Burying the actual task deep inside a long block of unstructured context, with no XML tags separating instructions from reference material, makes it easy for the model to lose track of what's actually being asked. Both are instances of the same underlying problem: leaving too much for the model to infer when it could be stated directly.

Exam trap A scenario shows a single prompt asking Claude to draft a customer email, then evaluate whether the email is polite enough, then revise it if not, all in one response. The setup looks like it's already doing "review," so a tempting wrong answer is "this is fine, it already includes a review step." The correct critique is that self-review inside one generation call is unreliable — the fix is a second, separate call whose only job is to critique the first call's draft against explicit criteria.

A content pipeline prompt reads: "Write a product description. Don't make it sound salesy. Don't use exclamation points. Don't be too long." The output is inconsistent in tone across runs. The fix is to replace each negative constraint with a positive one: state the target tone directly ("write in a neutral, factual tone"), state a concrete length ("2-3 sentences"), and state what punctuation to use instead of only what to avoid. Positive, concrete instructions give the model a target to hit rather than an open-ended space of things to avoid.

Anti-patterns as a checklist

On the exam, scenario questions about a failing or unreliable prompt are frequently solvable by pattern-matching against this list rather than reasoning from scratch: check whether the prompt states positive requirements or only prohibitions, whether it bundles unrelated tasks that could be split, whether it asks one call to both generate and critique itself, whether success criteria are vague, and whether distinct content types are separated with structure. Most "why is this prompt unreliable" questions map cleanly onto one of these five patterns, and the fix is almost always to state something explicitly that was previously left implicit.

Anti-patterns compound

These issues are not mutually exclusive, and a single weak prompt often exhibits several at once: a prompt with vague success criteria, no positive framing, and several unrelated tasks bundled together is common in practice, and fixing only one of the three issues may not measurably improve reliability. When a scenario's prompt is described as "unreliable" without further detail, it's worth checking it against the full list rather than assuming only one issue is present.

Try it

Take a prompt you have that contains at least one "don't do X" instruction with no stated alternative. Rewrite it as a positive instruction describing the desired behavior directly, run both versions against 5 inputs, and check whether the rewritten version produces more consistent output on the dimension the instruction was targeting. While you're at it, check the same prompt against the other four anti-patterns in this lesson and note which, if any, also apply.