Most prompt engineering advice on the internet is dated, performative, or both. Here are the anti-patterns to avoid.
Anti-pattern 1 — "You are the world's best expert in..."
Verbose role descriptions like "You are the world's most accomplished expert in quantum physics with 30 years of experience..." used to be common advice. They don't help.
Modern frontier models default to high-competence behavior. Telling them to "be an expert" doesn't unlock hidden capability. It just wastes tokens.
What to do instead: state the role concretely.
Bad:
You are the world's greatest customer support agent, beloved by all customers...
Good:
You are a customer support agent for Acme Shoes. Tone: empathetic, professional, concise.
Saves tokens. Same or better behavior.
Anti-pattern 2 — Threats and bribes
"I'll give you $200 if you do this correctly" or "You'll lose your job if you make a mistake."
In 2023, these worked occasionally on some models. They don't reliably work on modern models. They're embarrassing if anyone sees the prompt.
Just ask for what you want, with constraints.
Anti-pattern 3 — Asking for "creativity" at temperature 0
Be creative and original. Generate a unique poem about coding.
With temperature 0, output is near-deterministic. Same prompt → same poem. The "creativity" instruction does nothing.
Match the parameter to the task:
- Tasks needing consistency (classification, extraction, code) → temperature 0.
- Tasks needing variety (creative writing, brainstorming) → temperature 0.7-1.0.
Don't ask for creative output and configure for deterministic generation.
Anti-pattern 4 — Multiple competing instructions
You must respond in JSON. Be conversational. Always end with a question. Keep responses short. Use bullet points where helpful.
Five instructions, some contradictory. The model picks 2-3 to follow.
Pick the 1-2 most important constraints. If you must have more, prioritize:
PRIMARY: Respond in JSON matching this schema.
SECONDARY: draft_response field should be conversational and under 50 words.
Or use structured output mode so format is guaranteed and you can focus instructions on content.
Anti-pattern 5 — No example for the desired behavior
Extract the customer name, email, and order details from the message.
Without an example, the model guesses at format. Some outputs have "Name:" prefix; others bare strings; some include phone numbers you didn't ask for.
Add an example:
Extract the customer name, email, and order details.
Example:
Message: "Hi I'm Anuj, anuj@x.com, order #12345 missing"
Output: {"name": "Anuj", "email": "anuj@x.com", "order_id": "12345", "issue": "missing"}
Now extract from:
Message: ...
Output:
Examples are the single most impactful change for inconsistent outputs.
Anti-pattern 6 — Treating the prompt as code, not iterating
The first prompt almost never works perfectly. Production prompts are iterated dozens of times.
The cycle:
- Write initial prompt.
- Test on 20-50 representative examples.
- Identify failure modes.
- Adjust prompt (add examples, tighten constraints, restructure).
- Re-test.
- Repeat until quality is acceptable.
If you're shipping the first draft, you're under-engineering.
Anti-pattern 7 — Hidden state / referring to "earlier"
Refer to the customer details I mentioned earlier.
The model doesn't have a memory across calls (unless using chat history). "Earlier" doesn't exist. Either include the data in this call's context or use a tool to retrieve it.
Anti-pattern 8 — Mixing instructions and data without delimiters
Customer: I want a refund my email is bob@x.com please help
You are a support agent...
Where do the instructions end and the data start? The model has to guess. Use clear delimiters:
INSTRUCTIONS:
You are a support agent for Acme. Extract the customer's email and issue.
CUSTOMER MESSAGE:
"I want a refund my email is bob@x.com please help"
OUTPUT:
Or use XML-style tags (Claude-friendly):
<instructions>You are a support agent...</instructions>
<message>I want a refund...</message>
Clear structure → better parsing → better outputs.
Anti-pattern 9 — Ignoring the temperature × task mismatch
Forgetting that temperature controls randomness, not skill. Examples:
- Math reasoning at temperature 1.0 → unstable, gets the same problem right/wrong on different runs.
- Creative writing at temperature 0 → outputs feel mechanical, no variation.
Default for production:
- Most tasks: temperature 0 or 0.1.
- Exploration / brainstorming / variety needed: 0.7-1.0.
Anti-pattern 10 — Not testing on diverse inputs
Build a small test suite (30-100 examples covering the variety of real inputs). Test prompts against it before deploying. After deploying, monitor production failures.
Without test data, every "improvement" might fix one case and break another silently.
Quick checklist before shipping a prompt
- System prompt sets role concretely (no purple prose).
- Task is specific.
- 2-5 diverse examples included.
- Constraints listed explicitly.
- Output format specified (use structured output mode if API supports).
- Temperature matches task (0 for deterministic, higher for varied).
- Tested on 20+ representative inputs.
- Static prefix cached (Module 2 lesson on caching).
- Max_tokens set.
Takeaway
Most prompt mistakes are doing too much (verbose roles, contradictory instructions, threats) rather than too little. Specific role + clear task + good examples + tight constraints + tested = production-ready. Skip the marketing-style prompt engineering.