Teaching Notes
For instructors, editors, and curriculum builders
This document is for people delivering, adapting, or editing this course. It covers intent, tone guidance, and things to watch for during review or facilitation.
Core teaching intent
Each lesson in this course is designed to change one behavior. Not explain a concept broadly — change one specific thing about how the learner approaches AI.
When reviewing lessons, ask: "Will someone who reads this do something differently afterward?" If the answer is no, the lesson needs more practical grounding.
Tone guidance
The course should feel like advice from a smart colleague who has figured something out and is explaining it plainly.
It should not feel like:
- A whitepaper
- A how-to manual for a software product
- A motivational presentation
- A technical spec
If a sentence sounds like it belongs in a vendor blog post, it probably needs to be cut or rewritten.
Watch for:
- Words like "unlock," "leverage," "supercharge," "empower," "revolutionize," "transform"
- Hollow affirmations at the start of lessons ("Great news! In this lesson you'll discover...")
- Padding that restates the lesson title before getting to the teaching
- Conclusions that just repeat the intro with different punctuation
Pacing and depth
Each lesson should be readable in 5–8 minutes. Exercises add 10–20 minutes each.
Lessons should not try to cover everything. Each one covers one idea well. If you find a lesson drifting into multiple ideas, consider whether one idea can be pulled out into its own section or removed.
Examples
Every lesson should have at least one concrete example. Wherever the spec calls for a "weak" and "strong" comparison, use examples that are realistic and clearly differentiated.
Avoid examples that are obviously terrible. "Write me a thing about stuff" is not a useful weak example. A realistic weak prompt is one that a thoughtful person might actually write — just without proper context, audience, or direction.
Exercises
Exercises should feel like real work, not homework. The best exercises are ones where learners will recognize: "I would actually do this task in my job."
Keep exercises focused. One exercise per lesson. If you have two good ideas, pick the one that is most transferable.
On accessibility
Do not assume the reader knows what a prompt is. The term is introduced early and simply. Wherever technical vocabulary is used, it should be defined plainly in context — not in a sidebar, not in the glossary, but right where the term appears.
Review checklist
Before finalizing any lesson:
- [ ] Does the lesson teach one clear, actionable thing?
- [ ] Is there at least one concrete example?
- [ ] Does the weak/strong comparison actually show a meaningful difference?
- [ ] Is the tone practical and grounded — not hypey, not academic?
- [ ] Is the exercise realistic and doable?
- [ ] Could a non-developer follow this without getting lost?
- [ ] Does the key takeaway capture the lesson accurately in one sentence?