For years the answer to "how do I learn X?" was a YouTube playlist. That still works, but it has a flaw: the video does not know what you already understand, and it cannot see what you are stuck on. You watch someone else succeed and then try to copy them.

An AI assistant like Claude flips that around. It can ask you questions, look at your attempt, and explain the exact bit you got wrong. Used well, it is closer to a patient tutor than a textbook. Used badly, it is a machine for producing answers you do not understand. The difference is entirely in how you ask.

I use Claude every day for my own work, and I have watched how it teaches best. This is the approach I would give to anyone who wants to learn a skill rather than just get an answer.

Tell it to teach, not to do

The default behaviour of any assistant is to solve your problem. If you ask "write me a formula that totals this column", you get a formula. You have learned nothing.

Instead, set the frame at the start of the conversation:

I want to learn how to do this myself. Do not give me the answer straight away. Explain the idea, then give me a small task to try, then check my attempt.

That one instruction changes everything that follows. Claude will slow down, break the skill into steps, and wait for you.

Start from where the thing actually begins

Good teaching follows the order things happen in, not the order a reference manual lists them. When I explain a piece of software to a junior developer, I do not start with a list of files. I start with "the user clicks this button, and here is what happens next", and we follow the trail.

Ask Claude to do the same for whatever you are learning:

Walk me through this from the moment it starts. At each step, tell me what happens, why, and what would have happened if it had gone the other way.

This works for spreadsheets, for a piece of code, for a recipe, for how a mortgage application moves through a bank. Learning the sequence gives you a mental model. Once you have the model, you can work out the details yourself.

Make it explain the why, not just the what

"What" is cheap. Any search engine gives you what. The bit that sticks is why a step exists and what breaks if you skip it.

Whenever Claude gives you a step, ask:

Why does that step come before the next one? What goes wrong if I do it the other way round?

You will find that the answers to "why" are where the real understanding lives. They are also the answers that transfer to the next problem, which the specific "what" never does.

Do the thing, then have it checked

Watching is not learning. After each explanation, do the task yourself and paste your attempt back. Say:

Here is what I did. Do not fix it for me. Tell me where it is wrong and give me a hint.

This is the step most people skip, and it is the one that matters. The hint should be enough to get you moving without handing over the answer. If you are still stuck after a second try, then ask for the answer, but ask it to explain the gap between your attempt and the right one.

Make it show you how to test your own work

A skill you cannot check is a skill you do not really have. Whatever you are learning, ask:

How do I prove to myself that this works? Give me a concrete way to test it.

For a spreadsheet, that might be a set of numbers where you already know the answer. For a bit of code, it is the exact command to run and what the output should look like. For a marketing email, it might be sending it to yourself and reading it on a phone. The point is that you stop needing the assistant to tell you whether you got it right.

Keep the conversation going for weeks

The biggest advantage over a video is memory within a conversation. Keep one long thread per skill. Come back to it. Start each session with "remind me where we got to and give me the next task". You end up with a tutor that knows your history, your mistakes, and the words that helped.

A worked example

Say you want to learn enough SQL to answer questions about your own shop's sales. The conversation might go:

  1. "I run a small shop and I want to learn SQL well enough to answer questions about my sales data. Teach me, do not do it for me. Start with the smallest useful thing."
  2. Claude explains what a table is and gives you a two-line query to try.
  3. You run it, paste the result, and ask what the parts mean and why they are in that order.
  4. "Give me a question about my sales that needs one more idea than I have now."
  5. You attempt it, get it wrong, ask for a hint, fix it.
  6. "How would I check this number is right without trusting the query?"

Six exchanges in, you own a skill instead of a snippet.

The honest caveat

Claude can be wrong, and it can be confidently wrong. That is another reason to insist on testing your own work rather than accepting the answer. Treat it as a very well-read colleague, not an oracle. The habit of checking is itself part of the skill you are learning.

If you want help putting AI tools to work in your business, whether that is learning to use them yourself or building something with them, get in touch and tell me what you are trying to do.