Top 5 Prompt Engineering Mistakes & How to Fix Them

The main reason for poor AI output is usually a poorly written prompt. Here are the 5 most common mistakes millions of users make every day, and how to turn them into professional prompts:

1. Writing Overly Vague Prompts

Writing a general request without giving the model a role, context, or depth leads to shallow results.

The difference isn't "how much" information — it's "which" information. Give the audience, length, and topic together and the model no longer has to guess which one to prioritize. A short prompt isn't necessarily bad; a prompt missing context is.

2. Omitting the Output Format

Whether the AI should return plain text, a table, or JSON directly affects the quality of the result.

Asking for a JSON schema doesn't guarantee the output will always be parseable — the model sometimes strays outside the schema or adds explanatory text. In a critical application you still need to validate that output separately (schema validation); the prompt reduces the risk, it doesn't eliminate it.

3. Skipping Few-Shot Examples

Giving the model 1-2 concrete input/output examples (few-shot prompting) noticeably improves classification and transformation consistency compared to a zero-shot prompt.

There's no single answer for how many examples are enough — the more nuanced the task, the more examples it needs. Starting with 2-3 examples and adding new ones from cases the model misclassifies is more practical than writing 10 examples upfront.

4. Using Negative Constraints ("Don't Do X")

Telling the model what NOT to do scatters its focus. Clearly define the positive rule you actually want instead.

This is because processing a negative rule forces the model to first consider the forbidden thing and then suppress it — that extra step leaves room for error. Defining the desired behavior directly removes that step entirely.

5. Not Templatizing Your Prompts

Rewriting the same prompt from scratch every time wastes effort. Use a prompt manager like YONT to templatize prompts with dynamic variables.

The variables in YONT — things written in curly braces like {meeting_name} — exist exactly for this: you keep the same structure and only fill in the part that changes, while the rest of the rules and format stay identical every time.

Thinking About All Five Together

All five mistakes share the same root cause: the bigger the gap the model has to guess-fill, the more random the result. Context, format, examples, positive rules, and reusability all aim at the same thing — narrowing the room for interpretation you leave the model. If you checked more than 3 boxes in the check-up above, starting with the top item (missing context) usually brings the biggest improvement.

Frequently Asked Questions