Twelve Words Changed Everything
I typed “write me a blog post about productivity” into GPT-4 and hit enter. What came back was 500 words of the blandest, most generic advice I’d ever read. Drink water. Make lists. Wake up early. It read like a motivational poster factory had gained sentience and lost its will to live.
Then I changed twelve words. Just twelve.
I added “for remote Indian developers who struggle with context-switching between client time zones.” Same topic. Same model. But the output? Night and day. Specific examples about IST-to-EST handoff routines. A trick for batching Slack replies before bed. A section on “async-first” standup formats I’d never even considered. From garbage to genuinely useful — all because I told the AI who I was writing for and what problem they actually had.
That’s prompt engineering in a nutshell. Not magic. Not some secret syntax. Just learning how to talk to a system that’s incredibly powerful but takes your words very, very literally.
Over the past two years, I’ve probably written 10,000+ prompts across GPT-4, Claude, Gemini, and a handful of open-source models. Some flopped spectacularly. Others produced work that made me wonder if I should just retire. Along the way, I’ve collected questions — from colleagues, from readers, from my own late-night frustrations. What follows are those questions, answered with everything I’ve learned.
“Wait, What Even Is Prompt Engineering? Is It Real?”
Fair question. When I first heard the term back in early 2023, I thought it was nonsense too. Prompt engineering? Sounds like someone slapped a fancy title on “asking a computer questions.” And in a sense, that’s exactly what it is. But here’s the thing — asking questions well is a skill. Always has been.
Think about it this way. You walk into a restaurant and say “give me food.” You’ll get something. Probably not what you wanted. Now say “I’d like a dosa with extra coconut chutney, no sambar, crispy not soft.” You’ll get exactly that. AI works the same way. Vague in, vague out.
Prompt engineering is just the practice of crafting your inputs so the AI gives you what you actually need instead of what it guesses you might want. No hacks involved. No cheat codes. Just clear, specific communication with a system that won’t read between the lines.
And yes, it’s real enough that companies are paying six-figure salaries for people who do it well. In 2025, Anthropic and OpenAI both published prompt engineering guides. Google DeepMind runs internal workshops on it. So no, it’s not going away anytime soon.
“My Prompts Keep Giving Me Generic Answers. What Am I Doing Wrong?”
Probably everything. Kidding. But probably one big thing: you’re being too vague. Let me show you what I mean.
# Bad zero-shot prompt
Summarize this article.
# Good zero-shot prompt
Summarize the following article in exactly 3 bullet points.
Each bullet should be one sentence, focusing on the key findings.
Write for a technical audience familiar with machine learning.
Article:
[article text here]See the difference? First prompt gives the AI zero constraints. How long should the summary be? What format? Who’s reading it? The AI doesn’t know, so it guesses. And its guesses tend toward the middle of the road — safe, bland, generic.
The second prompt nails down three things: format (3 bullet points, one sentence each), focus (key findings only), and audience (ML engineers, not beginners). That’s what we call a zero-shot prompt — you’re giving instructions without any examples. The AI relies entirely on its training to follow them. And when those instructions are specific enough, it does a surprisingly good job.
Here’s another one I use all the time for code generation:
# Zero-shot prompt for code generation
Write a Python function called `validate_email` that:
- Takes a single string parameter `email`
- Returns True if the email is valid, False otherwise
- Uses regex for validation
- Handles edge cases: empty strings, missing @ symbol, multiple @ symbols
- Includes a docstring with examples
- Does NOT use any external libraries beyond `re`Every line in that prompt eliminates an ambiguity. Without the edge cases line, the AI might skip them. Without the library restriction, it might pull in a third-party package you don’t want. Without the docstring requirement, you won’t get one. The AI won’t add things you didn’t ask for, and it won’t think about things you didn’t mention.
My rule of thumb: if you can imagine two different valid responses to your prompt, it’s too vague. Tighten it until only one interpretation makes sense.
“When Should I Use Examples in My Prompts?”
Great question, and the answer might surprise you. Examples aren’t just nice to have — they’re the single most powerful thing you can add to a prompt when the output needs to follow a specific pattern.
This technique is called few-shot prompting. Instead of describing what you want (which can get wordy and still leave room for misinterpretation), you show the AI what you want. Three to five examples usually does the trick.
I use this constantly for data extraction. Say I need to pull structured info from messy product descriptions:
# Few-shot prompt for data extraction
Extract structured data from product descriptions.
Example 1:
Input: "Apple MacBook Pro 16-inch with M3 Max chip, 36GB RAM, 1TB SSD. $3,499"
Output: {"name": "MacBook Pro 16-inch", "brand": "Apple", "processor": "M3 Max", "ram": "36GB", "storage": "1TB SSD", "price": 3499}
Example 2:
Input: "Samsung Galaxy S24 Ultra, Snapdragon 8 Gen 3, 12GB RAM, 512GB, priced at $1,299.99"
Output: {"name": "Galaxy S24 Ultra", "brand": "Samsung", "processor": "Snapdragon 8 Gen 3", "ram": "12GB", "storage": "512GB", "price": 1299.99}
Example 3:
Input: "Dell XPS 15 laptop featuring Intel Core i9-13900H, 32GB DDR5, 1TB NVMe for $1,899"
Output: {"name": "XPS 15", "brand": "Dell", "processor": "Intel Core i9-13900H", "ram": "32GB DDR5", "storage": "1TB NVMe", "price": 1899}
Now extract from:
Input: "Google Pixel 9 Pro with Tensor G4 chip, 16GB RAM, 256GB storage at $999"No amount of written instruction would communicate this as clearly as three examples do. Each one teaches the AI your naming conventions (strip “Apple” from the product name but keep “Galaxy”), your schema structure, and how to handle price variations (“$3,499” vs “priced at $1,299.99” vs “for $1,899”). The model picks up on all of it.
Few-shot prompting works beautifully for classification too. I built a support ticket router last year in Hyderabad that used nothing but a prompt like this:
# Few-shot classification
Classify support tickets by priority.
"My account is locked and I have a presentation in 10 minutes" -> URGENT
"How do I change my profile picture?" -> LOW
"Payment failed for my team's enterprise subscription renewal" -> HIGH
"The export button produces a corrupted file every time" -> MEDIUM
Classify: "All production dashboards are showing error 500 since 8am"Four examples. That’s it. The AI picked up on the urgency signals (time pressure = URGENT, money + team impact = HIGH, functional bug = MEDIUM, simple question = LOW) and correctly classified new tickets about 90% of the time. We refined it over a few weeks, but the core prompt barely changed.
When should you choose few-shot over zero-shot? Whenever the format matters more than the knowledge. If you need the AI to know something, zero-shot with detailed instructions works fine. If you need the AI to do something in a specific way, show it examples.
“How Do I Get the AI to Actually Think Instead of Just Guessing?”
This one changed how I use AI forever. Seriously.
By default, language models don’t “reason” the way you and I do. They predict the next word based on patterns. So when you ask a math question or a logic puzzle, they’ll sometimes jump straight to an answer — and get it wrong. Not because they can’t solve it, but because you didn’t give them room to work through it.
Enter chain of thought prompting. CoT for short. The idea is dead simple: tell the AI to show its work. Step by step. Out loud.
# Without chain of thought
A store has 45 apples. They sell 60% on Monday, then receive a shipment
of 30 on Tuesday. On Wednesday they sell 1/3 of what they have.
How many apples remain?
# With chain of thought
A store has 45 apples. They sell 60% on Monday, then receive a shipment
of 30 on Tuesday. On Wednesday they sell 1/3 of what they have.
How many apples remain?
Think through this step by step:
1. Start with the initial count
2. Calculate Monday's sales and remaining
3. Add Tuesday's shipment
4. Calculate Wednesday's sales and final count
Show your work for each step.Without the CoT instruction, GPT-4 gets this right maybe 70-80% of the time. With it? Close to 99%. And for harder problems — multi-step word problems, code debugging, legal reasoning — the gap widens dramatically.
I use chain of thought prompting for debugging more than anything else. Here’s a real example from a project I was working on in March 2026:
# Chain of thought for debugging
The following Python function should return the second largest
number in a list, but it has a bug. Find and fix it.
```python
def second_largest(numbers):
first = second = float('-inf')
for n in numbers:
if n > first:
second = first
first = n
elif n > second:
second = n
return second
```
Analyze this step by step:
1. Trace through the function with input [5, 5, 3, 1]
2. Track the values of `first` and `second` at each iteration
3. Identify where the logic fails
4. Explain the fixWhen I just asked “what’s wrong with this code?” without the step-by-step instruction, Claude gave me a vague answer about edge cases. When I added the tracing instructions, it walked through every iteration, found the exact bug (duplicate values getting treated as the second largest), and produced a clean fix. Same model, same code, wildly different quality of analysis.
A colleague of mine in Pune calls this “making the AI show its homework.” I think that’s perfect. You wouldn’t trust a student who just wrote the final answer on a math test. Why trust an AI that does the same thing?
“Can I Make the AI Pretend to Be an Expert? Does That Actually Help?”
Yes and yes. It’s called role prompting, and it’s not as silly as it sounds.
When you tell the AI “you are a senior security engineer,” you’re not just playing pretend. You’re activating a different region of the model’s training data. Different vocabulary. Different priorities. Different depth of analysis. A “security engineer” will flag SQL injection; a “junior developer” probably won’t.
I combine role prompting with structured output formats for my best results. Here’s one I’ve used dozens of times:
# Role + structured output prompt
You are a senior security engineer performing a code review.
Analyze the following code for security vulnerabilities.
For each vulnerability found, respond in this exact format:
### Vulnerability [number]
- **Severity**: CRITICAL | HIGH | MEDIUM | LOW
- **Type**: [CWE category]
- **Location**: [function/line]
- **Description**: [what the vulnerability is]
- **Impact**: [what an attacker could do]
- **Fix**: [specific code change to resolve it]
If no vulnerabilities are found, state "No vulnerabilities detected"
and explain what security measures are already in place.
Code to review:
```python
import sqlite3
def get_user(username):
conn = sqlite3.connect("app.db")
query = f"SELECT * FROM users WHERE username = '{username}'"
result = conn.execute(query).fetchone()
conn.close()
return result
```That f-string SQL query is a textbook SQL injection vulnerability. And when Claude reviews it in the “senior security engineer” role, it catches it instantly — CRITICAL severity, CWE-89, with a parameterized query fix. Without the role? The AI might mention the injection in passing but often buries it in a wall of general code review comments about error handling and docstrings.
The structured output format matters just as much as the role. By giving the AI a template, you guarantee consistency. I’ve fed outputs like this directly into Jira tickets. No reformatting needed. That’s the power of combining role and structure in one prompt.
“I Have a Really Complex Task. One Prompt Can’t Handle It. Now What?”
You chain them. And honestly, this is where prompt engineering stops being a neat trick and starts being actual engineering.
Two techniques here. First: self-consistency. Second: prompt chaining. Let me walk you through both.
Self-consistency means asking the AI to solve the same problem from multiple angles and then compare its own answers. It’s like getting three different consultants to independently evaluate your options and seeing where they agree:
# Self-consistency prompt
I need to decide on a database for a new application.
Requirements: 10M+ records, complex joins, ACID compliance,
horizontal scaling, and real-time analytics.
Approach this decision three different ways:
1. First, evaluate from a pure performance perspective
2. Then, evaluate from an operational complexity perspective
3. Finally, evaluate from a cost and ecosystem perspective
After all three analyses, identify where they agree and disagree.
Give your final recommendation based on the consensus.When I used this for a project last November, the three perspectives all pointed to PostgreSQL with a read replica setup — but disagreed on whether to add ClickHouse for the analytics layer. That disagreement was actually the most useful part. It highlighted a genuine trade-off I hadn’t fully thought through.
Prompt chaining is different. Instead of one mega-prompt, you break the task into steps and feed each step’s output into the next. This is how production AI applications actually work at companies like Anthropic and OpenAI. Not one giant prompt. A pipeline of focused ones.
# Step 1: Extract requirements
From this client email, extract all technical requirements
as a numbered list. Only include concrete, actionable requirements.
# Step 2: (feed Step 1 output here)
For each requirement, classify as: Must Have, Should Have, Nice to Have.
Consider dependencies between requirements.
# Step 3: (feed Step 2 output here)
Create a sprint plan for the Must Have items.
Estimate story points for each (1, 2, 3, 5, 8, 13).
Identify the critical path.Each step is small enough that the AI can nail it. Step 1 just extracts. Step 2 just classifies. Step 3 just plans. No step asks the model to do three things at once. And because each step gets the full context window focused on one job, the quality jumps noticeably compared to cramming everything into a single prompt.
I built a content pipeline at work using exactly this pattern. Step 1 generates an outline from a topic. Step 2 expands each outline point into paragraphs. Step 3 edits for tone and removes AI-sounding phrases. Step 4 adds SEO metadata. Four prompts, four passes, and the output is consistently better than anything a single prompt could produce. My editor confirmed she couldn’t tell the difference from human-written drafts after step 3.
“What Are the Biggest Mistakes People Make?”
I’ve seen hundreds of prompts from developers, content creators, and product managers. Here are the patterns that keep showing up.
Mistake 1: Assuming the AI knows what you know. You’ve been thinking about your project for weeks. The AI has zero context. It doesn’t know your codebase. It doesn’t know your audience. It doesn’t know what you tried yesterday that didn’t work. Every prompt should include enough context that a smart stranger could understand what you need.
Mistake 2: Asking for too many things at once. “Write a blog post, make it SEO-optimized, include three infographic descriptions, add social media captions, and create an email newsletter version.” That’s five separate tasks crammed into one prompt. The AI will attempt all of them and do none well. Split them up. One task per prompt, or use chaining.
Mistake 3: Not specifying the output format. Want JSON? Say so. Want bullet points? Say so. Want a table? Say so. Want exactly 200 words? Say so. The AI won’t choose the format you want by coincidence. It’ll choose whatever format it’s statistically most likely to produce given your input words.
Mistake 4: Giving up after one attempt. Prompt engineering is iterative. I rarely get the perfect output on the first try. Usually takes two or three rounds of refining. Maybe the tone was off. Maybe the output was too long. Maybe it missed an edge case. Tweak the prompt, run it again. It’s a conversation, not a vending machine.
Mistake 5: Ignoring temperature and system prompts. If you’re using the API (and you probably should be for anything serious), temperature controls randomness. Lower values (0.0 to 0.3) for factual/code tasks, higher (0.7 to 1.0) for creative work. System prompts set the AI’s baseline behavior and persist across the conversation. Most people never touch these and wonder why their outputs feel inconsistent.
“Does the Same Prompt Work Across Different AI Models?”
Sort of. But not really.
GPT-4 and Claude handle the same prompt differently. I’ve run identical prompts through both dozens of times and the results diverge in predictable ways. GPT-4 tends to be more verbose and eager to please — it’ll add things you didn’t ask for, which can be helpful or annoying depending on context. Claude tends to be more precise and conservative — it sticks closer to your instructions but might not volunteer useful extras.
Gemini is a different beast altogether. It’s strong on multimodal tasks (images, video, audio) but can be flakier on structured output formatting compared to GPT-4 or Claude. I’ve had prompts that produce perfect JSON from Claude but broken JSON from Gemini until I added explicit formatting instructions.
My advice: develop your prompts on whichever model you’ll deploy on. Don’t assume portability. If you’re switching models, budget time for prompt adaptation. Usually the changes are small — maybe 10-15% of the prompt needs tweaking — but they matter.
One pattern that works well across all models: being more explicit than you think you need to be. No model has ever complained that your instructions were too clear. None of them will say “you gave me too much context, I’m confused.” More detail always helps, or at worst, gets ignored harmlessly.
“How Do I Know If I’m Getting Better at This?”
Track your prompts. Seriously. I keep a Notion doc with prompts that worked well, organized by task type. When I need to do something similar, I don’t start from scratch. I adapt a proven prompt.
You’ll know you’re improving when three things happen. First, your first-attempt outputs start requiring fewer edits. Second, you can look at a bad output and immediately diagnose which part of the prompt caused the issue. Third, you start thinking in terms of prompting techniques — “this needs few-shot” or “I should chain this into two steps” — before you even open the AI tool.
Some benchmarks from my own experience. In January 2025, maybe one in five of my prompts produced usable output on the first try. By December 2025, it was closer to three in five. Now in April 2026, I’d say four in five. The improvement isn’t because AI models got dramatically better in that window (they did, some, but not 4x better). It’s because I got better at asking.
I’ve also noticed something unexpected. Getting good at prompt engineering made me a better communicator overall. My code review comments got clearer. My emails got shorter and more precise. My technical specs improved. Turns out, learning to remove ambiguity for a machine teaches you to remove ambiguity for humans too.
“So What’s the One Thing I Should Remember?”
If you forget every prompting technique in this guide — zero-shot, few-shot, chain of thought, role prompting, chaining, self-consistency — remember this one principle:
Specificity is everything.
Who is the audience? What format do you want? What constraints exist? What should the AI not do? What edge cases matter? How long should the response be? What tone? What depth?
Every ambiguity you leave in a prompt is a coin flip. Sometimes the AI guesses right. Sometimes it doesn’t. Your job as the person writing the prompt is to remove every coin flip you can. Turn guesses into guarantees. Turn “probably what I meant” into “exactly what I said.”
AI isn’t going to get worse at following instructions. It’s only going to get better. The people who learn to give clear, specific, well-structured instructions today aren’t just getting better AI outputs tomorrow — they’re building a skill that compounds every single time a new model drops.
Twelve words. That’s all it took to go from useless to useful. Imagine what you could do with twenty.
