This isn't a course that hands you everything. It's a map. The real teaching is done by the best free resources on the internet. I just put them in the right order and explain the ideas in plain language first.
No jargon for the sake of it. Every hard concept gets a simple version before anything else. And one thing matters more than any video: you have to do it yourself.
Due to my busy work schedule, my progress on a detailed intuitive explanation with images will be slow, but it will be rolling release! In the meantime, try to get a headstart here and I will do my best to deliver a straight forward and beginner-friendly e-book :3
The real thing a degree gives you isn't the facts. It's the ability to teach yourself anything, for the rest of your life.
This field never stops moving. What's cutting-edge now will be ordinary in a year, so staying current isn't optional, it's the job. Learning how to learn on your own is the one skill that never goes out of date.
And this is free because I learned everything for free. Every resource on this page is one I actually used. If it was free for me, it should be free for you too. No paywall, no catch.
The order is deliberate. Maths first, because everything later is built on it, with code running alongside it, because you can't practise any of this without being able to write a script. Then data science and machine learning, where those ideas turn into working predictions. Then deep learning, which is the same ideas stacked higher. Then LLMs, last on purpose. Skipping ahead feels faster but it's how people get stuck, ending up copying code they can't debug.
You don't need equal amounts of each. In practice the maths that earns its keep is roughly half statistics and probability, a third linear algebra, and a smaller slice of calculus. So don't burn months on calculus before you've touched a dataset.
Two things live somewhere people don't expect. Reinforcement learning sits at the end of deep learning rather than with the other machine learning methods, because anything you'd actually build with it uses a neural network. And deployment sits inside data science, because a model nobody can use isn't finished.
The language underneath everything. Start with statistics and basic algebra, build up gradually. You'll come back here often, and that's normal.
Python, properly, once. Enough to write a script, read someone else's, and work out why yours is broken. Run this in parallel with the maths.
Where maths meets real data. Clean it, explore it, let a machine find the patterns, then ship the result. This is most of the actual job.
The same machine-learning idea, stacked into layers. Neurons, then vision, sequences, transformers, and finally learning from consequences.
The tool you'll use daily, and the one you'll build with. Prompting, the API, context and cost, then agents that use tools on your behalf.
Not a phase you reach, a habit you start on day one. Small projects, finished and put somewhere public, teach more than the next course.
An autodidact is just someone who teaches themselves. It sounds intense, but it's a habit, not a talent: read or watch a little, then immediately try it with your own hands before moving on.
This is the habit that carries you through a whole career, not just this course. New models and tools arrive constantly, and nobody hands you a class for each one. The people who last are the ones who can pick up something new on their own, again and again.
Watching someone else solve a problem feels like learning, but the understanding doesn't stick until you get stuck and work your way out. Every resource below is something to use actively. Pause the video and code along, redo the maths on paper, break the example and fix it. The struggle is the part that teaches. If a section feels too hard, drop back one level rather than pushing through confused.
Don't do these one at a time, front to back. Run them in parallel and build up together. Khan Academy is the spine here because it starts gently and never assumes you remember the last thing. The plan below is the exact order to climb.
Read: Why you need to understand the maths behind ML (intuitive understanding)The most useful maths for this whole field, and the one beginners skip. It's how you describe data, measure uncertainty, and tell a real pattern from random noise. Begin it alongside Algebra 2, since it doesn't need heavy maths to start.
Bring this in at step 03, next to Calculus 1. It's the maths of vectors and matrices, and since data is stored as grids of numbers, this is how data physically moves through every model.
The smallest slice of the three, so don't let it intimidate you or eat your whole schedule. Climb Pre-calc → Calc 1 → Calc 2. You mainly need the core idea behind how a model improves itself, not every technique.
Run this next to the maths, not after it. Maths without code is theory you can't test; code without maths is copying things you don't understand. Together they're the whole foundation.
You are not training to be a software engineer. The bar is lower than it sounds: write a script from scratch, read someone else's and follow it, and work out why yours is broken without panicking. Python is the only language you need, so learn it properly here, once, and every section after this can spend its time on ideas instead of syntax.
Read: Guide to learning how to code in the sea of vibecodersEvery program ever written is made of about six ideas, and you can learn all of them in a fortnight. Pick one of the resources opposite and finish it end to end rather than sampling all three. Typing the examples out yourself is not optional; that's the part that builds the skill.
Named boxes holding numbers, text, or true/false. Most beginner bugs are a value being a different type than you assumed.
If this, do that. Conditionals pick a branch, loops repeat until a condition ends them. This is where the logic lives.
A block of work with a name, inputs and an output. Write it once, call it anywhere. Small functions are easier to fix than one long script.
Lists, dictionaries, sets. Choosing the right container makes half your problems disappear before you write any logic.
Code being broken is the normal state of code. Nobody writes it correctly first time, and the gap between a beginner and a professional is mostly how calmly and quickly they find the mistake. This is a skill you can practise directly, and almost nobody does.
Slowly, out loud if it helps. Most errors say exactly what's wrong. Googling the last line verbatim solves a huge share of them.
Print the value just before the crash. Then just before that. You're narrowing down where your belief and the truth split apart.
Cut the code down until only the broken bit is left. A ten-line failing example is easy to fix; a 300-line one isn't.
Explain the code line by line to an object, a pet, or a chat window. You'll usually catch it mid-sentence.
The stuff no course teaches and every job assumes. The terminal is how you actually run things; Git is how you save your work in a way that lets you undo mistakes and show your history. Learning both early makes everything afterwards less frightening.
An LLM will happily hand you working code for anything in this section. That's exactly the problem. The understanding you're building here comes from being stuck and getting unstuck, and accepting a finished answer skips the only part that was doing the teaching.
There's a difference between a tutor and a ghostwriter. Asking it to explain an error, or to review code you already wrote, is a tutor. Asking it to write the function is a ghostwriter, and you'll feel the hole later, usually the first time something breaks in a way you can't read. Once you can genuinely follow every line it produces, use it freely; phase 05 is all about that.
This is where most of the real work happens. Surprisingly little of the job is inventing clever algorithms. Most of it is getting data, cleaning it, looking at it properly, applying tools that already exist, and then getting the result somewhere people can use. Learn it in this order.
You know Python from phase 02. This is the data dialect of it: NumPy for fast arrays, Pandas for tables, SQL for getting data out of a database in the first place. Beginners skip SQL and regret it, because almost every real job touches it.
The unglamorous skill that quietly decides everything. Real data is messy: missing values, typos, wrong formats, three different spellings of the same city. A model fed bad data gives bad answers, no matter how fancy it is.
EDA is the habit of properly looking at a dataset before you trust it with anything. You count things, plot things, and go hunting for whatever is weird. It's the cheapest step in the whole process and it catches the mistakes that would otherwise quietly ruin a model three weeks later.
It also loops back into cleaning. You explore, you find something broken, you clean it, you explore again. Expect to go round that circle several times before you train anything.
How many rows and columns, what type is each, how much is missing. Always look at the raw rows too, summary statistics hide a lot.
Plot one column at a time. Is it skewed, does it have two humps, are there impossible values like a negative age or a 300-year-old customer?
Then plot pairs of columns. And remember: correlation is not causation. Two things moving together is a question, not an answer.
The killer bug. A column that secretly contains the answer makes your model look perfect in testing and useless in reality. Ask where each column came from.
Here's the secret that makes all of it click, and it's worth reading twice. A machine learning model is just a maths function. Numbers go in, a prediction comes out. "Training" is nothing more than searching for the version of that function that fits your data best.
How important each input is. You can't change the inputs themselves, but you can change how much each one counts. An input multiplied by 5 matters far more than one multiplied by 1.
A baseline that shifts the whole result up or down. It lets the formula start from the right place before the inputs adjust it.
Most of what you'll meet here is supervised learning, where every example comes with the right answer attached, plus some unsupervised methods that find structure with no answers at all. There's a third kind, reinforcement learning, which learns from consequences instead. It's over in phase 04, and the module there explains why it's waiting for you at the end of deep learning.
Models affect real people. They can inherit bias from their data and make unfair decisions at scale. Knowing how to spot and reduce that harm is part of doing this work responsibly, not an optional extra.
A model sitting in a notebook on your laptop isn't finished, it's a sketch. Deployment is everything that turns it into something other people can actually use: packaging it, putting it behind an address your app can call, and watching it afterwards so you notice when it starts going wrong.
MLOps is the name for that whole discipline. It borrows most of its ideas from normal software engineering, with one extra headache: a normal program breaks loudly, but a model degrades quietly, still returning confident answers that are slowly getting worse. Almost nothing you learn here is hard, and almost nobody does it, so it's the fastest way to look like an engineer rather than a hobbyist.
Wrap the model in a small web API so anything can ask it for a prediction. FastAPI plus Docker is the standard first stack, and it's a weekend's work.
Same data, same code, same settings, same model. Version all three, or you'll never be able to explain why last month's model was better.
The world keeps changing; your model doesn't. Drift is when incoming data stops resembling what it trained on. Watch the inputs and the predictions, not just whether the server is up.
The boring automation: collect → clean → train → evaluate → deploy, on a schedule, without you. Boring is the point.
The piece of deployment infrastructure that arrived with modern AI, and the reason it belongs here rather than in the LLM section: it's a database question first and a model question second. An embedding is a list of numbers a model produces to stand for a thing, arranged so that similar things end up close together. A vector database stores millions of them and answers "what's nearest to this?" in milliseconds.
That one trick powers semantic search, recommendations, deduplication, and the retrieval half of retrieval-augmented generation, which is how you give a language model access to documents it was never trained on. You'll meet the other half in phase 05.
A fixed-length list of numbers produced by a model. Similar meaning, similar numbers, and it works for text, images or products alike.
Nearness stands in for relatedness. Cosine similarity is the usual ruler: it compares direction rather than size.
You can't embed a whole book usefully, so you split it into passages first. How you chunk is the single biggest quality lever in a retrieval system.
Comparing against every vector is too slow at scale, so these databases use approximate nearest-neighbour indexes: a sliver of accuracy traded for enormous speed.
One idea unlocks this entire section, so sit with it before any model name. You already know a machine learning model is just a maths function. Deep learning is what happens when you stack many of those functions on top of each other, so the output of one becomes the input of the next, layer after layer.
Stacking lets the model learn patterns far too complicated for a single formula. That's the whole trick. Everything famous, from the vision models to the language models, is this same idea arranged in different shapes.
Learn these before any specific model. They're the building blocks every deep learning system shares, and they're simpler than they sound.
One tiny maths function: it takes inputs, multiplies each by a weight, adds a bias, and passes on a single number. That's all a neuron is.
A small step that lets the network bend and curve instead of only drawing straight lines, so it can learn complicated patterns.
Neurons lined up side by side, then stacked. The output of one layer feeds the next: functions feeding functions.
How the network learns from mistakes: it traces the error backwards and nudges every weight a little in the direction that reduces it. Repeat millions of times.
The models that see. They're built for images, where what matters is the pattern in a patch of nearby pixels: an edge, a corner, eventually a face.
Models for data where order matters: text, speech, time series. They read one step at a time and carry a little memory of what came before.
The architecture behind modern language models and most of today's AI. Instead of reading strictly step by step, a transformer looks at all the words at once and learns which ones to pay attention to.
Everything so far learned from an answer key: here's the input, here's the correct output, minimise the difference. Reinforcement learning throws the key away. An agent acts in an environment, receives a reward or a penalty, and gradually works out which behaviours pay off. It's how you teach something to play a game, control a robot, manage a warehouse, or route traffic.
Why it's here and not back in phase 03. Textbooks list it as the third branch of machine learning, next to supervised and unsupervised, so it would sit fine there. But anything you'd actually build today uses a neural network as the agent's brain, so it only really makes sense once neurons and gradients are second nature. It also sets up the next section: chat models are tuned with reinforcement learning from human feedback, and reasoning models are trained by rewarding answers that turn out to be checkably correct. This module is the bridge between the two halves of modern AI.
The thing making decisions, and the world it acts on. The environment hands back a new situation and a score after every move.
One number saying "that was good" or "that was bad". Designing it badly is the classic failure: the agent optimises exactly what you measured, not what you meant, and will happily cheat.
The strategy: given what I can see, what do I do? In deep RL the policy is a neural network, which is the whole reason this module waits until now.
Take the reward you already know about, or gamble on finding a better one? Every RL algorithm is a different answer to that trade-off.
Large language models like ChatGPT and Claude are the tools you'll actually reach for every day, both to learn faster and to build things. Used well, an LLM is like a patient tutor who never gets tired of your questions. Used badly, it quietly teaches you wrong things. And you'll be surprised to know that most apps with built in chatbots are just LLM wrappers with a prompt thrown at it to take the role of the platforms help bot lol
The skill isn't just typing a question. It's knowing how to ask, how to check the answer, and how to plug a model into your own code. Learn it last, on purpose, because it's most useful once you understand enough to spot when the model is wrong.
The fastest way to get unstuck. Paste an error, ask it to explain a concept five different ways, or have it quiz you. But it can sound confident and still be wrong, so treat every answer as a smart friend's guess, not gospel.
Just a fancy name for asking clearly. The model can only work with what you give it, so the more specific you are about the goal, the format, and any examples, the better the answer. This is a real, learnable skill that makes everything else easier.
This is how you go from typing in a browser to building your own apps. An API is just a way for your code to send a message to the model and get a reply back, the same conversation, but done in Python instead of a chat box. You send a list of messages, you get a message back. That's the entire shape of it.
One fact explains almost everything else in this section: the API is stateless. The model remembers nothing between calls. A "conversation" is an illusion your code creates by re-sending the whole history every single time. Cost, context limits and caching all follow from that.
The request is a list of turns: a system instruction that sets standing rules, then alternating user and assistant messages. Building a chatbot means appending to that list.
Models read in chunks of characters called tokens, roughly three-quarters of a word each. You're billed per token in and per token out, and every limit is measured in them.
How much randomness in the wording. Near zero for extraction and classification, higher for creative work. It isn't an intelligence dial.
Receive the reply piece by piece as it's generated rather than waiting for all of it. Same output, far better to sit in front of.
Two more things you'll want almost immediately. Structured output: ask for JSON matching a shape you define, and you get something your code can use directly instead of prose you have to pick apart. Failures: networks time out and rate limits get hit, so wrap calls in a retry that waits a little longer each attempt. And keep your API key in an environment variable, never typed into the file.
Two questions hit every LLM project in its first week: how much can I show the model, and why is the bill so big? Both come back to tokens, and both have tidy answers.
The context window is the model's desk. Everything it can see at once has to fit on it: your system prompt, the entire conversation so far, any documents you pasted in, plus room for the reply it's about to write. Bigger is not automatically better either. Fill a window with junk and answers get worse, not better, so deciding what earns a place on that desk is the real skill. People call that context engineering, and it's where prompt engineering grows up.
Then caching. If the start of your prompt is identical on every call, a long system prompt, a style guide, a document you keep asking about, you're paying the model to re-read it every single time. Prompt caching lets the provider keep that processed opening warm, so repeat calls are dramatically cheaper and noticeably faster. There's one rule that makes it work: stable content first, changing content last. Caching matches on the prefix, so a single edited character near the top throws away everything after it. Put a timestamp at the front of your prompt and you'll never get a cache hit at all.
Measured in tokens and shared between what you send and what comes back. When a chat outgrows it you must summarise or trim the old turns, not just hope.
Reuse the processed prefix of a repeated prompt. Huge win for chatbots over a fixed knowledge base, or agents with long tool definitions. Order your prompt stable-to-variable.
If you don't need the answer this second, batch APIs run jobs asynchronously at a steep discount. Ideal for bulk classification, backfills and evals.
Measure tokens per request before you scale anything. Then route: a small cheap model for the easy steps, the expensive one only where it earns its place.
A chatbot answers. An agent does. The difference is one loop. You give the model a goal and a set of tools it can call, search the web, read a file, run code, query the vector database you built in phase 03, and then let it run. It asks for a tool, your code executes it, you hand back the result, it decides what to do next. Repeat until the job's done or you stop it.
Notice who does what there. The model never runs anything itself; it only ever asks. Everything around it, the tool definitions, the code that actually executes them, the memory, the file access, the permission checks, the loop itself, is the harness. This is the part you build, and when people say an agent is good, they usually mean somebody wrote a good harness. The model was the same one everyone else has.
Loop engineering is the design work inside that cycle. What goes back into context after each step, what gets summarised or dropped, when to stop, what happens when a tool errors or the model starts going round in circles, and how much you're willing to spend before you pull the plug. It's unglamorous and it's most of the job.
Functions you describe in plain language: a name, what it does, what arguments it takes. Write those descriptions as carefully as your prompt, because that's all the model has to go on.
The scaffolding around the model: tool implementations, memory, permissions, retries, logging, spend limits. The thing you're actually building.
Think, act, observe, repeat. Every hard agent question is about this cycle: what's in context, when does it stop, what happens when a step fails.
Agents fail in ways that look fine. Keep a set of tasks with known-good outcomes and re-run them every time you change the prompt or the loop, or you're just guessing.
Two pieces of advice worth more than any framework. Most problems don't need an agent: one good prompt, or a fixed chain of two or three calls, is cheaper and far more predictable. And when you do build one, give it the fewest tools that can do the job, plus a hard cap on steps and spend. An agent with twelve tools and no ceiling is a bill with a personality.
I built this because everything I learned, I learned for free. There's no paywall coming, and you never have to give a thing to use any of it.
But if it helped you, and only if you can comfortably spare it, a small tip helps me keep making free things and keeps learning accessible for the next person. Completely optional. No pressure, no hard feelings.
You don't need to finish every resource before you start making things. Learn a little, build a small project, get stuck, look it up, keep going. That loop, not any single course, is what turns you into someone who can do this. Questions, or want to share what you've built?