Learning & Explanation Patterns

You've been asked to explain something twice this week already. Once to a new hire who needs the concept from zero. Once to your manager, who needs the one-paragraph version because they're about to walk into a budget meeting. Same underlying idea both times — completely different prompt if you actually want it to land.

That's the gap this lesson closes. Learning and explaining are two sides of the same move: getting a concept into a shape someone (possibly you) can actually hold onto. The five patterns below aren't about making AI sound smart — they're about making the explanation stick, and about catching it when it doesn't.

Pattern 1: ELI5 Ladder

Ask for the same concept explained at three escalating levels in one response: novice (zero prior context, no jargon, an everyday comparison), practitioner (assumes basic fluency, uses the real terms, connects to how it's actually used), and expert (assumes prerequisites, skips definitions, goes straight to the interesting tradeoffs).

Explain [CONCEPT] at three levels in one response:

NOVICE: no jargon, use an everyday analogy, assume zero prior context.
PRACTITIONER: assume basic familiarity with [DOMAIN], use real terminology,
  connect it to how it's actually used day to day.
EXPERT: assume [SPECIFIC PREREQUISITES], skip all definitions, go straight
  to the interesting design tradeoffs or edge cases.

Keep each level to 3-4 sentences.

When it works: Mixed-audience situations — a Slack thread with people at different seniority levels, a doc that both new hires and veterans will read, or when you genuinely don't know your own level yet and want to self-select. It also works as a personal diagnostic: if you can only follow the novice band, that tells you something.

When it fails: If you only ever read the novice band and skip straight to applying the concept, you'll miss the caveats that live in the practitioner and expert bands — the ladder is meant to be climbed, not cherry-picked from the bottom rung.

Pattern 2: Analogy Bridge

Map an unfamiliar concept onto something the listener already understands well, then — this is the part almost everyone skips — explicitly state where the analogy breaks down.

Explain [UNFAMILIAR CONCEPT] using an analogy to [FAMILIAR DOMAIN THE
LISTENER KNOWS WELL].

After the analogy, add a section titled "Where this breaks down:" that
names at least two specific ways the analogy is misleading if extended
too far.

When it works: Onboarding someone into a domain by bridging from something they're already expert in — explaining Kubernetes pods to someone who's run a restaurant kitchen, explaining vector similarity to someone who thinks in spreadsheets. The bridge gets them moving fast.

When it fails: Every time, in the exact same way — you skip stating where the analogy breaks down, and the listener extends it past its useful range. A load balancer isn't a restaurant host that "deletes" overflow guests; it queues or redirects them. If you don't say the analogy stops being literal at that point, someone will build a wrong mental model on top of a correct-sounding comparison, and it'll surface three weeks later as a wrong assumption in a design review.

Pattern 3: Feynman Check

Explain the concept back to the AI in your own words, and have it grade the gaps — not the phrasing, the actual conceptual holes.

I'm going to explain [CONCEPT] back to you in my own words. Grade my
explanation for CONCEPTUAL GAPS only — ignore phrasing and style.

For each gap you find:
1. Name specifically what's missing or wrong
2. Re-explain ONLY that piece, not the whole concept
3. Ask me to explain that piece back to confirm it landed

My explanation: [YOUR EXPLANATION]

When it works: Any time you think you understand something but haven't tested it — before a presentation, before you write documentation, before you tell a teammate "yeah, I get it, let's move on." Named after Richard Feynman's technique: if you can't explain something simply, you don't understand it yet.

When it fails: If the loop isn't bounded to the specific gap, it turns into a full re-teach every round, which is slow and demoralizing, and you'll quit before the gaps actually close. It also fails if you let the AI grade your wording instead of your understanding — a technically imprecise but conceptually correct explanation should pass.

Pattern 4: Worked-Example Scaffold

Don't just explain the rule — walk one concrete example through it, start to finish, showing every intermediate step.

Explain [CONCEPT] by walking through ONE concrete worked example:

1. State the specific input/scenario
2. Show each step of applying [CONCEPT], including intermediate values
3. State the final output
4. Then, in 2-3 sentences, generalize from the example to the rule

Use a realistic example from [YOUR DOMAIN], not a toy example.

When it works: Anything procedural or formulaic — a pricing calculation, a retry-with-backoff sequence, a statistical test. Abstract rules are easy to nod along to and hard to actually apply; a worked example forces every step into the open.

When it fails: If the example is a toy that doesn't resemble your actual domain (the classic "foo/bar" problem), you'll understand the mechanics but fumble the application when the real data doesn't look like the sanitized example. Always specify your actual domain in the prompt.

Pattern 5: Misconception Preempt

Before teaching the correct model, name the most common wrong mental model explicitly — so the learner recognizes it if they're already carrying it, instead of quietly layering the correct explanation on top of a wrong foundation.

Before explaining [CONCEPT] correctly, first state the most common WRONG
mental model people bring to this topic, and explain specifically why
it's wrong.

Then teach the correct model, explicitly contrasting it against the
misconception you just named.

When it works: Concepts with a well-known "attractive but wrong" intuition — eventual consistency (people assume it means "wrong sometimes," not "correct within a bounded delay"), or async/await (people assume await blocks the whole runtime, not just the current function). Naming the trap before someone falls into it is cheaper than correcting it after.

When it fails: If you don't actually know the common misconception for a niche or new topic, the AI may fabricate a plausible-sounding-but-wrong "common misconception" that doesn't match what your specific audience actually believes. Ground this one in a real misconception you've personally seen, or skip it.

Where the Craft Track Comes In

If you want to understand why Feynman Check works — the retrieval-practice research behind "explaining it back" being more durable than re-reading, or why analogies transfer partial structure rather than full structure — that depth lives in Prompt Engineering Mastery's Persona and Critic patterns. This lesson gives you the ready-to-run version; that track gives you the mechanism.

Build It

The BuildChallenge below has you encode the ELI5 Ladder as a function — a buildExplainAtLevel assembler that takes a concept and a level and returns a level-appropriate prompt, with real constraints (a jargon budget at novice level, assumed prerequisites at expert level) instead of vague vibes about "keeping it simple."

Bottom Line

Five patterns, one underlying move: match the explanation's depth to what the listener actually needs, and verify understanding instead of assuming it. ELI5 Ladder handles mixed audiences. Analogy Bridge handles unfamiliar-to-familiar bridging — as long as you name where the bridge ends. Feynman Check catches the gap between "I read it" and "I understood it." Worked-Example Scaffold makes procedural concepts concrete. Misconception Preempt clears the wrong model before the right one moves in. Next: Iteration Loops — the critique-and-refine discipline that makes every pattern in this track sharper the more you use it.