One of my only clear memories from primary school is DEAR – Drop Everything And Read. The truth is I was sleeping through it. DEAS: Drop Everything And Sleep.

Reading alone has never been how I learn. Passively reading documentation puts me to sleep just as fast as DEAR once did. But I found a learning method that actually works, one inspired by physicist Richard Feynman, and AI conversation turns out to be the tool that makes it practical.

The Feynman method in four steps

Feynman’s idea: if you can’t explain something simply, you don’t understand it yet. The gaps show up the moment you try to explain.

1. Articulate the idea. Say it out loud or write it down.
2. Find the gaps. Notice where the explanation breaks down.
3. Fill the gaps. Research, refine, test your understanding.
4. Explain again, simply. If you can, you understand it.

Solid method. Slow on your own though. You articulate something, realise you don’t get it, grind through documentation, come back hours later and try again. Momentum dies somewhere in that gap.

Why AI conversation closes that gap

What if something could question your understanding the moment you say it out loud, and help you refine on the spot? That’s what AI conversation gives you: not a replacement for thinking, but a way to make Feynman practical instead of slow.

• Immediate feedback. You explain, Claude questions, gaps surface instantly.
• Real-time refinement. No energy crash waiting for round two.
• Better retention. You remember what you’ve built through dialogue far better than what you’ve read.
• Low friction. Ask as you think, no stopping to search docs.

A real example: building Cortex Analyst regression tests

I was asked to design a regression testing system for Snowflake Cortex Analyst semantic models. Complex problem, no clear direction yet.

I started by working with Claude to build a project brief: business intent, models in scope, tech stack, known unknowns, and what success looked like to stakeholders. Compact and high-level, not prescriptive. Too vague kills the dialogue, too detailed kills the exploration.

With that locked in, I had Claude research the latest Cortex Analyst documentation first, so it entered informed rather than relying on training data. Then the design conversation started, and it followed the same loop each time: state an idea, get questioned, find a gap, fix it.

Say the idea out loud, and questions find what you were assuming. I explained how I understood Cortex Analyst evaluations to work. Claude asked whether we’d batch models or run them one at a time, and what the baseline sampling strategy was. I didn’t have a real answer to either, which meant I understood less than I thought.

Push the idea against a harder case, and it forks instead of breaking. I’d proposed different sampling percentages per branch. Claude asked what happens if the config changes mid-comparison. Working through it live, the fix wasn’t extra test runs, it was arithmetic: pulling the “new config only” result out of data we already had. The hard case got a named plan instead of a hidden gap.

Your own answer can fail the same test. I’d proposed deriving comparisons by query rather than storing them. Claude asked how you’d audit a comparison computed on the fly. My own answer didn’t survive that. We added a table to store them properly instead.

Step back and re-explain the whole thing simply. Partway through, I asked directly whether this was best practice or technical debt. The answer: pragmatic trade-offs, not ideal. We agreed the current design was defensible, with a clear plan to refactor later if needed. The debt was conscious, not accidental.

Two hours, about 60 messages back and forth: a complete four-pillar architecture, production-ready decisions on sampling, storage and gating, and specs ready for handoff.

That was just the first pass. I fed the draft to Claude Code and asked it to build an HTML visualisation of the four pillars. Seeing it as a diagram exposed gaps the dialogue hadn’t caught, things that read fine in prose looked different once drawn out. I refined the architecture, then opened a new conversation to work through what I was still unsure about. More refinement, no major rework, because gaps got caught as we went instead of all at once at the end.

Five practical tips

1. Prime with context first. Upload the docs, write the brief, don’t go in blind.
2. You articulate, Claude questions. That’s the method in action.
3. Stay focused. Each message should sharpen one thought, not wander.
4. Use lighter models. Sonnet 5 or Haiku 4.5 are plenty. You need fast, sharp feedback, not deep reasoning.
5. Summarise, then start fresh. After a focused session, get Claude to write a markdown summary of what you decided. Next session, upload that instead of the full history. You skip re-explaining everything and the token bill drops with it.

Isn’t this just rubber-duck debugging with better feedback?

Fair question. The difference is the pushback. Rubber-ducking to yourself only goes so far, because you already share your own blind spots. AI conversation closes that gap by questioning you back.

Dependency isn’t really the risk either. You’re building deeper understanding because you’re forced to explain why something works, not just what it is. That’s what builds independence.

And none of this is specific to Claude. It works with a colleague or a mentor too. The tool just makes it faster and lower friction.

Closing

I went from sleeping through DEAR to practising Feynman with AI instead of a textbook. The method is old and proven. The tool is what changed.

If you learn by talking rather than reading, this isn’t a hack. It’s matching a method that already works to a tool that finally makes it practical.