The Autocomplete Genius
The same model is brilliant for one person and useless for another. The difference is the prompt, and this course makes that difference deliberate.
Welcome to Prompt Engineering 🎛️
You have almost certainly used an AI model: to draft an email, explain an error message, or write a function. And you have almost certainly had both experiences: the answer that felt like magic, and the confident nonsense that wasted your afternoon.
Here's the uncomfortable truth: for the same task, on the same model, one person reliably gets the magic and another reliably gets the nonsense. The difference is what they put in. This course makes that difference deliberate: a skill you apply on purpose, not luck.
The journey ahead:
- Inside the model (this module): why prompts work at all
- Clear instructions and examples: the core craft
- Reasoning, system prompts, structured outputs, tools: production techniques
- Grounding, agents, security: prompting real systems
- Evals and the prompt lifecycle: proving your prompts work, like an engineer
No machine learning background is needed. A little Python appears in two modules, and every snippet is readable even if Python is not your language.
Start with the single most important fact about these models.
A large language model (LLM) is a program trained on a huge amount of text to do one thing: given some text, predict what plausibly comes next, one small chunk at a time.
Input: "The Eiffel Tower is located in"
Model: " Paris" (because that continuation is overwhelmingly likely)It is not looking the answer up in a database. It is not running a search. It learned patterns from billions of sentences, and it continues your text the way those patterns suggest.
When the continuation matches reality, the model looks brilliant. When a wrong continuation is statistically plausible, the model states it with exactly the same confidence. Keep this picture; it explains almost every strange behavior you will ever see.
Fundamentally, what is a language model doing when it answers your question?
- APredicting a plausible continuation of the text it was given, learned from patterns in training data
- BLooking up the answer in a database of verified facts
- CSearching the live internet and summarizing the results
- DRunning your question as code and returning the output
Here is the metaphor this whole course runs on.
The model is a brilliant intern on their first day. Every day.
- Brilliant: read more text than any human alive, writes fluently in fifty languages, knows every framework's documentation.
- First day: knows nothing about you, your company, your codebase, your customers, or what you said yesterday. Unless you tell them, in writing, right now.
Most bad prompts fail exactly the way a bad intern briefing fails. "Make the report better" gets you a shrug in both worlds. The intern isn't stupid; the briefing was empty.
Prompt engineering, at its core, is writing a great briefing for a brilliant intern with no context. Hold onto that; we will sharpen it into specific techniques from Module 2 onward.
You send a model exactly this, with no other context. What is the most likely reply?
Roses are red, violets are- AIt continues the pattern: "blue" (probably with more of the poem)
- BIt asks what you would like it to do with this text
- CIt refuses because the request is incomplete
- DIt returns an error because there is no question
One more idea before the recap: why does wording change the answer so much?
Because different setups make different continuations plausible. Watch the same request steer two different ways:
Prompt A: "List three risks of storing passwords in plain text."
Prompt B: "Explain why storing passwords in plain text was fine for our MVP."Prompt A pulls the model toward security literature. Prompt B pulls it toward justification, and the model will find justifications, because agreeable continuations of that framing exist in the training patterns.
Same model, same topic, opposite outputs. The prompt is not a search query; it is the setup that determines which continuation is plausible. Every technique you will learn (structure, examples, roles, grounding) is a way of controlling that setup.
Two prompts about the same decision. A: "List the main drawbacks of storing user sessions in localStorage." B: "Explain why storing user sessions in localStorage is a solid choice." What does this lesson predict about the answers?
A: "List the main drawbacks of storing sessions in localStorage."
B: "Explain why storing sessions in localStorage is a solid choice."- AEach gets a fluent answer supporting its own framing: A collects drawbacks, B collects justifications
- BBoth converge on the same balanced verdict, because the model knows the facts either way
- CB is refused for being a leading question
- DA fails: models cannot criticize a technology they were trained on
A teammate says: "The model told me our caching approach is correct, so it must be fine." Based on this lesson, what is the sharpest critique of that reasoning?
- AThe model produces plausible continuations, and a validation-seeking framing invites a plausible yes, not a verified one
- BModels are usually wrong, so the caching approach is probably broken
- CThe model cannot discuss caching because it never saw the codebase
- DThere is no critique; a confident model answer is strong evidence
- A large language model (LLM) predicts a plausible continuation of the text it is given, chunk by chunk. No database, no live search, no execution.
- Plausible is not the same as true, and the model sounds equally confident either way.
- The model is a brilliant intern on their first day, every day: enormous general knowledge, zero context about you unless you provide it.
- Your prompt is the setup that decides which continuations are plausible. Wording is steering.
- Confidence is not evidence. Engineering means testing, and that mindset arrives in full in Module 10.
Next: the model doesn't even see your words the way you wrote them. It reads tokens, and that explains some famous failures.