Anti-Patterns to Avoid

Errors That Sabotage Your Prompts

Mastering prompting also means knowing what not to do. Certain habits, perfectly natural in human communication, yield poor results with Mistral models—precisely because they rely on implicit understanding the model lacks. This lesson lists the seven most frequent anti-patterns, with the faulty version, the corrected version, and the logic behind the correction for each. You will likely recognize a few of your own habits along the way.

Anti-pattern 1: Subjective Language

Between colleagues, “write me a text not too long” works because you share context: the colleague knows the use case, the reader, the company habits. The model does not perceive subjective words like you do. Terms like “short,” “long,” “many,” “interesting,” or “not too” are ambiguous and produce unpredictable results from one execution to the next.

Bad:

Write a text not too long about AI.
Include many interesting examples.

Good:

Write a text of 200 to 300 words about generative AI.
Include 3 concrete examples of application in business
(marketing, HR, customer service).

The correction rule is mechanical: replace every subjective term with an objective measure. “Not too long” becomes “200-300 words”, “many examples” becomes “3 examples”, and “interesting” becomes a precise description of the type of examples expected.

Anti-pattern 2: Contradictory Instructions

When your prompt contains incompatible instructions—“be exhaustive and cover all aspects” followed by “respond in maximum 3 sentences”—the model must choose which one to follow, and that choice is unpredictable. One day you get three superficial sentences, the next a comprehensive wall of text. The correction consists of reconciling the two requirements into a single, coherent instruction: “Cover the 3 main aspects of the topic. For each aspect, give a summary sentence (max 25 words).” Exhaustiveness becomes a defined scope, brevity a constraint per element—no more conflict.

If your rules are truly complex, with different behaviors depending on the case, do not pile them up: structure them as a decision tree, where each branch is explicit:

If the client is an individual:
  → Use an accessible tone, avoid technical jargon
  → Propose the Starter offer first

If the client is a business:
  → Use a professional and technical tone
  → Propose the Enterprise offer first

If you are unsure:
  → Politely ask if this is for personal or professional use

Anti-pattern 3: Asking the Model to Count

Language models are bad at counting. They do not actually count words, characters, or sentences—they estimate, because they manipulate tokens and not text units. Asking for “exactly 150 words” or “check that each sentence is less than 20 words” is like demanding a painter measure in microns: it is not their tool.

Bad:

Write a text of exactly 150 words.
Check that each sentence is less than 20 words.

Good:

Write a short text (around 150 words, 2-3 paragraphs).
Use concise and direct sentences.

And if counting is truly critical for your application—a character limit imposed by an interface, for example—perform it in code after receiving the model’s response, not in the prompt. Your programming language counts perfectly; the model does not.

Anti-pattern 4: Excessive Token Generation

Every generated token has a cost, both financial and in latency. Asking the model to produce information you will not use is pure waste: you pay more to wait longer for text you will not read. The typical case is code analysis where you ask “explain each line in detail”, plus “the history of the language” and “possible alternatives”, when only bugs interest you.

Good:

Analyze this code and identify:
1. Potential bugs (with the line concerned)
2. A proposed fix for each bug
Nothing else.

The final “nothing else” is a surprisingly powerful instruction: it explicitly tells the model not to add the complements, warnings, and expansions it produces spontaneously. Your response arrives faster, costs less, and gets straight to the point.

Anti-pattern 5: Numeric Scales

Asking the model to rate on a scale of 1 to 5 or 1 to 10 seems rigorous—in reality it is the opposite. The model does not have reliable internal calibration for these scales: the same text could receive 6/10 today and 8/10 tomorrow, with no criteria explaining the gap. The solution consists of replacing numbers with verbal scales with explicit criteria:

Evaluate the quality of this text according to these levels:
- Insufficient: factual errors, incoherent structure
- Acceptable: correct but lacks depth or clarity
- Good: well structured, clear, with relevant examples
- Excellent: publication-ready, original, brings clear added value

Choose one level and justify in 2 sentences.

Each level being defined by observable criteria, the evaluation becomes reproducible and justified—you know why a text is “Acceptable” rather than “Good”, and the model applies the same criteria at every call.

Anti-pattern 6: Vague Instructions

“Improve this text” is the perfect example of an instruction that seems clear and is not at all. Improve what? Spelling? Style? Structure? The model will choose for you, and it risks rewriting passages you wanted to keep as is. The professional version delimits both what to correct and what to leave intact:

Improve this text by correcting:
1. Spelling and grammar mistakes
2. Sentences longer than 30 words (simplify them)
3. Word repetitions within a range of 3 sentences

Do NOT modify:
- The meaning of sentences
- Technical terms (even if synonyms exist)
- Paragraph structure

The “Do NOT modify” block is as important as the first: without it, a zealous model will replace your technical terms with approximate synonyms.

Anti-pattern 7: Ignoring Pre-filling

The last anti-pattern is a missed opportunity rather than an active error: many users ignore the possibility of pre-filling the response via the assistant role, seen in the lesson on roles. Yet it is a powerful lever to force a format. With a simple user message asking for JSON, the model can add an introductory sentence, backticks, a final comment—as many elements that will break your parsing. By ending your messages with a start of an assistant response, the format becomes quasi-guaranteed:

Without pre-filling (unpredictable format):

messages = [
    {"role": "user", "content": "List 3 advantages of remote work in JSON."}
]

With pre-filling (guaranteed format):

messages = [
    {"role": "user", "content": "List 3 advantages of remote work in JSON."},
    {"role": "assistant", "content": "{\"advantages\": [", "prefix": True}
]

The model finds itself already “in the process of writing” the JSON object: it can only complete it.

Key Takeaways

• Replace subjective language and vague instructions with measurable and delimited instructions
• Avoid contradictory instructions—structure complex cases as a decision tree
• Never ask the model to count: critical counts are done in code
• Limit generation to information actually used, with verbal scales rather than numeric ones
• Leverage assistant pre-filling to guarantee output format