This chapter draws the line between writing instructions for a computer and teaching it from examples instead. Artificial intelligence is defined as the broad goal of getting machines to do things that look intelligent; machine learning is the specific technique of adjusting a program using examples rather than writing its rules by hand; deep learning is machine learning done with many-layered neural networks; statistics is the mathematics both borrow from for judging whether results can be trusted; and data science is the job of answering real business questions with whichever of these tools fits.
The core test offered for when to reach for machine learning: you can recognize a correct answer but cannot write down the rule that produces it. This is worked through with a spam filter built twice — first as a growing, self-defeating pile of hand-written rules and exceptions, then as a model trained on labeled examples, with the vocabulary of examples, labels, features, models, and fitting laid out along the way. From there the chapter sorts the field into four learning shapes — supervised, unsupervised, reinforcement, and self-supervised — and corrects the common assumption that "AI" means the chatbot, arguing that a finished conversational product hides every decision that actually determines whether a system can be trusted or debugged. It closes by naming what the daily work of this field really consists of: wrangling data, defining success, and hunting down why a number moved, with model-building as the smaller, more enjoyable slice in between.
A rapid tour through the summer's model releases: cheaper, longer-context models from OpenAI and Anthropic, a new Flash-tier release from Google detailed on the company's own blog, and a large permissively licensed open-weight model out of China tracked on sites such as this AI release tracker. Vendor benchmark claims — including one lab's assertion that a model sustained over two weeks of autonomous coding work — are flagged as leads to verify rather than facts to repeat. On the money and regulation side: Amazon's stake in OpenAI, semiconductor demand projections reported by outlets like CIO Dive, and a new phase of enforcement under the EU's AI Act, tracked directly on the European Commission's site, alongside emerging guidance on what scraped training data must satisfy under data protection law as discussed by firms such as Stephenson Harwood.
You already know how to make a computer do what you say. That is the skill you are bringing to this course, and it matters more than you might think. You can write a function. You can read someone else's code and work out what it does. You can find a bug by narrowing down where the truth stops matching your expectation. Every one of those habits transfers. Nothing here asks you to throw them away.
What this course asks is that you learn a second way of getting a computer to do something useful — one where you do not write the instructions at all.
That is the whole shift. It sounds small when you say it in one line. It is not small. It changes what your job looks like, what you spend the day on, and what counts as a bug. And it is the reason so many programmers bounce off machine learning on the first try. They come in expecting a new library and find a new way of thinking, and nobody warned them.
So let me tell you where this road goes, because a hundred chapters is a long climb and you deserve to see the shape of it before you start.
You will begin by building models on real data, fast, using tools other people wrote. Not because shortcuts are good, but because you need to see the thing work before the theory means anything. Then you will go down into the mathematics underneath it — linear algebra, calculus, probability, statistics, the Bayesian ideas most courses wave at and move past. We are going to sit in that material properly, because it is what separates someone who can run machine learning from someone who understands it. After that, the rest of the classical toolkit, the methods that quietly win real jobs. Then neural networks, built by hand before you are allowed near a framework. Then transformers, taken apart piece by piece, because that architecture runs the field right now. Then building real applications on top of language models. Then the operations work — deployment, monitoring, cost, the unglamorous engineering that turns a notebook into a product people depend on. And at the end, a fleet of AI agents that manages itself in production, which you built, and which you can explain top to bottom.
That last part is the goal. Not a certificate. A system.
Here is why I keep saying that. Nobody hiring for this work can tell, from a line on your resume, whether you understand anything. They can tell from a thing that runs. So every phase of this course ends with something you could show a person: a model on real data, a project you can defend, a deployed application. When you finish a phase, you have an artifact. That is the currency in this field. A portfolio gets you interviews; a certificate gets you into a pile.
Now, before any of that, we have to agree on words. Because five words get used almost interchangeably in public and they do not mean the same thing, and if you cannot separate them you will not be able to tell what a job posting is actually asking for.
Start with artificial intelligence. It is the widest of the five, and the oldest. Artificial intelligence is the whole effort to get machines to do things we think of as requiring intelligence when a person does them. Note what that definition does not say. It does not say how. A program that plays chess by searching millions of possible move sequences and scoring them with rules a human wrote is artificial intelligence. So is a system that reads a chest scan and flags a tumour after being shown a hundred thousand scans. Those two systems share almost no machinery. They belong to the same field because they aim at the same kind of target. Artificial intelligence is a goal, not a technique.
Inside that goal sits machine learning, and machine learning is a technique. Machine learning is the approach where you do not write the rule. Instead you show the computer examples, and a procedure adjusts the program until it does well on those examples. The rule still ends up existing — it lives in a pile of numbers inside the model — but no human wrote it, and often no human could read it back out.
Here is the sentence this whole chapter hangs on, and I want you to carry it with you for the next ninety-nine chapters: machine learning is what you reach for when you can recognise the right answer but cannot write down the rule that produces it.
Read that again slowly. Recognise the right answer. Cannot write the rule. Both halves have to be true. If you can write the rule, write it — a rule is faster, cheaper, easier to test, and it does not silently rot when the world changes. And if you cannot even recognise a correct answer when you see one, machine learning cannot help you either, because you would have nothing to show it and no way to check whether it was working.
Inside machine learning sits deep learning. Deep learning is machine learning done with neural networks that have many layers stacked one after another. Each layer takes what the previous layer produced and transforms it again. Stack enough of them and the early layers end up learning simple patterns while the later layers combine those into complicated ones. Nobody tells the layers what to look for. That is the point, and it is why deep learning took over problems like images, audio and language, where the useful patterns are far too tangled for a person to specify. It is a subset. Every deep learning system is a machine learning system. Plenty of machine learning is not deep learning, and some of the most useful models you will build in the next few months will have nothing deep about them at all.
Then statistics. Statistics is the mathematics of drawing conclusions from data when the data is incomplete and noisy. It is older than computing. It asks: given what I observed, what can I actually claim, and how confident am I allowed to be? That question is not decoration on top of machine learning. It is the foundation under it. When you measure whether your model is good, you are doing statistics. When you ask whether your model would still work on next month's data, you are doing statistics. Machine learning and statistics are not rivals, whatever the arguments online suggest. Machine learning borrowed its bones from statistics and then went off to build things at a scale statisticians of the last century could not have run.
And finally data science, which is the odd one out because it is not a technique at all. Data science is a job. A data scientist takes a question somebody in an organisation actually cares about — why are customers leaving, which of these shipments will be late, what changed last Tuesday — and answers it using whatever tool fits. Sometimes that tool is a machine learning model. Very often it is a careful chart and a clear head. Data science uses statistics, uses machine learning, sometimes uses deep learning, and spends an enormous amount of its time on things that are none of the above, like finding out that two systems have been recording dates in different formats for three years.
So the nesting, plainly. Deep learning sits inside machine learning. Machine learning sits inside artificial intelligence. Statistics is the mathematics all three of them borrow from. Data science is the day job that reaches for whichever of them the question needs.
I want to be honest about the edges, though, because they are genuinely blurry and anyone who tells you otherwise is selling something. Logistic regression is a hundred-plus years old, it is taught in every statistics department, and it is also one of the first machine learning models you will build in a few chapters. Is it statistics or machine learning? Both. The label depends on what you are using it for and who you are talking to. A statistician fitting it wants to know which factors matter and how sure we can be. An engineer fitting it wants accurate predictions on data it has never seen. Same equations, different question, different name. Do not waste energy policing those boundaries. Learn to hear which question someone is asking.
Now let me make the central idea concrete, because so far it has been words about words. We are going to build a spam filter. Twice.
First the way you already know how. You are a programmer, you have been handed a stream of incoming messages, and you have to decide for each one whether it is spam. Your instinct is to write the rule, so write it. You look at some spam. You notice a phrase that keeps showing up — some variation on winning a prize you never entered. Fine. If the message contains that phrase, flag it. You ship it, and it works. It catches a real amount of spam. This is a good day.
Then the spammers change the spelling. They swap a letter for a digit, or split the phrase with a stray character, and your rule sees nothing. So you add more phrases. Now you have a list of forty phrases, and you notice something uncomfortable: the list only grows. You are never going to delete an entry from it.
You look for a different signal and you find one. Spam shouts. It uses capital letters far more than a normal message does. So you add a second rule: if more than half the letters are capitals, flag it. Good. Except now you are flagging your colleague who types entirely in capitals when the build breaks, and a legitimate automated alert from a monitoring system, and a message that is mostly a stock ticker. So you soften the rule. Only count capitals if the message is longer than some number of words. You pick the number by guessing.
Links next. Spam pushes you somewhere. So you flag messages with links to domains you have not seen before. Except every newsletter anyone signs up for contains links to domains you have not seen before. So you need an exception list. So now you are maintaining a list of good domains alongside your list of bad phrases, and both lists only grow, and neither is ever finished.
Then the rules start fighting. A message with one suspicious phrase and no capitals and one known-good link — is that spam? Your rules say yes and no at the same time, so now you need a way to weigh them. So you give each rule a score and add the scores up and flag anything over a threshold. And here is the moment it collapses: where do the scores come from? You made them up. Where does the threshold come from? You made that up too. You are now sitting in front of a system with sixty hand-tuned numbers, and when you nudge one, something you fixed last month breaks, and you cannot tell which change caused it.
And the deepest problem is not any of that. The deepest problem is that you are trying to guess what the spammers will do next, and they get to see your filter and you do not get to see their plan. You are writing rules for a target that moves specifically to get away from your rules.
Feel that failure properly, because that feeling is the reason this field exists.
Now build the same filter the other way. Here is the thing you never lost sight of during all that misery: you can tell spam when you see it. Show you a message and you will classify it correctly almost every time. You just cannot write down how you did it. That is exactly the condition from our sentence. Recognise the answer, cannot state the rule.
So instead of stating the rule, you supply the answers. You gather a big pile of messages — tens of thousands, ideally — and each one comes with a mark saying spam or not spam. Maybe people already hit a report button on them. That pile is your raw material, and the pieces of it have names you will use for the rest of your career, so let us fix them now.
Each individual message in the pile is an example. One message, one example. You will also hear it called a sample or an instance, and they mean the same thing.
The mark on each example — spam or not spam — is the label. The label is the answer you already know. It is the recognition part of our sentence, written down and made countable.
But a model cannot work on a message. It works on numbers. So you turn each message into a list of numbers that describe it, and those numbers are the features. You might count how many times each word appears. You might record the fraction of capital letters, the number of links, the length of the message. Whatever you choose, you end up with each example represented as the same fixed list of measurements. Deciding what those measurements should be is a real craft, and it has a name — feature engineering — and we will spend proper time on it later in the climb.
Then you need a model. A model is a function with adjustable insides. It takes the features of one message and produces a guess. The simplest version: give every feature a weight, multiply each feature by its weight, add them up, and call anything above zero spam. That is it. That is a real model and it works surprisingly well on this exact problem. Notice what it looks like: a score built from weighted signals with a threshold. It looks like the hand-tuned monstrosity you just abandoned. The structure is nearly identical.
The difference is where the weights come from. And that is the last piece: the fitting procedure. Fitting is the process that adjusts the weights so that the model's guesses match the labels on as many of your examples as possible. It starts from weights that are wrong, measures how wrong, changes them a little in a direction that reduces the wrongness, and repeats. Thousands of times. It is a search — a search through possible settings for the ones that agree best with the answers you supplied. You will hear this called training, and you will hear the fitted result called a trained model, and later in this course you will derive the mathematics of that search and then write it yourself with no library at all.
We are not running any of that here. No code yet, no library call. That comes soon enough, and I want you holding the idea rather than the syntax.
Because look at what actually changed between the two spam filters. The parts are similar. The output is similar. What moved is your job.
In the first version, your job was to state the rule. Every improvement had to come out of your head, and every improvement had to be reconciled by hand with all the improvements before it.
In the second version, your job is to supply good examples and to decide how success is measured. That is all. You no longer say what makes a message spam. You say here are a hundred thousand messages and here is which ones were spam, and you say a mistake that lets spam through costs us less than a mistake that hides a real message, so weight it that way. Then the procedure finds the rule.
That is not less work. It is different work, and it fails differently. If your examples are bad, your model is bad, and it will be bad confidently and quietly. If your examples all came from last year, your model has learned last year. If you measured success with the wrong number, you will optimise hard toward something nobody wanted. Those are the bugs of this discipline, and none of them look like a stack trace.
Our spam filter is one shape of learning problem, and the field is organised into four of them, sorted by what the learning procedure gets to see.
Supervised learning is the one you just built. Every example comes with the right answer attached, and the model learns to reproduce those answers on data it has not seen. The spam filter is your anchor here — remember it, because most of the next thirty chapters live in this shape.
Unsupervised learning gets examples with no answers at all. It has messages but nobody said which are spam. So it cannot classify; instead it looks for structure — which messages resemble each other, which measurements move together, what the natural groupings are. You use it when you do not yet know what the categories should be.
Reinforcement learning gets neither labels nor a static pile of data. It gets an environment it can act in, and a reward that arrives sometimes, often long after the action that earned it. It learns by trying things and finding out what pays. That is how you train something to play a game or steer a process over time.
Self-supervised learning is the clever one, and it is the reason the last few years happened. It takes data with no labels and manufactures labels out of the data itself. Hide a word in a sentence and make the model predict it; the hidden word was always there, so the answer is free. Do that across an enormous amount of text and you get a system that has learned a great deal about language without a single human annotation. Every large language model you have used was built this way.
Four shapes. One sentence each for now; each one earns its own proper treatment later.
Which brings me to what the work actually feels like day to day, because your picture of it is probably wrong in a specific way.
You likely imagine choosing models. Reading about a promising architecture, implementing it, watching a number climb. That happens. It is genuinely satisfying. It is also the smallest slice of the week.
The largest slice is getting data into a usable shape. That sounds like a chore and I am not going to dress it up, but I will tell you why it is the real work rather than the overhead. The pile of examples is the entire source of what your model knows. So everything wrong with the pile becomes something wrong with the model. Two systems recorded the same event with different timestamps. A field changed meaning eighteen months ago and nobody wrote it down. Some rows have missing values and the missingness is not random — it happens more often for exactly the cases you care about. Half your labels came from one annotator having a bad week. Every one of those is a modelling problem wearing a plumbing costume, and you will spend more time there than anywhere else.
The second slice is deciding what counts as success. This is where you earn your keep, and it is barely taught anywhere. A spam filter that catches ninety-nine percent of spam sounds excellent until you learn it also quarantines one legitimate message in fifty, and one of them was a job offer. Whether that trade is acceptable is not a mathematical question. It is a question about the people using the thing. Your job is to turn their answer into a number the fitting procedure can chase, and to notice when the number you chose has started to drift away from what anyone actually wanted.
The third slice is finding out why the number went down. Not why it is low — why it moved. Something changed, and it could be your code, your data, the world, or your measurement. This is debugging, and your existing instincts do transfer, but the search is harder because the system has no single place where it decided anything.
Which leaves modelling as the thin, enjoyable band in the middle. Get comfortable with that. The people who ship working systems are the ones who made peace with it.
Now the misconception, and it is the big one for anyone arriving in this field today.
The belief is that artificial intelligence means the chatbot. And therefore that learning artificial intelligence means learning to talk to one well.
Here is why that fails. Trace the chatbot back through everything we just laid out. It is one product, built on one branch of the field — deep learning — using one paradigm — self-supervised learning on text — with an extra alignment stage bolted on afterward to make it behave. That is a narrow slice of a very large field. It is also, importantly, a finished surface. Someone made every decision that mattered before you typed anything: what data it learned from, how the text was chopped up, what shape the network took, how success was measured, what behaviour got rewarded and what got suppressed. You are downstream of all of it.
And that is the part that hurts you. When the chatbot is confidently wrong, the person who only knows the product has nothing to say beyond noticing that it is wrong. They cannot tell you whether it is wrong because the pattern was absent from the training data, or because it was present but rare, or because the sampling is introducing randomness, or because the way success was measured rewarded a confident answer over an honest one. And so they cannot fix it, cannot build around it, and cannot tell you in advance where it will break — which is the thing anyone paying for this work actually needs.
Here is the tell, and you can run it on yourself, today, on any system you use. Ask: what data did this learn from, and how did anyone measure whether it worked? If you cannot answer both, you are using the system, not understanding it. That is a perfectly fine place to stand — but it is not a job, and it is not where this course is taking you.
Everything you build from here will have both answers. You will know what went in, and you will know how it was scored, because you will have chosen both.
That is the map. This chapter builds on nothing — it is the ground floor, and you needed no prior knowledge to stand on it. It unlocks everything, because every chapter after this one will use these five words and these named parts, and will assume you can look at a problem and say whether it wants a rule or wants examples. Next, we go back and find out where all of this came from — because the ideas you just met were not obvious, and the story of people arguing their way toward them will tell you a great deal about why the field looks the way it does.
Before we leave, the perishable part of the show.
The frontier moved a lot this summer, mostly in the same direction: more context, lower prices, and longer autonomous runs. In early July, OpenAI shipped a three-tier family of models, with the smallest priced at twenty cents per million input tokens and the largest at five dollars in and thirty out, all sharing a context window a shade over one point one million tokens. Their own reported figures put the top tier near ninety-two percent on a terminal-based agentic coding benchmark, and around forty-seven percent on a much harder general reasoning exam. Those are vendor-reported numbers, which is exactly the category the charter for this course tells you to treat as a lead rather than a fact — check them against independent evaluation before you believe them. In early August the same lab optimised its top model in the consumer product and opened the cheapest tier to free users. Late July brought Anthropic's Opus 5 at five dollars in and twenty-five out with a one-million-token window, and in mid-August they made a lower Sonnet price permanent. Google shipped a Flash-tier model in late July and another in mid-August at identical pricing, seventy-five cents in and three dollars seventy-five out.
Two things there matter more than the horse race. First, the price of a million tokens is now a design constraint you will reason about explicitly, and it is falling fast enough that architecture decisions you make on today's prices should be written to survive tomorrow's. Second, watch what the benchmarks are measuring. Agentic coding scores are about whether a system can run for a long time without a human correcting it — Alibaba claimed its largest model sustained sixteen days of autonomous work on a software project, which is unconfirmed by third parties and should be held loosely, but the direction is real. That capability is the whole subject of this course's final phase.
On the open-weight side, Alibaba released a roughly twenty-eight-billion-parameter dense model in mid-August under a permissive Apache licence. That is the interesting one for a learner. A dense model at that size is something you can actually inspect, fine-tune, and run yourself, and a permissive licence means you can put the result in a portfolio without a legal argument. Meta and DeepSeek also shipped in the same window, which tells you the open tier is not conceding.
On money and rules: Amazon completed a fifty-billion-dollar investment in OpenAI for a five percent stake, and an industry analyst projected that data-centre demand pushes global semiconductor revenue past one point six trillion dollars this year, with more than half of that in memory. In Europe, an amending package on artificial intelligence took effect at the end of July, adjusting the timelines of the bloc's AI Act, and from the second of August the Commission and its AI Office began formally enforcing core transparency obligations with direct supervisory powers over general-purpose models. There is also draft guidance out on what web scraping for training data has to satisfy under data protection law. If you intend to work on production systems, that last item is not somebody else's department — the question of where your training data came from is about to have a paper trail attached to it, and you have just learned why that question was always the important one anyway.