How to Learn Claude Code: The Path That Actually Sticks

Last updated: November 2026

The best way to learn Claude Code is to start with what Anthropic gives away: the free Claude Code 101 course and the official quickstart, run on your own machine, followed by one small project that you finish and put online. That part is not controversial, and it is not where people get stuck. Whether the skill sticks is decided by everything around it: a first install that swallows the evening, practice that never happens between sessions, a fix tested on the wrong copy, and a deploy that stops halfway for a sign-in nobody mentioned. So how hard is it to learn Claude Code? Less hard than its reputation, and hard in different places than you would expect. The patterns below come from our session notes this autumn, mostly from three working professionals early in their time with the tool, none of them employed as developers. Six patterns, in the order they show up.

In this post: the free syllabus · the setup sitting · homework with a finish line · practice follows your week · testing the old version · the human half of deploy

1. Use the free course as your syllabus

If you want to learn how to use Claude Code properly, the spine of it is already written, and it costs nothing. Anthropic's own quickstart ends by pointing you to it: "take Claude Code 101 and other free self-paced courses on Claude Academy." I would rather you did that before paying anyone, us included.

Claude Code 101 is 12 lessons and about an hour and a half, plus a quiz. It runs from what the tool is and how it works, through installing it and your first prompt, into the daily workflow (explore, plan, code, commit), context management and code review, and finishes on customisation: the CLAUDE.md file, subagents, skills, MCP and hooks. Its stated audience is developers, new and experienced. Take it anyway if you are not one. You will look up a few words, and that is fine.

Here is the order I would put the free material in:

If you are learning Claude Code as a beginner, that first row matters more than it looks. The terminal guide opens with a sentence I wish more tutorials led with: "You can use Claude Code even if you've never used a terminal before." It also points to the desktop app if you would rather skip the terminal entirely.

And if you came here for how to learn Claude Code for free, the honest answer has two halves. The learning is free. The tool is not. Claude's pricing page says "Claude Code is included in all paid plans," and the Free plan does not include it. The quickstart's account requirement is a Claude subscription, a Console account, or access through a supported cloud provider.

What none of that material can do is see your screen or your week. The rest of this list is about that gap.

The fix: do Claude Code 101 in week one with the quickstart open in a second window, and run every step on your own machine as you go. Watching the install lesson is not the same as installing.

2. Book setup as its own sitting

This is the item people argue with, because installation sounds like a five-minute preamble to the real lesson. On Windows, in my experience, it is often the first real lesson, and treating it as a preamble is what makes it feel like failure.

Two new students on Windows this autumn lost real time before the tool said a word. Across their first sessions, the surprises were these:

claude --version
# working install: prints a version number, then (Claude Code)

# what actually showed up instead:
# "claude is not recognized"        install worked, folder not on PATH yet
# "does not support 32-bit Windows" on a 64-bit PC, from the editor's terminal
# no output for minutes             looks like a hang, usually the download
# a project folder inside OneDrive  files not where we expected them

Every one of those is either documented or avoidable. The terminal guide explains the 32-bit one directly: on a 64-bit machine, the error means you opened Windows PowerShell (x86), which "runs as a 32-bit process." In our case the editor had quietly opened that version for us. The same guide warns that the installer "shows no progress while Claude Code downloads, so leave the window open and wait," which is exactly the moment a beginner decides it has frozen. The PATH message keeps turning up with new students, and in one case, even after the PATH was fixed, it took closing every leftover editor window, including ones still running in the background, before the terminal saw the change. The OneDrive folder was my oversight: the project lived in a synced folder, the files did not appear where we expected, and moving it left a duplicate that cost the start of the next lesson.

One of those first lessons spent most of its hour getting to a working claude. I do not count that hour as wasted. It is the hour where you learn what a terminal is, where your files actually live, and that the error messages are usually telling the truth. The same student drafted her first prompt in a text file while the installer ran, so the lesson still ended with something building.

I went through the wider version of this, including hardware, second screens and video call failures, in six setup problems that stall AI beginners.

The fix: give setup its own sitting, not the first ten minutes of a learning session. Make the project folder somewhere local that does not sync, and stop for the day once claude --version prints a number if that is all you have energy for.

3. Homework with a finish line gets done

The pattern here is the cleanest one in this autumn's notes, and it cuts against how most people plan their own practice.

The first two rows are the same student. She did every structured exercise she was given, a short challenge with a defined answer, and came back with it finished. The one week the homework was open-ended (find a design you like, so we can build from it), it was not done and not remembered. Asked what she had worked on since the last lesson, she said, "Not really." A chunk of the next lesson went on doing that homework live.

The third row is a different student. He was set six or seven hours on his site across a weekend, and none of it happened. Then, in the same lesson where we discovered that, something changed. Once the brief for the site was settled and I asked him to tell Claude what he wanted in his own words, he wrote about six prompts of his own in under half an hour. The ability was there the whole time. What was missing between lessons was a task small and specific enough to start.

This is the other half of something I wrote about in October, a student who had done nothing between lessons and could not remember the last one at all. What fixed that was a way to look lessons up. In that post I also said I had stopped leaving homework altogether. The notes since then are more precise than that: open-ended homework fails, and homework with a finish line does not. "Practise" is not a task. "Get the contact section live with a working email link" is.

A surprising amount of what my team and I do in 1-on-1 sessions is exactly this: turning "practise this week" into one task with a visible ending.

The fix: turn every "work on it this week" into one task with a finish line you can check. If you cannot tell whether it is done, it will not get done.

4. Practice follows your week, so choose the project from it

The student who did not touch his site across three gaps had not stopped using Claude. When I asked if he had done anything, he said he had not. Later in the lesson, once we opened the project, it came out that he had used it for something else: an interface experiment he had seen in another tool, typed into the website conversation. In an earlier gap he had used the Claude app for something at work. Practice had happened. It had gone where his week was already pulling him, which was not towards a personal website.

That website was my suggestion, and a reasonable one: it has a visible ending and it teaches the whole loop from folder to live link. But the thing he had brought up more than once was a repetitive data entry task he does by hand. That never became the project, and in hindsight it is the one I would start him on now.

The other version of this pattern is the gap. A team lead I work with came back after five weeks between lessons and summed up where things stood himself: it was still a website, and "we don't have anything yet." Nothing had gone wrong in those five weeks. The project had simply waited for the next lesson. Once we were back on it, his first deploy took minutes. The tool was never the slow part.

A learning project that sits outside your working week has to compete with your working week, and it loses. A project that saves you an hour on Thursday gets opened on Thursday.

The first projects in this autumn's notes, and what each one was good for:

• A small browser game. One student's went live in her second lesson with Claude Code. Quick to finish, and it teaches the whole loop from prompt to public link.
• A one-page personal site. The most common first project, with a clear ending. It only keeps you practising if you have a reason to open it again.
• A task you repeat by hand at work, like the data entry above. Slower to start, and the one most likely to get opened on a Thursday.

The work option raises two questions before you start. Is Claude Code safe to run? By default it asks before it edits a file or runs a command, and is Claude Code safe to use covers where that protection stops. Is it allowed? That is your company's call, not the tool's, and if IT has blocked it or given you something narrower, when your company blocks Claude Cowork goes through what still works.

The fix: pick your first real project from your own week, something you currently do by hand and are allowed to hand to an AI tool under your company's policy. If your sessions are more than a fortnight apart, put one short slot in the calendar between them, on that same project.

5. Test the version you just shipped

This one is not a beginner mistake, and the clearest case I have came from the person you would least expect: a QA professional, someone who tests software for a living.

On her first look at the live game she had built, she found a real bug. The gold medal arrived after 10 obstacles, and "it's supposed to be 100." The fix was pushed and the live site redeployed. Later in the same lesson she spent four minutes still seeing the old threshold. She was playing an earlier copy of the game that lived inside Claude as an artifact, not the deployed site. When it clicked, her verdict was immediate: "Oh my god. Big mistake."

The team lead's first deploy had the same shape from the other side. The link went live in a few minutes and served the old version, because the repository did not yet hold the new work. The site was real, just not current.

This is not the first month it has turned up in my notes, and it will not be the last, because modern tools make copies freely: a local preview, a hosted preview, an artifact, the live site. Before you decide a fix did not work, find out which copy you are looking at. A prompt worth keeping for it:

Before I test: which copy of this app am I looking at?
List every copy that exists (local, preview, artifact, live),
the address of each one, and which of them has the change
we just pushed.

The fix: before testing any fix, ask which copy has it and open that address yourself. Then retire the copies you no longer need, and close them. She had told Claude a few minutes earlier that the artifact was no longer needed. It was still there, and it was what she opened.

6. Know which half of the deploy is yours

Getting a first project online is where most beginners expect to be stuck, and they are stuck, just not where they predicted. Claude Code does far more of it than people expect, and then stops dead at a step only a human can take.

Two students who deployed for the first time this autumn hit the same split, in the same places:

The left column surprises people. One student found the sign-in code already sitting on his clipboard ("It put it in my clipboard already, which is crazy"), and the other pasted a nine-line build log into the terminal and got back the name of the setting to change. The right column surprises them more, because nobody tells you the deploy will stop halfway and wait for you to approve something in a browser tab.

There is a second lesson hiding in the left column. When one of them asked Claude Code to push his site, it first reported that the repository still needed creating and offered him the manual route. Told to go ahead and create it, it installed the tool it needed and did the whole thing. A lot of "Claude Code cannot do that" is really "Claude Code assumed you wanted to do that yourself."

The fix: before any deploy, ask: "Can you do this for me? List what you can do yourself and what I have to do by hand." Then stay at the keyboard while it runs, so you can do your half the moment it asks.

Start here

If you only act on one of these, make it the third. The course and the docs will teach you the tool, and they do it well. Nothing in them can make you open it on a Tuesday evening. A task with a finish line can.

1. Take Claude Code 101 this week, running each quickstart step on your own machine, with setup booked as its own sitting.
2. Pick one small project from your own week and write its first task as a sentence you can check, such as "this page is live" or "this report runs".
3. Ship it, then ask Claude which copy has your latest change and which deploy steps are yours, before you test anything.

How long does it take to learn Claude Code? More than one evening, and less than most people expect. Setup is the one fixed cost, which is why it gets its own sitting. After that, the QA professional had a game live online in her second lesson with Claude Code, and a second site live about half an hour after creating its folder in her third. Another student's site went live an hour into his third lesson, and in his fourth he was writing his own prompts. What stretched the timeline was never the tool. It was weeks between lessons with nothing built in them.

For the first session itself, step by step, the Claude Code tutorial for beginners is the longer walk-through. If the worry underneath all of this is that one request will break something you care about, read what one non-coder was actually afraid of, because it is rarely the tool. And if you would rather work through the path above with someone watching your screen, that is what our 1-on-1 Claude Code course is for, and a free Discovery Call will tell you whether you need it.

From the session logs of AI Tutor Code: 1-on-1 Python and AI tutoring for working professionals. The patterns above come from real students early in learning Claude Code, lightly anonymised.

Written by Michael Murr for AI Tutor Code: private 1-on-1 online tutoring for professionals learning Python, AI tools, Data Science, ML, and LLM engineering. 200+ students taught, 3,000+ hours delivered.