Common Prompt Engineering Mistakes

What Counts as a Prompt Engineering Mistake? A prompt engineering mistake is any decision in how a prompt is written, tested, or used that makes the model's output less accurate, less consistent, or less useful than it could be.

Most mistakes do not cause obvious errors. The model still produces a fluent response, which is exactly why mistakes are easy to miss. The response looks reasonable but answers a slightly different question, uses the wrong format, invents a missing fact, or works on one input and fails on the next.

This lesson organizes the most common mistakes into six categories, shows how to recognize each one from the symptoms in the output, and finishes with a complete example of diagnosing and fixing a flawed prompt.

Category Where the Mistake Happens

1. Task definition What you ask the model to do
2. Information What the model is told about the situation
3. Input data How the material to process is provided
4. Output How the expected result is defined and handled
5. Process How the prompt is developed and tested
6. Reliability and safety How the output is trusted and protected Category 1: Task Definition Mistakes 1.1 Vague Task Symptom: The response is reasonable but not what you needed.

Cause: General verbs such as handle, improve, or write about allow several interpretations (Lesson 5).

Example:

Improve this paragraph. Fix:

Shorten this paragraph to under 60 words while keeping the two statistics it mentions. 1.2 Too Many Tasks in One Instruction Symptom: Some requested parts are missing or done superficially.

Cause: Several actions are combined in one long sentence, so the model loses track of some of them.

Example:

Read this code and find bugs and explain them and optimize it and add tests and comments. Fix: Number the steps, or split the work into separate prompts (Lesson 15).

1.3 Conflicting Instructions Symptom: Output follows one instruction on some runs and a different one on others.

Cause: Requirements contradict each other, such as "be comprehensive" and "maximum 50 words", and no priority is stated.

Fix: Remove the conflict or state which requirement wins (Lesson 5, Technique 8).

1.4 Hidden Main Instruction Symptom: The model responds to the background information instead of performing the task.

Cause: The actual request is buried inside paragraphs of context.

Fix: Place the main instruction in its own clearly visible line or section.

Category 2: Information Mistakes 2.1 Missing Context Symptom: Generic, "one-size-fits-all" answers, or recommendations that do not fit your situation.

Cause: The model does not know the audience, purpose, environment, or constraints (Lesson 6).

Example:

What's the best way to deploy my app? Fix: State the framework, scale, budget, team experience, and hosting constraints that change the answer.

2.2 Assumed Shared Knowledge Symptom: The model produces a format, style, or definition that differs from "the usual one".

Cause: The prompt refers to things only you know: "our standard format", "the usual tone", "the new policy".

Fix: Describe the format or include an example. Apply the new colleague test (Lesson 5).

2.3 Irrelevant Context Symptom: The response mentions details that have nothing to do with the question.

Cause: Background information was included "just in case", and the model treated it as relevant.

Fix: Keep only context that changes the correct answer.

2.4 Missing Versions or Dates Symptom: Code uses outdated syntax; time-based answers refer to the wrong period.

Cause: The prompt does not state software versions or the current date, so the model relies on assumptions from its training data.

Fix: State versions for technical tasks and provide the current date for anything time-dependent.

Category 3: Input Data Mistakes 3.1 No Boundary Between Instructions and Data Symptom: The model follows instructions found inside the data, or processes part of your instruction as content.

Cause: Data is pasted directly after the instruction without labels or delimiters.

Fix: Label the data and wrap it in delimiters such as ... (Lesson 7).

3.2 Describing Data Instead of Providing It Symptom: The model's solution does not match your actual code or document.

Cause: The prompt says "my function has a bug in the loop" instead of including the function and the error.

Fix: Include the exact code, the full error message, or the actual text.

3.3 Sending Noisy or Excessive Data Symptom: Answers include navigation text, email signatures, or irrelevant fields; costs are high.

Cause: Raw HTML, full email threads, or entire database records are sent without cleaning.

Fix: Extract and clean only the relevant content in code before building the prompt.

Category 4: Output Mistakes 4.1 Undefined Output Format Symptom: Length, structure, and style change from run to run.

Cause: The prompt specifies what to do but not what the result should look like (Lesson 8).

Fix: Define format, length, and structure explicitly, or show an example.

4.2 No Rule for Missing Information Symptom: The model invents a value, name, or date that is not in the input.

Cause: A field is required, but the prompt does not say what to do when the information does not exist.

Fix: Specify a fallback such as null, "Not stated", or "Not assigned in the notes."

4.3 Unwanted Extras Around the Answer Symptom: Responses start with "Sure! Here's..." or end with "Let me know if you need anything else", which breaks parsing or looks unprofessional.

Cause: Chat models add conversational text by default.

Fix: Request only the output, and name the extras to omit.

4.4 No Validation of Structured Output Symptom: Occasional crashes or bad data in production, even though testing looked fine.

Cause: Code assumes the model always returns valid JSON with correct values.

Fix: Parse, validate types and allowed values, and handle errors in code.

Category 5: Process Mistakes 5.1 Testing With One Input, Once Symptom: A prompt that "worked" fails after deployment.

Cause: It was tested on a single clean example, and only one response was checked. Because sampling introduces variation (Lesson 2), one good result proves little.

Fix: Test with a set of varied inputs, including difficult ones, and run important prompts more than once.

5.2 Changing Many Things at Once Symptom: After a revision, output improves in one way and worsens in another, and you cannot tell why.

Cause: Several parts of the prompt were changed together.

Fix: Change one thing at a time and compare results on the same inputs (Lesson 12).

5.3 No Record of Prompt Versions Symptom: Output quality drops and nobody knows which change caused it.

Cause: Prompts are edited directly in code or in a chat without history.

Fix: Store prompts in files under version control and note the reason for each change.

5.4 Over-Engineering From the Start Symptom: A very long prompt with many rules, some contradictory, and no clear improvement over a simpler version.

Cause: Every possible rule was added before seeing any actual problem.

Fix: Start simple and add rules only to fix observed failures (Lesson 10, Tip 1).

5.5 Copying "Magic" Prompts Without Understanding Symptom: A prompt copied from the internet works on its demo example but not on your data.

Cause: The prompt was designed for someone else's task, model, and inputs.

Fix: Understand why each part of a prompt exists, then adapt and test it for your own task.

Category 6: Reliability and Safety Mistakes 6.1 Treating Output as Verified Fact Symptom: Incorrect facts, invented references, or broken code reach users.

Cause: Fluent, confident output is assumed to be correct.

Fix: Verify important facts against reliable sources, test generated code, and keep human review for high-impact content.

6.2 Using the Model for Exact Computation Symptom: Small errors in totals, counts, dates, or character lengths.

Cause: Models predict tokens; they do not run calculations the way code does.

Fix: Compute exact values in code and use the model to interpret or explain them.

6.3 Relying on a Persona Instead of Information Symptom: Answers sound expert but contain generic or inaccurate content.

Cause: The prompt says "You are a world-class expert" but provides no facts, context, or requirements.

Fix: Use roles to set perspective and still provide all information the task needs.

6.4 Ignoring Prompt Injection Symptom: User-supplied text changes the model's behavior, such as overriding rules or revealing instructions.

Cause: Untrusted input is mixed directly with instructions, and the application trusts the model's output completely.

Fix: Separate instructions from data, tell the model that the data is content to process, limit what the model's output can trigger, and validate actions in code. This topic is covered in the Prompt Safety section.

6.5 Including Sensitive Data Unnecessarily Symptom: Personal or confidential data appears in prompts, logs, or outputs.

Cause: Entire records are sent when the task needs only a few fields.

Fix: Send only the data the task requires. Never include passwords, API keys, or full payment details.

Diagnosing a Bad Response When a response is wrong, the symptom usually points to the category of mistake. Use this table to find where to look first.

Symptom in the Output Most Likely Mistake Where to Look Answers a different question Vague task (1.1) or hidden instruction (1.4) The instruction verb and its position Generic, not specific to you Missing context (2.1) The situation, audience, and constraints Uses a different format/style than "usual" Assumed shared knowledge (2.2) Unstated conventions Mentions irrelevant details Irrelevant context (2.3) Background information Outdated syntax or wrong time period Missing versions or dates (2.4) Technical environment and date Follows text inside the data No boundary (3.1) or injection (6.4) Delimiters and data handling Invents names, dates, or values No missing-information rule (4.2) Fallback instructions Format changes between runs Undefined format (4.1) Output specification Parts of the request skipped Too many tasks (1.2) Number of actions per instruction Inconsistent decisions between runs Conflicting instructions (1.3) Competing requirements Small numerical errors Exact computation (6.2) Move calculations into code Worked Example: Fixing a Flawed Prompt The Scenario An ed-tech platform wants to automatically generate a short feedback message for each student submission.

The Flawed Prompt You are the best teacher in the world. Look at the student's code and give good feedback. Be detailed but short. Use our usual feedback style. def avg(nums): return sum(nums)/len(nums) Also give a score. Diagnosis Problem in the Prompt Mistake Likely Effect the best teacher in the world Persona instead of information (6.3) Sounds authoritative but adds no real guidance give good feedback Vague task (1.1) Unclear what to evaluate: correctness, style, edge cases? Be detailed but short Conflicting instructions (1.3) Length varies between runs our usual feedback style Assumed shared knowledge (2.2) The model invents a style Code pasted without labels No boundary (3.1) Code and instructions run together No assignment description Missing context (2.1) The model does not know what the code should do or for what level Also give a score Undefined output (4.1) Score scale unknown: out of 5, 10, 100, or a letter grade? No rule for empty or unrelated submissions No missing-information rule (4.2) Unpredictable output for invalid submissions The Corrected Prompt

Context

You give feedback on beginner Python exercises for students in their first month of programming. Feedback should help them learn, not only judge.

Assignment

Write a function avg(nums) that returns the average of a list of numbers.

Task

Review the student's submission in . Evaluate:

1. Correctness for normal input
2. Handling of edge cases (for example, an empty list)
3. Readability

Feedback Style

• Start with one thing the student did well.
• Then explain the most important improvement, with a short code example.
• Use simple language and an encouraging tone.
• Maximum 120 words for the feedback text.

Output Format

Feedback: Score:

If the submission is empty or not Python code, reply only: Feedback: Submission could not be reviewed. Score: 0

def avg(nums): return sum(nums)/len(nums) Possible output:

Feedback: Nice work — your function is short and correctly calculates the average using sum() and len(). The main improvement is handling an empty list: avg([]) raises a ZeroDivisionError. Check for this case first, for example:

def avg(nums): if not nums: return 0 return sum(nums) / len(nums)

Depending on your program, raising a clear error may be better than returning 0. Score: 4 Explanation of the Fix Context replaces the persona with useful information: the students are beginners, and the purpose is learning. Assignment tells the model what the code is supposed to do, so correctness can be judged. Task lists exactly what to evaluate, which naturally leads the model to the empty-list problem. Feedback Style replaces "our usual style" with concrete rules and resolves "detailed but short" with a specific word limit. Output Format defines the score scale and a parseable structure. Fallback defines behavior for invalid submissions. Delimiters separate the code from the instructions. The feedback is now specific, consistent in structure, and directly useful to the student. The output includes a balanced note that returning 0 is one option and raising an error is another, which is accurate: the right choice depends on how the function is used.

A Pre-Use Checklist Before using a prompt for anything important, check:

Task

Is the main instruction clear, with a precise verb? Is each task separate and visible? Are there any conflicting requirements? Information

Does the model know the audience, purpose, and relevant constraints? Are versions and dates included where they matter? Have unstated conventions been written down? Data

Is the input labeled and delimited? Has irrelevant or sensitive data been removed? Output

Are format, length, and structure defined? Is there a rule for missing or invalid input? Is structured output validated in code? Process

Has the prompt been tested with varied and difficult inputs? Has it been run more than once? Is the prompt version recorded? Try It Yourself Exercise 1: Diagnose the Prompt Identify at least five mistakes in this prompt, name their categories, and write a corrected version:

You're an expert marketer. Write something for our new course launch that is engaging and professional and casual. Use the normal format. Course: Django for Beginners starts soon, price is good. Make it perfect. Exercise 2: Symptom to Cause For each symptom, name the most likely mistake and the fix:

A summarizer sometimes includes the email signature in its summary. A date extractor returns "2024" for meetings described as "next Friday". A JSON extractor occasionally returns text before the JSON object. A support bot answered a question about refunds with a policy your company does not have. Exercise 3: Audit One of Your Own Prompts Choose a prompt you have used recently. Go through the pre-use checklist, fix every unchecked item, and compare the outputs of the old and new versions on three different inputs.