Use AI as a skeptical student and then as an examiner to pinpoint, to the word, where your understanding breaks.
Open this lesson in KodokonThe Feynman technique rests on a ruthless observation: you only discover your gaps when you try to explain. As long as a concept stays in your head, the brain papers over the holes with comfortable vagueness; the moment you have to state it simply for someone else, every hole becomes a wall. Education research confirms the intuition under the name protégé effect: teaching a concept produces a greater retention gain than reviewing it, even when facing a fictional student. AI is the ideal fictional student - available, tireless, and above all configurable: you can forbid it from doing what a polite human would spontaneously do, filling your silences.
You play the role of a curious, skeptical junior developer. I'm going to explain [CONCEPT, e.g. Node.js's event loop] to you as if you knew nothing about it.
Your rules:
1. Interrupt me the moment I use a piece of jargon without having defined it: simply ask "meaning?".
2. Demand a concrete example for every abstract claim.
3. Spot my evasive phrasings ("basically", "it's kind of like", "technically") and force me to specify what they hide.
4. At the end, grade my explanation out of 10 and list the exact points where I was vague, wrong or incomplete - that's the only thing I really care about.
Absolute prohibition: never complete my explanation for me, even if I'm wrong. Your role is to reveal my gaps, not to fill them.
I'll begin: [YOUR EXPLANATION]While you explain, learn to recognize the three gap signals. The first is shield-jargon: you use a technical term precisely because you'd be unable to unpack it ("it's handled by the garbage collector" - how, exactly?). The second is the slippery analogy: "it's kind of like a queue" without being able to say where the analogy breaks. The third is the logical leap: between two sentences, a "therefore" that hides three steps you couldn't detail. Note each signal in your learning journal: these are your next review targets, far more precise than "review chapter 4".
Change roles: you are now a senior technical examiner for a staff engineer position. The topic is [CONCEPT] and my explanation appears above in the conversation.
Your mission: put it to the test, not complete it.
1. Ask me 3 questions about edge cases my explanation doesn't cover.
2. Build a counter-example that seems to contradict what I claimed, and ask me to resolve it.
3. Identify an implicit assumption in my explanation and ask me what would happen if we removed it.
One question at a time. After each answer, deliver a one-word verdict - solid, shaky or wrong - followed by a sentence of justification. Only give the correct answer if I've failed twice in a row on the same question.Finally, weave the method into the moments where it pays off most. After every non-trivial debugging session: explain the root cause to the AI in skeptical-student mode; if your explanation doesn't hold, you fixed the symptom, not understood the bug - it'll come back. Before every code review you request: explain your design in three sentences; if you can't, the problem is upstream of the code. This ten-minute exercise turns every everyday incident into a learning session - the exact opposite of having an explanation generated and reading it passively, where the comfort of reading passes itself off as understanding.