Getting Real Work Out of a Model
You already use ChatGPT, Claude or Gemini. This is how to stop getting average answers.
- Level
- Nothing assumed
- Lessons
- 72
- Reading time
- 590 min
- Price
- Free, no sign-up to read
A practical course for people who use AI chat tools every week and quietly suspect they are getting less than the tools can give. Eight modules and seventy-two lessons on what actually changes an answer: context, tasks, examples, format, reasoning, and honest iteration. Every lesson carries real before-and-after prompts you can copy tonight. No secret words, no incantations, no promises the tools cannot keep. By the end you will be able to brief a model the way you would brief a capable colleague, and to tell when it is guessing.
Opens after the How a Language Model Actually Works exam
Sign in, finish that course, and pass its exam. You can read this syllabus meanwhile.
Go to How a Language Model Actually WorksModule 1
What a prompt actually is
Before any technique, the mechanism. What happens to your words between pressing send and reading the answer — how they are chopped up, why the whole conversation is sent again every turn, why the same prompt gives a different answer twice, and why the model does what you tell it at all. Everything later in the course is a consequence of these five facts.
By the end you can
Explain what happens to a prompt between the send button and the answer — tokenisation, a single re-sent string, sampling, instruction tuning, and the product wrapped around the model — and use that mechanism to predict which prompt changes will help and which are folklore
- 1Why the same question gets a better answerA vague question has a vague best answer; detail is what makes a good answer possible at all.
- 2What the model actually receivesThe model receives one flat block of text — system prompt, whole transcript, your message — chopped into tokens, with no memory and no formatting, and every prompting technique is a consequence of that shape.
- 3Why the same prompt gives a different answerVariation between answers comes from the sampler, not from the model changing its mind, so a prompt is only tested when you have run it several times and seen what moved.
- 4Why it obeys you at allInstruction-following and agreeableness are trained behaviours, which is why manners do nothing, why pushing back makes it fold, and why constraints get dropped without warning.
- 5A role is not a taskNaming a persona sets tone; only naming the verb, the object, the constraints and the finished state sets the work.
- 6The six things a working prompt containsA working prompt fills six slots — task, context, examples, constraints, output shape, escape hatch — and disappointing prompts are almost always missing the last two.
- 7Magic words, and what the studies actually foundThe famous prompt tricks came from narrow studies on older models, and their effects are usually smaller than the ordinary variation between two runs of the same prompt.
- 8How much detail is too muchSpecificity pays until constraints start getting dropped or contradicting each other, so keep three to five checkable requirements and delete any sentence that would not change a correct answer.
- 9Why the same prompt behaves differently in different appsYour prompt is only one layer of what reaches the model, so diagnose surprising behaviour by asking what else was in the block before you rewrite what you wrote.
Module 2
The material you give it
Most disappointing answers are not caused by a badly worded instruction. They are caused by a model working from a description of your problem instead of your problem. This block is about assembling the right material, marking it so it cannot be mistaken for instructions, putting it where it will be used, and leaving out the rest.
By the end you can
Assemble the smallest set of material a task genuinely needs, mark and position it so the model uses it, and diagnose an answer that failed for want of context rather than for want of a better instruction
- 10Context is most of the jobThe model only knows what is in front of it, so paste the thing itself and paste the part that matters.
- 11Paste the source, not your account of itDescribing your problem means deciding in advance what matters, so give the artefact and the surrounding facts and let your interpretation be a question rather than the input.
- 12Marking where your material starts and stopsPasted material and your instructions arrive as one undifferentiated block, so wrap it, name it, and say explicitly that its contents are data rather than orders.
- 13Where the instruction goes, and why it mattersIn a long prompt, state the task before the material and repeat it after, put the most important document last, and prefer the right extract to the whole file even when the whole file would fit.
- 14The background you should stop retypingWrite your unchanging facts — role, place, currency, house words, audience, hard rules — once as a standing brief, keep style out of it, and re-read it whenever an answer arrives strangely.
- 15Memory, and the notes it took about youMemory injects notes a system took about you into prompts you cannot inspect, so audit the list, use temporary chats for anything you do not want kept, and keep the context that matters in a brief you wrote yourself.
- 16What actually happens when you attach a fileAttaching a file sends a derivative of it — extracted text, OCR output, images, or retrieved fragments — so verify what actually arrived before trusting a summary of what is in it.
- 17Choosing what not to includeInclude what feeds a line of the answer you expect and cut the rest, because irrelevant material does not sit harmlessly in the context — it dilutes attention and supplies wrong facts with the same confidence as right ones.
- 18Negative instructions, and why they half-workA prohibition puts the forbidden thing in the context and provides no work to do instead, so convert it into a positive target wherever possible and verify the genuinely negative ones in a separate checking pass.
Module 3
Teaching by example
Some rules are faster to show than to write. This block is about doing that deliberately — choosing the examples that carry the boundary, noticing the pattern you demonstrated by accident, combining a shown example with a stated rule, and proving to yourself that the examples earned the space they cost.
By the end you can
Build a small labelled example set that transmits a rule prose cannot state, identify the unintended patterns your examples teach, and demonstrate by test whether adding them improved the output at all
- 19Show it two examplesExamples transmit their entire shape, including the parts you did not notice you were demonstrating.
- 20Zero, one, or five: how many examplesUse no examples for facts and variety, one for shape, and two to five for boundaries you cannot state — and if you can say what an example teaches in a sentence, write the sentence instead.
- 21The example that earns its placeAn example is only worth its space if a careful person could have got it wrong, so build your set from the real items where you yourself hesitated.
- 22What your examples teach by accidentExamples teach every property they share — length, tone, punctuation, class proportions, order — so read them as a set and either vary or state anything you did not mean to demonstrate.
- 23State the rule, then show itA rule says what an example is an example of, and an example says what a rule means in the hard case, so write the rule first and annotate each example with the reason for its label.
- 24Negative examples, and when they backfireA bad example demonstrates the thing you are trying to prevent, so pair it with its correction and end on the good version, or replace it with a checkable list and a separate self-check.
- 25Capturing a voice from three samplesStyle transfers through real samples plus named mechanics — sentence length, banned openings, contractions — not through adjectives, and it drifts back to generic over long outputs.
- 26Your best examples already existThe examples worth using already exist in your sent folder, your ticket history and your reviewed drafts, and a before-and-after pair encodes a house standard nobody has ever written down.
- 27Proving the examples were worth itCompare a prompt with and without its examples on ten held-out items, three runs each, and treat a difference smaller than the run-to-run wobble as no difference at all.
Module 4
The shape of the answer
An answer that is correct and arrives in the wrong form still costs you twenty minutes. This block is about specifying the container — the table, the message, the JSON, the document — together with the harder question of which format constraints improve an answer and which quietly remove the thinking that made it right.
By the end you can
Specify an output that drops straight into its destination, choose a container that matches the decision being made, and identify which formatting constraints improve an answer and which strip out the reasoning behind it
- 28Ask for the shape you can actually useState the shape, the omissions, and what to do about gaps — but leave room for reasoning before the tidy part.
- 29Length, and what a word limit actually costsStrip padding permanently and set length by what the content needs, because a tight limit on a hard question removes the working rather than the waste.
- 30Choosing the containerChoose the container by what you will do with the answer next, and counteract the bias of whichever you chose — tables invent comparability, lists flatten importance, prose hides omissions.
- 31Output a spreadsheet or a script can readAsk for CSV with explicit rules for separators, dates and missing values, keep the reasoning in prose before the structured block, and remember that valid output is not correct output.
- 32Hand it the skeletonPaste the skeleton with the rule written inside each bracket, including a legal way for a slot to be empty, and derive it from a document that already worked rather than designing it.
- 33Writing for the person who will read itName what the reader already knows, what they will do with it, how long they have and how they feel, and paste something they wrote — that is a real constraint, unlike a persona for the model.
- 34The tells, and how to strip themStrip the machine register with a checkable list of banned constructions, not adjectives — and accept that the deepest tell, an absence of specifics only you could know, is fixed by you rather than by a prompt.
- 35Working across languagesKeep material in its original language, instruct in whichever language you write most precisely, name the register explicitly, and back-translate anything that matters.
- 36Building the failure into the formatGive the output a legal way to fail — a stated empty value, a source quote, a confidence field, a permitted refusal — so the rows that need checking identify themselves.
Module 5
Making it work the problem
Some tasks fail in one pass and succeed in three. This block is about recognising which ones — where shown reasoning genuinely helps and where it only makes the answer longer, how to split a task that keeps going wrong, when to let a reasoning model do it for you, and what a chain of plausible steps is and is not evidence of.
By the end you can
Judge from a task's structure whether shown reasoning will improve it, split a task that fails in one pass into steps that each succeed and can each be checked, and state precisely what a chain of shown reasoning is not evidence of
- 37Make it show its workShown reasoning is not a log of how the answer was made, but it puts claims where you can check them.
- 38Which tasks get better with steps, and which do notShown steps help when a task has dependent intermediate results or when you intend to check them, and otherwise only make the answer longer — so name the intermediate you want rather than asking for "steps".
- 39Arithmetic it should not do in its headA model generates digits rather than calculating, so ask it to write and run code or produce a spreadsheet formula whenever the number matters, and check the inputs and the row count rather than the answer.
- 40Models that think before answeringReasoning models pay off exactly where you would have asked for steps — state the goal and constraints, not the method, and treat the visible trace as material to check rather than a record of what happened.
- 41Splitting a task that keeps failingSplit where the shape of the output changes or where you would want to intervene, keep every intermediate, and check the earliest steps hardest because later steps launder their errors into confident prose.
- 42Ask for the plan before the workGet the outline and the assumptions that would change the result before any substantial output is produced, and for anything that acts on the world, require the plan to state what is irreversible.
- 43Making it check its answer against the rulesChecking is easier than composing, so make compliance a separate pass that quotes the deciding words — and remember a green checklist only covers the rules you thought to write down.
- 44Let it ask you the questionsWhen you cannot tell what your prompt is missing, ask the model for the few questions it cannot guess the answer to — and require assumptions for the rest so clarification does not become a questionnaire.
- 45Asking more than once, on purposeUse repeated runs as a measurement rather than a re-roll — agreement shows stability, disagreement shows exactly where the prompt is under-determined, and neither shows truth.
Module 6
From lucky to reliable
A prompt that worked once is not a prompt you own. This block is about the loop that turns a half-working attempt into something dependable: naming which of four things went wrong, changing one thing at a time against a fixed check, keeping the version that worked, and recognising the point at which no further prompting will help.
By the end you can
Diagnose which of four causes produced a bad answer, improve a prompt by changing one thing at a time against a fixed set of test items, and keep a version a colleague could run and get the same quality from
- 46Edit the prompt, do not spin the wheelRegenerating resamples the same prompt; naming what is wrong is the only thing that changes the pile.
- 47Four reasons an answer is badBad answers have four causes — missing material, misread instruction, wrong output form, and a task beyond the tool — and the giveaway for the fourth is that better prompting produces a better-looking wrong answer.
- 48Change one thing at a timeChange one element at a time against fixed test items with several runs each, discard what does not measurably help, and periodically try removing things — most reused prompts are a third decoration.
- 49The five items you keep foreverKeep five to ten fixed items with expected answers, including one that should produce a refusal, and run them after any prompt change and after any model update — decay is invisible without them.
- 50The file that makes this compoundKeep each working prompt with its date, its model, a "use when" line, the reason for its odd constraints, and capitalised slots for the parts you swap — the notes are what make it usable three months later.
- 51Why a prompt stops workingWhen a stable prompt degrades, check the model version, the product, the input shape and the age of any hard-coded fact before rewriting — and prefer prompts that describe a good answer over prompts that work around a behaviour.
- 52Why the prompt from the internet does not workBorrow structure and domain knowledge from other people's prompts and discard the persona, the stakes and the exhortations — what makes a prompt work is the specificity a shared template has had removed.
- 53Getting the model to improve your promptAsk what information is missing and where your wording is ambiguous, cap the loop at two rounds tested against real items, and never let the model judge whether its own output was good.
- 54When to stop prompting and do it yourselfDecide beforehand how long the task would take by hand, stop when the same error survives two genuine fixes, and hand back the parts that need judgement, accountability or knowledge only you have.
Module 7
Checking the answer
Confidence is not a signal, and the errors that hurt are the ones that look exactly like correct answers. This block is about verification that fits the failure: how to check a citation, a search-grounded claim, an assertion about a document, a figure, and the hardest one — something that was quietly left out.
By the end you can
Match verification to the cost of being wrong rather than to how confident an answer sounds, and apply the right check for a citation, a search result, a claim about a document, a number and an omission
- 55How to tell when it is guessingFabrication can be more specific than truth, so verify by cost of being wrong, never by how confident it sounds.
- 56The citation that does not say thatA fabricated citation fits the pattern of a citation better than many real ones, so check that it exists, that it says what is claimed, and that it supports the inference — three separate checks, in that order.
- 57When it can search, and what that fixesA search tool replaces a memory problem with a reading problem — so ask for the query, the source and the date beside each claim, and open the one page that carries the claim you will act on.
- 58Checking a claim about a document you haveA claim about a document is checkable in seconds by searching a middle fragment of the quote and reading the whole sentence around it — and the sentence-level qualifiers are where summaries reverse meaning.
- 59Checking a number in under a minuteCheck a number by magnitude, by whether the parts add up, by whether the bases match, and by tracing one component to its source — and ask for the two raw numbers behind any percentage.
- 60Disagreeing without getting agreementAsking "are you sure?" tests agreeableness rather than correctness, so verify by asking for the evidence, the case against, or a clean-context re-answer — and treat agreement with your framing as the default, not as support.
- 61Asking a second modelA second model from a different provider locates disagreement cheaply, but shared training data means agreement is not independent confirmation — a real check is one whose failure mode differs from the thing being checked.
- 62The hardest check: what was left outAn omission leaves no mark in the answer, so force it into view — enumerate and count before analysing, require a line for every checklist item including "not present", and ask what was found but left out.
- 63How much checking is enoughSort by what happens if the answer is wrong rather than by how confident it sounds, and design the prompt so the checking is a text search rather than a re-reading.
Module 8
The work you actually have
Everything so far applied to the jobs that fill a real week — a draft, a difficult message, a long document, a decision between options, a messy spreadsheet, a script you cannot write, something you are trying to learn, an application you need to send. Each lesson is a worked prompt you can adapt tonight, and the last one is about making a prompt somebody else can run.
By the end you can
Take a recurring task from your own week and build a prompt for it that supplies the right material, produces a usable shape, makes its own failures visible, and can be handed to a colleague who will get the same quality from it
- 64Drafting without losing the thing that was yoursDo the thinking out loud, hand over transcription and diagnosis, and keep the first sentence, the argument, the commitments and anything personal — a draft you merely accept is the average version.
- 65The message you have been putting offState the relationship's future, the dated history, the precise outcome you want and what you will not do — then ask how the recipient will read it before you send.
- 66Getting through a long document properlyMap the document and count its sections, locate the relevant ones, extract with quoted sources, verify two quotes, and summarise last — a summary produced first is a selection you cannot audit.
- 67Deciding between optionsBring your own criteria and weights, use the model to surface the criteria you would have regretted ignoring, require a source for every factual claim, and ask for the case against your preference rather than whether you are right.
- 68The spreadsheet somebody else builtAsk for the transformation — a formula or a script — rather than the cleaned data itself, diagnose from fifteen rows before cleaning, and check the row count before and after every step.
- 69Asking for code you could not have writtenAsk for commented code with setup instructions, run it on a copy with a dry run first, and verify by counting rows and spot-checking three — reading a script for deletions and network calls is a much smaller skill than writing one.
- 70Using it to learn, without fooling yourselfLearning happens when you produce — explain it back, be tested with hints rather than answers, and ask where the rule breaks — because a clear explanation reliably produces the feeling of understanding without the thing itself.
- 71Applications, without the generic letterAn application fails because it contains nothing only you could have written, so paste the full advert, the full CV and the awkward truth — and use the model hardest for interview practice rather than for the letter.
- 72A prompt somebody else can runA prompt transfers only with its context, its expected output, and its "when to distrust it" section — and if you cannot write that section, you do not yet know when to distrust it yourself.