In September 1956, a researcher at MIT named Joseph Weizenbaum began building a program he called ELIZA. Finished in 1966, it could hold a conversation — or appear to. Secretaries who tested it reportedly asked Weizenbaum to leave the room so they could speak to it privately. They knew it was a program. They spoke to it anyway as though it understood them. Weizenbaum was disturbed. The illusion of comprehension, he found, required almost nothing from the machine and almost everything from the human.
In November 2022, Anthropic released Claude, and OpenAI released ChatGPT to the public. Within two months, over a hundred million people were talking to large language models. Analysts at Goldman Sachs estimated in March 2023 that AI could affect 300 million jobs. The difference from ELIZA was not just scale — it was that these systems actually produced useful output, but only when the person writing to them understood how to ask. Early users discovered fast that vague requests produced vague answers, and frustration often followed a system that was, technically, doing exactly what it was told.
This course teaches you to close that gap — between what you type and what you actually need. It is not a course about AI in the abstract. It is about Claude specifically: how it processes instructions, why context changes everything, where it pushes back, and how to build prompts that consistently produce work you can use. By the end of four lessons, you will have a practical, transferable framework for getting reliable results — not luck.
If you finish every module, here's who you become:
A features editor at a mid-sized newspaper, Dana Nguyen, was among the first in her building to get access to Claude via the API. She wanted a 500-word draft summarizing a city council vote on zoning reform. She typed: "Write me something about the zoning vote." Claude produced 500 words. They were fluent, well-structured, and entirely fabricated — specific councillors named, specific vote tallies invented, a quote from a alderman who said nothing of the kind. Dana had given Claude no facts. Claude, trained to be helpful and to produce complete-seeming output, filled the vacuum with plausible-sounding content. The problem was not Claude's honesty. The problem was that Dana's instruction gave Claude nothing to work with except genre conventions. She learned the lesson most productive users learn in their first week: Claude does not know what you know. It only knows what you tell it.
Claude is a large language model. When it receives your message, it does not "understand" in the way a colleague understands — it predicts the most contextually appropriate continuation of the text you have provided, given everything it learned during training. This is not a limitation to apologize for; it is a precise description of a powerful process. But it means that the quality of Claude's output is structurally dependent on the quality of your input.
Think of it this way: you are not giving Claude a task and walking away. You are providing the entire context within which Claude operates. The model cannot ask a clarifying question in most interfaces unless you invite it to. It cannot look up your company's style guide unless you paste it in. It cannot know that you wanted a formal tone unless you say so. Every gap in your instruction is a place where Claude will make an assumption — and those assumptions are based on statistical patterns from training data, not on your actual situation.
The practical consequence: vague prompts produce statistically average responses. Claude will give you what most people probably wanted when they wrote something similar. That may be fine for routine tasks. For anything specific, nuanced, or high-stakes, it will almost always miss.
In a 2023 survey by the consulting firm Accenture, professionals who rated AI "not useful" were asked what they had typed. In over 70% of cases, the prompt was fewer than 15 words. Professionals who rated AI "very useful" averaged 47 words per initial prompt and consistently included context about purpose, audience, and constraints.
Through extensive use across thousands of professionals, three categories of missing information reliably produce poor output:
These three elements — purpose, constraints, and source material — form the foundation of every effective prompt in this course. Lesson 2 will build them into a formal framework. Lessons 3 and 4 will show you how to use iteration and role-framing to push output quality further.
Claude is not a mind reader and is not trying to be. It is a very fast, very capable text-completion engine. The professional who treats it that way — providing the information a capable human assistant would need — consistently outperforms the professional who treats it as an oracle.
Weak prompt: "Summarize this for me."
Result: A generic paragraph with no understanding of audience, purpose, or length.
Strong prompt: "Here is a 3,000-word academic paper on urban heat islands [paste text]. Summarize the key findings in three bullet points, each under 30 words, for a Twitter thread aimed at city planners. Avoid jargon. Do not invent statistics not present in the paper."
Result: Targeted, usable, accurate output on the first try.
The strong prompt is longer. It takes 45 seconds to write. It saves the 10-minute revision cycle the weak prompt almost always triggers. This is the core trade-off this course asks you to internalize: invest in the front end, save on the back end.
In this lab you will practice the core skill of Lesson 1: providing purpose, constraints, and source material. Start by sending a weak prompt — just a few words — and observe what Claude produces. Then revise it using all three elements. Compare the results. Finally, ask Claude to explain what was missing from your first attempt.
When Lena Hartmann, a contracts paralegal at a mid-sized London firm, first used Claude to help draft non-disclosure agreement summaries, she was disappointed. The output was generic — the kind of boilerplate you could find in any template. She escalated her frustration to a senior associate, Rohan Desai, who had been quietly building what he called a "prompt template" for the team. Rohan's version included five elements in a fixed order: the role Claude should play, the document being worked on (pasted in full), the specific output requested, the format required, and a list of things to explicitly avoid. The difference was immediate. Lena's single-line prompts were producing generic text; Rohan's structured template was producing draft summaries that needed only minor edits before going to clients. The firm adopted his template as standard practice within six weeks — a real case of informal prompt engineering creating measurable workflow improvement before "prompt engineering" had a widely agreed definition.
Every high-performing prompt can be broken into five elements. Not all five are required for every task — but knowing each one helps you decide which to include and which to skip.
Here is how the five elements combine in practice, using Rohan Desai's legal context:
Role: "You are a paralegal with ten years' experience summarizing commercial contracts for non-lawyer clients."
Context: "The document below is a mutual non-disclosure agreement between two UK technology companies."
Task: "Summarize the key obligations of each party in plain English."
Format: "Use two short sections: 'Party A Obligations' and 'Party B Obligations.' Each section should have three to five bullet points. Total length: under 200 words."
Constraints: "Do not include legal advice, do not quote directly from the contract, and do not use the phrase 'it is important to note.'"
These five instructions take about 90 seconds to write and produce output that requires five minutes of review rather than thirty minutes of rewriting.
Most users skip the Format and Constraints elements entirely. Format omission forces Claude into its default output style, which is often too long and too generic. Constraint omission means Claude may include exactly what you didn't want — legalese, clichés, off-brand language — without knowing you objected to it.
The five-element framework is not a mandatory checklist for every interaction. For simple, low-stakes tasks — "fix the grammar in this sentence" — a one-line prompt is appropriate. The framework earns its cost when the task has any of these properties: multiple constraints, a specific audience, a defined length or format, or real consequences for errors. The more of those properties apply, the more completely you should deploy the framework.
A practical heuristic from the Anthropic documentation team (published in their public usage guides in late 2023): if you would give a detailed brief to a human writer, give a detailed brief to Claude. The same professional standards that apply to human handoffs apply to AI handoffs. The difference is that Claude will not push back if the brief is thin — it will simply produce something thin in return.
Choose any real work task you currently handle — a report, a client email, a summary, a proposal section. Build a prompt using all five elements: Role, Context, Task, Format, and Constraints. Send it, then ask Claude to evaluate the prompt itself: which elements were strong, which were weak, and what one addition would most improve it.
The product marketing team at a Berlin-based software startup was using Claude to draft feature announcement blog posts. Mia Schreiber, the content lead, noticed a pattern: her teammates sent one message, got a draft, judged it inadequate, and concluded that Claude wasn't useful for serious writing. Meanwhile, Mia was consistently producing polished posts. When asked how, she showed her process. Her first message was always a structured prompt producing a rough draft. The second message was invariably a specific critique: "The second paragraph buries the lead. Rewrite it so the primary benefit appears in the first sentence." A third message often followed: "Good. Now make the tone 20% less formal — we are talking to developers, not executives." By message four, Mia typically had a post ready for final review. Her teammates were stopping at message one. The lesson was so consistent that the startup made Mia's three-message structure a documented internal process — what they called the Draft-Critique-Tune loop.
Claude does not forget previous messages in a conversation. Every message you send is added to the context window — the running record of the entire conversation that Claude uses to generate each response. This means that every piece of information, every constraint, every correction you add in message two or three is available to Claude when producing message three or four.
This has a practical implication many users miss: you do not need to repeat your full prompt in every message. You established the role, context, and constraints in message one. In message two, you can give precise, targeted feedback. Claude will apply it within the framework you already built. The conversation compounds — each message builds on all previous ones.
The counter-intuitive insight is this: the first message should often be intentionally incomplete. Produce a draft. See what Claude defaults to. Then correct precisely. Trying to specify everything upfront sometimes takes longer and produces less targeted output than a structured two-message approach: rough prompt → evaluate output → precise correction.
Claude's context window is large — the Claude 3 family supports between 100,000 and 200,000 tokens, roughly 75,000–150,000 words. For normal professional tasks, you will almost never hit this limit. But for very long projects, if you notice Claude beginning to lose track of early instructions, starting a fresh conversation with a compressed summary is more effective than continuing an extremely long thread.
Mia Schreiber's three-message structure generalizes across almost any writing task. Here is the pattern with professional examples:
Three messages for complex writing tasks is a practical ceiling in most cases. If you find yourself at message six still significantly rewriting output, the original prompt probably needs to be rebuilt from scratch.
The quality of Claude's revision depends entirely on the quality of your critique. Here are four specific techniques for writing critique messages that produce targeted improvements:
Quote the problem: If a specific phrase is wrong, quote it. "Replace 'leverage synergies' with plain language describing what actually happens" is more actionable than "avoid jargon."
Name the fix, not just the problem: "The tone is too formal" gives Claude latitude to interpret "less formal" in many ways. "The tone is too formal — shift from passive voice to first-person active, and replace any word over three syllables with a shorter synonym" gives precise direction.
Confirm what to keep: If most of the output is good, say so. "Keep the second and third paragraphs unchanged; rewrite the opening paragraph only." This prevents Claude from reimagining the entire piece when you only wanted a targeted fix.
Use comparison framing: "This currently reads like a legal brief. Rewrite it to read like a column in The Economist" gives Claude a concrete reference point that often produces more targeted results than abstract descriptors like "clearer" or "more engaging."
Claude responds to specificity. The more precisely you describe what is wrong and what the corrected version should achieve, the more closely the revision will match your intent. Vague critique produces vague revision. Precise critique produces targeted change.
This lab requires at least three messages. In message one, send a structured prompt producing a first draft of something — a paragraph, an email, a summary. In message two, write a precise critique using one of the four techniques from the lesson (quote the problem, name the fix, confirm what to keep, or comparison framing). In message three, evaluate the revision and make a final targeted adjustment.
A senior account manager at a New York communications firm, James Okafor, was building a media monitoring report for a pharmaceutical client. He asked Claude to include a section projecting how a competitor's upcoming FDA filing would likely be received by investors. Claude declined — not rudely, but clearly: "I can help you analyze public information about the competitor's track record, but I'm not able to produce investment projections about specific companies as they could be relied on for financial decisions." James's first reaction was frustration. His second was useful: he reframed the request. Instead of asking for projections, he asked Claude to summarize publicly reported analyst opinions about the competitor's pipeline from trade publications — a different task that Claude performed well and that produced the context his client actually needed. The lesson James took, and repeated to colleagues: Claude's refusals are usually information about how you framed the request, not hard ceilings on what the topic allows.
Claude has two distinct categories of limitations, and conflating them causes unnecessary frustration:
Understanding this distinction saves time. If Claude pushes back on a request, the productive question is: is this a hard limit, or is my framing triggering caution that a reframe would resolve? In professional contexts, the answer is almost always the latter.
Claude's training data has a cutoff date. Claude 3.5 Sonnet, released in June 2024, has training data through early 2024. This means Claude cannot tell you about events that occurred after its training cutoff, and its knowledge of rapidly-changing domains (market prices, recent legislation, current clinical trial status) may be outdated.
The practical approach: for any task where currency matters, provide the current information yourself by pasting relevant excerpts, and ask Claude to work from the material you supply. Claude is excellent at analyzing, synthesizing, and writing about information you give it — even when that information is more recent than its training. The phrase "based only on the following information I'm providing" is a useful addition to prompts involving current data.
Additionally, Claude can produce confident-sounding text that is factually wrong — this is the "hallucination" problem that Dana Nguyen encountered in Lesson 1. The practical countermeasure: treat Claude's factual claims as drafts requiring verification, not finished facts. For research-heavy work, ask Claude to indicate when it is uncertain: "Flag any specific claim where you are not highly confident with [uncertain] before the sentence."
A 2023 study by Stanford researchers found that AI legal research tools produced incorrect case citations in approximately 30% of responses. The attorneys who caught the errors were those who treated AI output as a starting point requiring verification. Those who did not verify faced court sanctions. The lesson applies across professions: Claude's confidence in its output is not a reliable indicator of its accuracy.
When Claude declines or hedges significantly, three reframing strategies resolve most professional friction:
Clarify the legitimate purpose: Adding context about why you need the output often resolves contextual caution. "As a nurse practitioner documenting medication interactions for patient records..." is different from an uncontextualized request for the same information.
Decompose the request: Break the task into smaller components and ask for each separately. James Okafor could not get investment projections, but he could get historical analyst opinions, documented competitor track records, and published regulatory timelines — components that together served his purpose.
Ask Claude what it can do: When Claude declines, follow up with: "What related assistance can you offer on this topic?" Claude's response to this question often surfaces an adjacent approach that accomplishes the same professional goal without the framing that triggered caution. This is arguably the most productive response to any pushback Claude gives.
You now have a complete foundational framework: Claude reads exactly what you write and fills gaps from training patterns (L1); structured five-element prompts consistently outperform single-line requests (L2); iteration through a Draft-Critique-Tune loop is the path to polished output (L3); and Claude's limits are mostly about framing, not topics (L4). These four principles compound. A professional who applies all four consistently will produce better AI-assisted work than one applying any single principle in isolation.
In this lab, practice the three reframing strategies: clarifying legitimate purpose, decomposing a request into components, and asking Claude what it can do. Start with a request in a sensitive professional area — medical, legal, financial, or security-related — and observe how Claude responds. Then apply the reframing techniques to reach a useful outcome.