This is the final module of Unit 2 — and the most practical one. You now have three modules of prompt engineering theory behind you. This module is about what goes wrong when you apply it, and how to fix it fast.
Every prompt that fails does so for a diagnosable reason. Once you learn to recognise the patterns, you will spend less time rewriting prompts from scratch and more time refining them precisely. The 10 mistakes in this module account for the vast majority of poor AI outputs that Indian students and IT professionals experience.
The core principle of this module: A bad output is almost never the AI's fault. It is a specification problem — something was missing, ambiguous, or contradictory in the prompt. Your job is to diagnose which component failed and fix that specific component.
Mistake 1 — Too vague, no task verb
The most frequent mistake: stating a topic instead of a task. The model does not know if you want a summary, a tutorial, a comparison, a list, an essay, or code. It guesses — and guesses wrong about half the time.
✗ NO TASK VERB
machine learning in Python
✓ CLEAR TASK VERB
Write a beginner-friendly tutorial on training a linear regression model in Python using scikit-learn. Include code with comments.
Fix: Start every prompt with an action verb — write, explain, compare, list, debug, summarise, translate, review, generate, analyse. One verb, one task.
Mistake 2 — No audience specified
Without an audience, the model picks a default — usually a vague "educated adult." For students, this means explanations that are too advanced. For non-technical managers, too technical. Specifying the audience is the single fastest way to improve output quality.
✗ NO AUDIENCE
Explain recursion in Python.
✓ AUDIENCE SPECIFIED
Explain recursion in Python to a 2nd-year BTech CSE student who understands loops and functions but has never written a recursive function. Use a simple real-world analogy first, then a code example.
Fix: Add "for a [role + level]" to every explanation or writing task. "For a final-year ECE student", "for a non-technical HR manager", "for a junior developer joining my team."
Mistake 3 — Missing context
The most common assumption mistake: the model does not know who you are, what your project is, what constraints you have, or what has already been tried. Without context, it fills in the gaps — and fills them with generic content that does not fit your situation.
✗ NO CONTEXT
Write an email about the project delay.
✓ CONTEXT PROVIDED
Write an email to my project manager at TCS.
Context: The backend API integration is delayed by 3 days because the third-party vendor has not shared their documentation despite two reminders. The original deadline was Friday. The delay affects only the payment module, not the entire project.
Tone: Professional and factual. Do not over-apologise. Propose a revised timeline.
Fix: Before writing a prompt for any professional task, ask yourself: "What would I tell a new colleague before asking them to do this?" Paste that into your prompt as context.
Without a format instruction, the model defaults to its training average — usually long paragraphs with bold headings. If you wanted a table, bullet points, or a short paragraph, you will have to ask again. Specifying format upfront saves an entire follow-up prompt.
✗ NO FORMAT
Compare Zerodha and Upstox for a beginner investor.
✓ FORMAT SPECIFIED
Compare Zerodha and Upstox for a beginner investor in India.
Format: A table with these columns — Feature | Zerodha | Upstox.
Rows: Account opening fee, Brokerage, App usability, Research tools, Customer support.
After the table, add 2 sentences on which is better for a first-time investor and why.
Fix: Always specify format for outputs you will use directly — tables, bullet lists, numbered steps, code blocks, JSON, plain paragraphs, word count. If you do not specify, you are choosing "surprise me."
Mistake 5 — Multiple tasks in one prompt
Packing multiple unrelated tasks into one prompt forces the model to switch contexts repeatedly. Each task gets a fraction of the attention it deserves. The output is broad and shallow when you needed deep and specific.
✗ MULTIPLE TASKS
Explain neural networks, write me a Python implementation, list the top 5 applications in India, and suggest how I can learn this in 30 days.
✓ ONE TASK PER PROMPT
Prompt 1: Explain neural networks in plain language for a 3rd-year ECE student. Use an analogy. Under 200 words.
[After reading the answer:]
Prompt 2: Show me a minimal Python implementation of a feedforward neural network using NumPy only. No frameworks.
Fix: One task per prompt. Use the same conversation thread — each response builds on the last. Sequential prompts in one conversation produce far better results than one mega-prompt.
Mistake 6 — Accepting the first output
The first output is a starting point, not a final deliverable. Most AI outputs need one or two refinement passes to reach high quality. Accepting first outputs and blaming the tool is the most common mistake experienced users make.
✗ ACCEPTING FIRST OUTPUT
[reads the output, copies it, submits it]
Result: generic, AI-sounding, not quite right.
✓ REFINEMENT PROMPTS
Follow-up 1: “Make it more concise — cut to under 150 words.”
Follow-up 2: “Replace the generic opening line with something specific to Indian IT.”
Follow-up 3: “The tone is too formal. Rewrite the second paragraph to sound like a person, not a press release."
Fix: After every first output, ask yourself: what is one specific thing that could be better? Write one targeted follow-up prompt. Two iterations of this produces output that is noticeably better than the first draft.
Mistake 7 — Not separating generation from verification
Models make silent mistakes — missed constraints, broken logic, unsupported claims, incorrect code — that are not flagged as errors. The output looks correct but is not. The fix is a two-pass approach: generate first, verify separately.
✗ ONE-PASS PROMPT
Write a Python function that reads a CSV file and returns the top 5 rows by sales value.
✓ TWO-PASS PROMPT
Pass 1: Write a Python function that reads a CSV file and returns the top 5 rows by sales value. The CSV has columns: date, product, region, sales.
Pass 2 (new prompt): Review the code you just wrote. Check for: edge cases (empty CSV, missing column), error handling, and whether the output is a DataFrame or a list. Flag any issues.
Fix: For any important output — code, analysis, a document you will send to someone — use a second prompt to review and verify. Ask the model to check its own work against specific criteria. It catches its own mistakes surprisingly well when asked explicitly.
Mistake 8 — Wrong technique for the task
After learning techniques in Unit 2, a common mistake is over-applying them — adding few-shot examples when zero-shot is enough, or skipping chain-of-thought on a task that clearly needs step-by-step reasoning. Also: applying explicit CoT reasoning prompts to newer reasoning models that have it built in — this can actually interfere with their reasoning process.
✗ WRONG TECHNIQUE
Using few-shot with 3 examples to ask: "What is the capital of Maharashtra?"
Or: Adding “think step by step” to a reasoning model (o1, Gemini Thinking) — these models already reason internally; the instruction is redundant or disruptive.
✓ RIGHT TECHNIQUE
Simple factual question → zero-shot. No examples needed.
Complex analysis or multi-step problem → CoT on standard models (ChatGPT, Claude Sonnet, Gemini Pro).
Style-sensitive output → few-shot. Provide 1 example.
Reasoning models (o1, Gemini Thinking) → direct instructions. Skip explicit CoT triggers.
Fix: Match technique to task. Zero-shot first, always. Add few-shot only for style/format tasks. Add CoT only for multi-step reasoning on standard models. The simpler the better.
Mistake 9 — Generic domain language
A prompt about "system performance" without specifying whether you mean database performance, network performance, or microcontroller performance will get a generic answer that may not apply to your field. Domain-specific vocabulary in your prompt produces domain-specific output.
✗ NO DOMAIN
How do I improve system performance?
✓ DOMAIN SPECIFIED
How do I improve query performance in a Django REST API backed by PostgreSQL, handling 50,000 requests per day? Focus on database indexing and query optimisation. We are on AWS RDS.
Fix: Include your specific technology stack, industry, or subject area in every technical prompt. The more specific your domain language, the more precise the output. "Indian retail banking", "embedded systems on ARM Cortex-M4", "BTech EC curriculum" — specificity beats generality every time.
Mistake 10 — Outdated context in long conversations
In a long conversation, the model can gradually lose track of your original constraints, role, or goal — especially when the context window fills up and older instructions get compressed. You notice this when the model starts contradicting earlier instructions or reverting to generic style.
✗ CONTEXT DRIFT
[After 15 exchanges, the model has forgotten it was supposed to be a strict interviewer and starts giving away answers, or has forgotten the word limit it was given 10 messages ago]
✓ CONTEXT RESET
Quick reminder of our constraints: You are a strict technical interviewer. Do not give away answers. Maximum 3 sentences per response. We are at question 4 of 10.
Continue from where we left off.
Fix: For tasks spanning more than 8–10 exchanges, periodically restate the key constraints in a brief "reminder" prompt. Also: start a fresh conversation for a genuinely new task rather than continuing an old one — stale context from previous tasks can corrupt new outputs.
Quick diagnosis guide — what symptom means what
IF THE OUTPUT IS... → THE MISSING COMPONENT IS...
Too generic, could apply to anyone
→
Missing context (who you are, what this is for) and audience
Wrong format (paragraphs when you wanted a table, or vice versa)
→
Missing format specification — add it explicitly
Too long, too detailed, goes off on tangents
→
Missing constraints — add word count, "be concise", or scope limits
Too shallow, not specific enough to your situation
→
Missing domain language and context — be more specific about your tech stack, industry, and goal
Wrong tone (too formal, too casual, too technical)
→
Missing role and audience specification — add both
Logically wrong or inconsistent on a complex problem
→
Missing chain-of-thought — add "think step by step" or numbered reasoning steps
Correct but feels AI-sounding, not your style
→
Missing few-shot examples of your preferred style — add 1–2 examples
Addresses the wrong task entirely
→
Missing clear task verb — rewrite the first sentence with a specific action verb
The pre-submit prompt checklist
Print this. Stick it next to your monitor. Use it for the next two weeks until it becomes instinctive.
FOUNDATION
Does my prompt start with a clear action verb?write / explain / compare / list / debug / summarise / review / generate
Have I specified who will read or use this output?"for a 3rd-year BTech student" / "for my project manager at Infosys"
Have I provided enough context for this specific situation?background, constraints, what has already been tried, what the output is for
OUTPUT CONTROL
Have I specified the output format?table / bullet list / code block / numbered steps / plain paragraphs / word count
Have I added constraints on what NOT to include?word limits / topics to exclude / tools to avoid / tone restrictions
Is this one task, or have I bundled multiple tasks?if multiple → split into sequential prompts
TECHNIQUE
Does the style/format matter enough to add a few-shot example?if yes → provide 1 example before the task
Does this involve multi-step reasoning or analysis?if yes → add "think step by step" or numbered reasoning steps
AFTER THE OUTPUT
Have I verified every specific fact, citation, and number independently?especially for professional work — do not skip this
Is there one specific thing I can improve with a follow-up prompt?conciseness / tone / a specific section / missing detail
Unit 2 — What you have learned
This is the last module of Unit 2. Here is a quick summary of what you now know:
MODULE 2.1
Anatomy of a Good Prompt
Six components: role, task, context, format, examples, constraints. A prompt is a specification. Structure beats length.
MODULE 2.2
Zero-Shot, Few-Shot, CoT
Start with zero-shot. Add few-shot for style. Add CoT for multi-step reasoning. Combine all three for complex tasks.
MODULE 2.3
Role Prompting and Personas
Role changes style and framing, not knowledge. Strong roles have 4 elements. Audience specification is as powerful as the role itself.
MODULE 2.4
Common Mistakes and Fixes
10 diagnosable patterns. Bad output = missing specification. Use the pre-submit checklist until the habits are automatic.
Unit 3 is where all of this becomes practical for your actual job. You will apply these techniques to real developer, analyst, and manager workflows — with specific examples from Indian IT contexts.
The three things to remember
KEY TAKEAWAYS — MODULE 2.4
- Bad output is a specification problem, not an AI problem — every poor output has a diagnosable missing component. Use the symptom-to-fix diagnosis guide to identify it and the pre-submit checklist to prevent it.
- First outputs are starting points — one targeted follow-up prompt improves output quality by 30–40%. Accepting first outputs is the most common mistake experienced users make.
- Use a two-pass approach for anything important — generate first, then use a separate prompt to verify. Ask the model to check its own output against specific criteria. It catches its own mistakes well when asked explicitly.
This is the Unit 2 capstone assignment. It applies everything from all four modules.
- Find 3 prompts you have written in the past that gave you a disappointing output — or write 3 new weak prompts from scratch. Use real tasks you actually need to complete.
- Diagnose each prompt using the symptom-to-fix guide in this module. Identify exactly which component was missing or wrong.
- Rewrite each prompt applying the full Unit 2 toolkit:
- Six components from Module 2.1 — role, task, context, format, examples, constraints
- Correct technique from Module 2.2 — zero-shot, few-shot, or CoT as appropriate
- Role and audience from Module 2.3 if relevant
- Test each rewritten prompt and note the output quality difference.
- Add these to your AI Learning Journal under "Prompt Rewrites — Unit 2" with a one-line note on what the most impactful change was for each.
When you complete this assignment, you have finished Unit 2. You now have the core prompt engineering skills needed for Unit 3 — where you will apply these techniques directly to developer, analyst, and manager workflows in Indian IT contexts.
Sources and references
| Claim | Source |
|---|
| Goldilocks principle — too vague vs too specific in prompts | Reintech.io Common Prompt Engineering Mistakes, February 2026 |
| Two-pass approach: generate then verify; reflection pattern | Medium — Prompt Engineering Basics 2026, January 2026 |
| Do not use explicit CoT triggers with reasoning models (o1, Gemini Thinking) — can interfere | ODSC Medium — Beyond Prompt and Pray, April 2025; Thomas Wiegold Blog February 2026 |
| Domain expertise + prompt engineering is more valuable than generic prompting | ODSC Medium — Beyond Prompt and Pray, April 2025 |
| One strong few-shot example beats three mediocre ones | Medium — Prompt Engineering Basics 2026, January 2026 |
| Structure beats length — prompt engineering in 2026 is writing clearer specs | promptbuilder.cc Prompt Engineering Best Practices 2026 |
| Most common mistake is assuming the AI has context it does not have | Treyworks Common Prompt Engineering Mistakes 2026 |