How to learn with this course

On Friday evening, Arjun opens the course page and scrolls. And scrolls. Around thirty-five modules, around two hundred lessons, seventeen projects. He feels the familiar panic of a gym membership bought on the first of January.

Then he has an idea. “I will binge it,” he tells Priya. “This weekend I do the first three modules. By Monday I’ll be a month ahead.”

Priya does not look up from her laptop. “Tell me how it goes.”

On Saturday he reads for nine hours straight, fuelled by Crumb’s day-old croissants. He clicks “mark complete” fourteen times. The progress bar moves satisfyingly. On Sunday he rests, proud.

On Monday morning Priya asks him, casually, “What is a context window, and why does it matter for the support bot?” Arjun opens his mouth. Something about… windows? Tokens? He remembers reading it. He remembers the diagram was blue. He cannot explain it. Later he retakes the quiz for that lesson and scores one out of three. Then he tries to write a ten-line API call from memory and cannot remember where the system prompt goes.

Fourteen lessons marked complete. About two ideas actually learned.

Why nine hours of reading taught Arjun almost nothing

Priya pulls up a chair. “How did you learn to make the sourdough?” (Arjun is famous at Crumb for his weekend sourdough.)

“I made it badly. Six times. The first one was a brick.”

“Did you read about sourdough first?”

“A bit. But reading told me what hydration means. Making it told me what 65% hydration feels like in my hands.”

“And if you had read six sourdough books in one weekend and baked nothing?”

He sees where this is going. “I would know all the words, and I would still make a brick.”

“That is what happened on Saturday,” Priya says. “Reading feels like learning because everything makes sense while you are reading it. Recognising an idea is easy. Producing it from memory, or using it to build something, is a different and much harder skill, and it is the only one that counts at work. Two things build it: practice spread over time, and pulling ideas out of your own head instead of rereading them.”

Both points are well supported by decades of research on how people learn. Spreading practice over days and weeks (spaced practice) beats cramming the same hours into one sitting. And testing yourself (retrieval practice, like the quizzes and exercises here) beats rereading. The course is built around both.

One lesson, done properly

Priya suggests he redo just one lesson properly, the one on tokens from Module 01, and time every part. Here is what his Monday evening session looked like, from 8:00 to 9:30 p.m.:

Ninety minutes for one lesson, not fourteen lessons in nine hours. But two days later, when Priya asked him how many tokens a typical support email uses, he answered straight away: “About 180. Hindi ones use more, nearly double.” He knew because he had measured it himself.

His learning log entry that night:

## Mon 9 Nov - Module 01: Tokens
Did: counted tokens in 5 support emails. Avg ~180 tokens. Hindi email: 340 tokens for similar length!
Confused by: why Hindi needs more tokens. (Answer: tokenizer trained mostly on English text.)
Broke: passing None instead of a string -> TypeError. Remember to check inputs.
Quiz: 3/3.

How the course is put together

Now that he knows how to study, Arjun wants to understand the map he is studying from.

Two parts, six months. Part 1 (months 1 to 5) is AI engineering: building products on top of existing models, from your first chatbot through RAG, agents, MCP and production. Part 2 (month 6) is deep learning foundations: the maths, PyTorch, neural networks, transformers from scratch and fine-tuning. About 17 projects run through both.

Phases and modules. Modules are grouped into phases (Orientation, Foundations, Building with LLMs, Retrieval and RAG, Open models, Agents, Production, Deep learning, Portfolio) so you can see where you are on the map. Numbered modules (“Module 07”) follow the original syllabus section by section. A few have a label instead of a number: Start here (you are here), the Developer Toolkit, and the portfolio finale. They fill gaps a complete beginner would fall into.

Three kinds of page.

How the tracker works

The course page keeps track of your progress. Here is exactly what it does, and what it does not.

• Mark complete. Each lesson ends with a button to mark it complete; your module and course progress update straight away. Use Arjun’s rule: click it after you have done the exercise and the quiz, never just because you scrolled to the bottom. The bar is only useful if it is honest.
• Saved in this browser only. Progress is stored in your browser’s local storage on this device. There is no account and nothing is sent to a server. So it does not follow you to your phone or another laptop, a private or incognito window starts empty, and clearing your browser’s site data erases it. If you study on two devices, pick one as your “official” tracker.
• Quizzes. Most lessons end with three questions. They are not graded and nobody sees your score. After you answer, you see why the right answer is right. Treat a score of one out of three as a signal: reread, redo the exercise, then retake it tomorrow.
• Milestone checklists. Labs and projects come with a checklist of five to eight milestones, like “Load and chunk the transcripts”. Tick each off as you finish it. A ten-hour project feels very different as six steps of under two hours each.
• The glossary. Every technical word in the course has an entry in the glossary: a one-line definition, a longer explanation, an everyday analogy and a link to the lesson that teaches it. When a word feels fuzzy, look it up instead of guessing.
• The “Beyond the syllabus” badge. Some lessons carry this badge. They were added to fill gaps a beginner would hit: most of this Start Here module, the whole Developer Toolkit, and extra lessons inside later modules. If you already know a topic, take the quiz first; if you pass comfortably, skim the lesson and move on.

A week that works

The course is designed around 8 to 10 hours a week for about 26 weeks: roughly 210 to 260 hours in total. Here is the rhythm Arjun settled on, which many people find sustainable alongside a job or studies:

That is about 9 hours, with Wednesday and Friday completely off. Rest days are not wasted; that is when spaced practice does its work.

Do the arithmetic once so the plan feels real. About 200 lessons and labs at roughly an hour each with practice is 200 hours. Seventeen projects, many of them several hours long, are spread across the same weeks, which is why the Saturday block matters. If you have less time, stretch the course to nine or twelve months. Finishing slowly beats quitting fast. If you have more time, go faster, but never by skipping the projects.

When you get stuck: reading the error

You will get stuck, often. Everyone does, including Priya. Being stuck is not a sign you are bad at this; it is most of the job. What matters is having a routine instead of staring at the screen.

On Tuesday, Arjun runs his first API script and gets this:

Traceback (most recent call last):
  File "/Users/arjun/crumb-lab/main.py", line 1, in <module>
    import anthropic
ModuleNotFoundError: No module named 'anthropic'

He reads it top to bottom, panics at “Traceback”, and starts searching the internet. Priya points at the screen. “Read Python errors from the bottom up. The last line is the actual error. The lines above it say where it happened.”

The last line says Python cannot find a library called anthropic, so it was never installed in this project. The line above says it happened on line 1 of main.py. The fix is one command, uv add anthropic, which you will learn in the setup lab. Thirty seconds instead of thirty minutes.

Fifteen minutes later he gets another:

anthropic.AuthenticationError: Error code: 401 - {'type': 'error',
'error': {'type': 'authentication_error', 'message': 'invalid x-api-key'}}

Bottom line again: authentication failed because the API key is invalid. 401 is the web’s standard code for “I do not know who you are” (you will meet these codes in the Developer Toolkit). The key was wrong, or not loaded. He had copied it from the provider’s page with the last few characters cut off.

Here is the full routine, in order:

1. Read the error from the bottom up. The last line names the problem; the lines above say where.
2. Explain it out loud. Describe the problem line by line to a rubber duck, a pet or an empty chair. Programmers call this rubber-duck debugging, and it works embarrassingly often.
3. Shrink the problem. Make the smallest piece of code that still shows the bug. Half the time you find the bug while shrinking.
4. Check the docs. Every lesson’s “Go deeper” links to official documentation. Library APIs change fast; the docs are the source of truth.
5. Ask an AI assistant, well. Paste the exact error, the relevant code and what you already tried. Then verify the answer: models can hallucinate, confidently suggesting a function or setting that does not exist.
6. Use the 30-minute rule. Stuck for 30 minutes with no progress? Change something: take a walk, ask a person, or move on and come back tomorrow.
7. Ask humans with a good question. Say what you are trying to do, what you expected, what happened instead (with the exact error), and what you tried. Good questions get fast answers.

A word on AI assistants, since this is an AI course. Use them as a tutor, not a ghostwriter. “Explain this error” or “why does this line exist?” is excellent. “Write the whole project for me” means you learn to read code, not write it, and the first technical interview will show it.

Where this plan breaks

Priya has watched many people start courses like this. She tells Arjun the four ways it usually goes wrong, so he can see them coming.

The week-three dip. The excitement of the first two weeks fades, and the material gets harder at the same time. Expect it. Lower the bar, not the habit: on a bad week, one 30-minute session still keeps the chain alive.

Tutorial hell. Following lessons feels productive, and you can follow them forever without ever building anything on your own. The projects are the cure. If a project feels too big, build an uglier, smaller version of it first.

Surprise bills. Most lessons call paid model APIs. For learning, costs are usually small if you keep prompts short, keep max_tokens low and use cheaper models while experimenting. The danger is a bug, such as a loop that calls the API ten thousand times. The setup lab shows you how to set a spending limit with each provider so a mistake cannot become a large bill. Some providers, like Google’s Gemini, have a free tier that covers many exercises, and in Module 20 you will run open models on your own computer for free.

Lost progress. A cleared browser wipes the tracker. Your learning log and your GitHub repositories do not disappear, which is one more reason to keep both.

Try it yourself

Make your plan, in writing, before you start the next lesson.

1. Open your calendar and block four study sessions a week for the next four weeks. Name them like meetings: “Learn AI: lesson”, “Learn AI: project”.
2. Create a file called learning-log.md somewhere you will see it. Write today’s date and one sentence: why you are doing this course.
3. Decide which device and browser hold your “official” progress.
4. Write down your plan for the week-three dip: the smallest session you will still do on a bad week.

# Learning log

## Why
I want to build our support assistant myself instead of waiting for a vendor.

## Plan
Mon/Tue/Thu 8-9:30 pm, Sat 10 am-1 pm. Laptop Chrome is my tracker.
Bad-week minimum: one 30-minute session, one quiz.

## Wed 4 Nov
Finished Start Here lessons 1-5. Confused by: embeddings vs vectors. Will see in Module 07.

Common mistakes

• Binge, then burnout. Three big weekends, then nothing for a month. Steady, smaller sessions win.
• Marking lessons complete after reading. The progress bar becomes a lie, and you stop being able to trust it.
• Watching instead of doing. Videos and lessons feel like progress. Only building is progress.
• Skipping the projects. Projects are where separate ideas join up, and they are what employers look at.
• Staying stuck in silence. Two hours on one error without asking anyone is not grit; it is a lost evening.

Recap

• Reading feels like learning; producing and building is learning. Space your practice and test yourself.
• Do each lesson properly: read, type, break, change, quiz, log, then mark complete.
• The tracker saves progress only in this browser; quizzes are for you; milestones turn projects into checklists; the glossary defines every word; “Beyond the syllabus” marks added lessons.
• Aim for about 8 to 10 hours a week over six months, in regular sessions with rest days.
• When stuck: read the error bottom-up, shrink the problem, check the docs, ask well, and use the 30-minute rule.

On Friday, Meera asks Arjun how his course is going. He shows her the progress bar: it has gone down. He un-marked twelve of his fourteen lessons.

“That looks like failure,” she says.

“It is honest,” he says. “I read fourteen lessons last weekend and remembered two. Now I do one lesson properly each session: read it, type the code, break it, test myself, write it down. Four sessions a week, about nine hours. Slower on the bar. Much faster in my head.”

Meera thinks about her bakers. “Like an apprentice. You do not learn lamination by watching.”

“Exactly,” says Priya. “And an apprentice needs a workbench. Before Monday, Arjun, we set up yours: Python, an editor, git, and an API key that cannot bankrupt Crumb.”

Go deeper

• The Python tutorial: if you are new to programming, start reading it alongside the course; Module 00 covers the parts you need.
• Course glossary: bookmark it now.