You send a message to a friend: "send the file". They send the wrong one. You send a different message: "send me the Excel file Priya shared yesterday about the hostel fees". Correct file, first time. Nothing about your friend changed between those two messages — you just stopped making them guess.
That is the whole idea, and it survives all the way up to production systems. This lesson is about why it works, what the job actually involves, and why a skill that sounds like "typing nicely" turns out to have rules.
A two-minute experiment
Open any AI chat and type this:
Write about climate change.You will get something like five confident paragraphs, encyclopedia tone, no particular reader in mind. Perfectly fine. Completely unusable for anything specific. Now try:
Write 3 short paragraphs about how climate change affects
farming in Maharashtra, for a Class 10 student. Use simple
English, one concrete example per paragraph, and end with
one thing a student could actually do.Same model. Same second. Radically better output — because the second message answered the questions the first one left open: how long, for whom, about what exactly, in what register, ending how.
💡 A useful way to feel this: for every prompt you write, ask "how many different reasonable answers would satisfy this?" If the answer is "hundreds", you're about to receive an average one.
Why wording matters at all
Here is the mechanism, in one sentence you can say in an interview: the model generates text that plausibly continues the text so far — and your prompt is that text.
So the prompt isn't a command sent to a program that then goes and does a task. The prompt is the beginning of a document, and the model writes the rest. "Write about climate change." is the opening of a million possible documents, so you get a blend of the commonest one. Add a reader, a length, a region and an ending, and you've cut that million down to a few dozen — all of which are roughly what you wanted.
If you have read the GenAI course lesson on how LLMs work, this is the same fact seen from the user's side. Prompting is not tricking the model. It is aiming it.
What the job actually is
In real work, "prompt engineering" means four activities, and only the first one is what beginners picture:
| Activity | What it looks like |
|---|---|
| Specifying | naming the task, the allowed values, the output shape, the edge-case behaviour |
| Supplying | putting the right facts in front of the model, and only those facts |
| Testing | running the prompt against a fixed set of real inputs and scoring the results |
| Defending | deciding what happens when input is hostile, empty, or nothing like you expected |
Lessons 2–5 are mostly specifying and supplying. Lesson 8 is supplying at scale. Lesson 9 is defending. Lesson 10 is testing. That's the map of this course.
Wait — so it isn't about magic words?
Mostly, no. You will find lists online: "add take a deep breath", "say this is very important for my career", "offer the model a tip". Some of these showed measurable effects on specific models at specific times. Almost none of them survive a model upgrade, and none of them are what a team relies on.
What survives is boring and structural: say what you want, supply what it needs, show the format, define the ambiguous word. If a phrase helps and you can measure that it helps, keep it. If you cannot measure it, you are collecting folklore.
🎯 Selection-round radar: "What is prompt engineering?" is asked constantly and answered weakly. Don't say "asking AI questions properly". Say: designing the input so the model reliably produces the required output — specifying the task, supplying the context, constraining the format, and evaluating the result across real inputs rather than one. The word reliably is what marks you out.
The loop you'll live in
Nobody writes the right prompt first. The working rhythm is:
- Write the obvious version.
- Run it on several real inputs, not one.
- Look at what failed and name the pattern in words.
- Change one thing that addresses that pattern.
- Re-run the same inputs and compare.
Step 4 matters more than it looks. Changing five things at once and seeing improvement teaches you nothing about which change caused it — and one of those five may be quietly making a different case worse. Lesson 10 turns this loop into something with numbers attached.
Is this skill dying?
You'll see the claim regularly, and there is something real behind it. Models did get better at forgiving vague instructions, and "Prompt Engineer" as a standalone job title has thinned out after its 2023 peak.
But look at what got harder rather than easier. Applications now assemble prompts from retrieved documents, conversation history and tool results. They run unattended on inputs nobody reviewed. They can take actions. Deciding what goes in front of the model, in what order, with what guardrails, and how you'd know if it regressed — that is more work than in 2023, not less.
The title is fading; the skill got absorbed into every AI role. Which is why interviewers ask about it without ever using the phrase.
Common mistakes
- Testing on one input, declaring victory, then discovering production is messier.
- Collecting "magic phrases" instead of specifying the task.
- Changing several things at once, so you never learn which one worked.
- Assuming a longer prompt is a better prompt — length without specificity just dilutes.
- Blaming the model for output that the prompt never actually asked for.
Quick recap
| Concept | One-liner |
|---|---|
| Why wording works | the prompt is the text being continued — precision narrows the plausible continuations |
| The definition | designing input so the model reliably produces the needed output |
| The four activities | specify, supply, test, defend |
| Magic words | model- and version-specific folklore; structure survives, tricks don't |
| The loop | write → run on several real inputs → name the failure → change one thing → re-run |
| The job title | fading; the skill is now assumed in every AI role |
Practice Zone — PYQs from real selection rounds
Six MCQs, then two prompts to fix by hand. Write your version before revealing — that is the exact task an interviewer sets.
Why does the wording of a prompt change the output so much?
Asked in
Which best describes prompt engineering as a professional skill in 2026?
Asked in
A prompt works perfectly in your testing and fails in production. The most likely reason is:
Asked in
Which change most reliably improves a weak prompt?
Asked in
What is the honest limit of prompt engineering?
Asked in
In production systems, prompts should be treated as:
Asked in
Hands-on tasks:
A teammate's prompt is: "Look at this customer feedback and tell me about it." List everything wrong with it, then rewrite it for a dashboard that displays sentiment and a one-line summary.
Asked in
For each complaint, say whether prompt engineering can fix it: 1) "The bot's answers are too long." 2) "It doesn't know our 2026 pricing." 3) "It sounds too casual for a bank." 4) "It invents policy numbers." 5) "It can't check order status."
Asked in
FAQ
Does a longer prompt always give a better answer?
No — and this is worth being precise about. What helps is specificity, and specificity often costs words, so good prompts are frequently longer. But padding, repetition and politeness add tokens without adding constraints, and with long inputs they actively hurt by burying the important lines in the middle (lesson 7).
Do I need to be polite to the model?
It costs a few tokens and changes little. Say "please" if you like the habit. Just don't mistake politeness for specification — "could you kindly summarise this nicely?" is still an unspecified request.
Will the same prompt work on ChatGPT, Claude and Gemini?
A well-structured prompt usually transfers, because clarity is model-independent. What doesn't transfer is anything tuned to one model's quirks — exact phrasings, tricks, and relying on a particular default style. Assume you'll re-check outputs after any model or version change.
Next lesson: the five slots every good prompt fills, one at a time — Lesson 2: Anatomy of a Prompt →