Prompt Patterns Worth Memorising
Ten reusable shapes — from 'explain before you change' to 'give me three options' — each one copyable.
Read first: Writing Prompts That Work
Once you have written a few hundred prompts, you notice you are writing the same ten shapes over and over. Here they are, ready to copy. Learn the reasoning behind each and you will stop needing the list.
The ten patterns
1. Explain before you change
Use when: You are about to touch code you do not fully understand.
Before changing anything, explain what this file does and howit is used elsewhere in the project. Then wait — do not edit yet.Why it works: Splits comprehension from modification. If the explanation is wrong, you have caught it before any code moved.
2. Give me three options
Use when: There is more than one reasonable approach and you do not know the tradeoffs.
Give me three ways to solve this, with the tradeoff for each.Do not write code yet. Recommend one and say why.Why it works: The first idea a model produces is the most common one, not the best one. Asking for three surfaces the alternatives it would otherwise skip.
3. Constrain the blast radius
Use when: Always, on any codebase you care about.
Change only src/components/Cart.tsx. Do not add dependencies,do not modify tests, and do not reformat code you are nototherwise changing.Why it works: Unbounded requests produce unbounded diffs. Stating the boundary makes an over-reaching change obvious instead of invisible.
4. Show me the diff first
Use when: The change spans multiple files.
Describe exactly what you plan to change, file by file,before making any edits. I will confirm.Why it works: Reviewing a plan takes thirty seconds. Reviewing eleven files of applied changes takes twenty minutes.
5. Reproduce, then fix
Use when: Fixing a bug.
First write a failing test that reproduces this bug.Show me the test failing. Only then fix it.Why it works: Proves the bug is understood before it is patched, and leaves behind a test that stops it returning.
6. Match what exists
Use when: Adding to an established codebase.
Find an existing component that does something similar andfollow its conventions — naming, file layout, error handling,styling approach. Tell me which one you used as the model.Why it works: Prevents the AI from importing patterns from its training data that clash with everything around them.
7. Name the failure modes
Use when: The code handles user input, money, or anything external.
List the ways this could fail — empty input, network error,concurrent access, malformed data — then handle the ones thatare realistic here.Why it works: Happy-path code is the default output. Edge cases only appear when you ask for them by name.
8. Rubber duck it back
Use when: You are not sure the AI understood the request.
Restate what I am asking for in your own words, includinganything you think is ambiguous. Do not start yet.Why it works: A misunderstanding costs one message to catch here, or an hour to catch after the code is written.
9. Set the stopping condition
Use when: Handing off a longer task.
Work until npm run check passes with no errors. If you getstuck twice on the same problem, stop and tell me ratherthan trying another approach.Why it works: Gives an objective finish line and prevents the flailing loop where each 'fix' creates the next problem.
10. Ask what it is unsure about
Use when: Right before you accept anything substantial.
What in this change are you least confident about,and what should I check by hand?Why it works: Models are poorly calibrated but not uncalibrated. This reliably surfaces the weakest part of the diff.
The thread running through them
Read the ten together and one idea repeats: separate thinking from doing. Explain before changing. Plan before editing. Reproduce before fixing. Restate before starting.
That is not a trick specific to language models. It is how you would brief a capable colleague who is fast, widely read, and has never seen your codebase — which is very close to what you are actually working with.
There is a mechanical reason it matters more here than with a human colleague. Once a model has written two hundred lines committing to an approach, correcting course means discarding work it has already produced — and a discard is a much bigger ask than a redirect. Separating the plan from the code means the expensive part only happens once you have agreed on the plan.
Building your own
The list above is not exhaustive, and yours will not match it exactly. You will notice your own pattern forming the same way you notice any habit: you catch yourself typing a near-identical clarification for the third time on unrelated tasks.
- 1Write down the shape, not the specific wording
The instinct is to save the exact sentence. Save the situation it answers instead — “I am about to touch code I don't fully understand” travels better than any one phrasing.
- 2Keep it somewhere you will actually paste from
A notes file works. It is better than nothing and worse than the next step.
- 3Promote it to a rules file once it applies to most prompts, not just this one
That is what makes it automatic instead of something you have to remember to type — the subject of the next part of the course.
A pattern you have to remember to use is only half a pattern. The payoff comes when it stops being something you type and starts being something that is simply true of every prompt you send, which is what a rules file buys you.
Key takeaways
- Separate thinking from doing. Almost every good pattern is some version of that.
- Ask for options before implementations when the approach is open.
- State the boundary explicitly, or the diff will decide its own size.
- “What are you least confident about?” is the cheapest review you can run.
- A clarification you have typed three times belongs in a rules file, not in your fingers.
Before you move on
Quick check
Answer these to unlock the next chapter: 3 of 4 to pass. You can retake it anytime.
Make a free account to read on
Every chapter is free — an account lets your course progress follow you from your laptop to your phone. No payment, no trial.