What Is Machine Learning, Actually?

the shift: rules you write vs. rules you fit

Say you want to flag CI pipeline runs that are likely to fail, before they finish, so a slow test suite can be skipped and the runner freed up. Traditional programming means you sit down and write the rule yourself: if the diff touches more than 500 lines, or if it changes a file under core/, or if the last three runs from this author failed, flag it. You're the one deciding what matters and how to weigh it.


def will_probably_fail(run):
    if run.lines_changed > 500:
        return True
    if any(f.startswith("core/") for f in run.files_changed):
        return True
    if run.author_last_3_failed >= 2:
        return True
    return False

This works until it doesn't. Real failure patterns are messier than three hand-picked thresholds — maybe it's a combination of a specific file, a specific time of day, and a specific author's typical commit size, in a way no one would think to encode by hand. Machine learning inverts the problem: instead of writing the function, you write down what you know about the function — a pile of past runs, each with its properties and whether it actually failed — and an algorithm searches for a function that fits that data.


# You provide examples, not rules:
#   (lines_changed=612, files_changed=[...], author_recent_fail_rate=0.4, ...) -> failed
#   (lines_changed=8,   files_changed=[...], author_recent_fail_rate=0.0, ...) -> passed
#   ... thousands more historical runs ...
#
# The algorithm produces a function. You never write its condition logic —
# you choose its shape (a decision tree, a linear model, a small neural net)
# and let training set its internal numbers.
model = train(historical_runs, outcomes)
model.predict(new_run)   # -> probably_fails: 0.83

That's the entire idea. Everything else in this track — decision trees, gradient descent, neural networks, transformers — is a different answer to the same question: given examples of inputs and the outputs they should produce, what's a good way to find a function that generalizes to inputs it hasn't seen?

three ways to learn from data

"Machine learning" isn't one technique — it's a family of problem setups that differ in one question: what feedback does the algorithm get while it's learning? The three standard answers are supervised, unsupervised, and reinforcement learning. Same CI example, three different problems:

Paradigm	What you have	What you get	CI example
Supervised	inputs paired with the correct output for each one	a function that predicts the output for new inputs	predict pass/fail for a new run, from thousands of past (run, outcome) pairs
Unsupervised	inputs only, no correct-output labels	structure hidden in the inputs themselves	cluster past failures into a handful of recurring failure "shapes" nobody had named yet
Reinforcement	an environment to act in, and a reward signal after each action	a policy that picks actions to maximize reward over time	an agent that decides which test suites to run first, rewarded for surfacing a failure sooner without wasting runner time

The dividing line is where the "right answer" comes from, not how fancy the algorithm is. A linear model and a deep neural net can both be supervised; a simple clustering algorithm and a deep autoencoder can both be unsupervised. Paradigm is about the problem setup, not the model.

supervised learning: classification vs. regression

Supervised learning splits again by what kind of output you're predicting. Classification predicts one of a fixed set of categories — pass/fail, or a specific failure category out of a known list. Regression predicts a continuous number — say, how many minutes a run will take. Same data, same "fit a function to examples" idea; the only difference is whether the target is a label or a number, which changes what "wrong" means and how the model is trained to reduce it.

This distinction matters early because it decides which model types and error metrics even apply — you'll see it drive the choice of loss function and evaluation metric throughout this track.

unsupervised learning, briefly

Without labels, "learning" means finding structure that was already there in the data — groups of similar points (clustering), a lower-dimensional way to describe high-dimensional data (dimensionality reduction), or which points don't fit the pattern the rest of the data follows (anomaly detection). Nobody tells the algorithm what the groups mean; it just finds that they exist. A human still has to look at cluster 3 and decide it's "flaky network mocks," not the algorithm.

Unsupervised learning is also the quiet backbone of a lot of modern supervised systems: large language models are pretrained in a self-supervised way — the "labels" are just the next word in a sentence the model already has, so no human ever hand-labels the training data, but the training loop still looks supervised (input in, correct output compared, error computed). The line between the paradigms blurs in practice more than the clean three-way split suggests.

reinforcement learning, briefly

Reinforcement learning is the odd one out: there's no fixed dataset of "correct answers" at all. An agent takes actions in an environment, observes a new state and a reward, and gradually learns a policy — a strategy for which action to take in which state — that maximizes reward over time. It's the right framing when the "correct" choice depends on a sequence of decisions and their long-term consequences, not a single input-output pair: the test-scheduling agent above isn't graded example by example, it's graded on outcomes that only become clear several actions later.

It's also the least commonly needed of the three in day-to-day applied work — most real-world problems that look sequential can often be reframed as supervised learning with enough feature engineering, and RL brings real training-stability headaches. Reach for it when the problem is genuinely about a sequence of decisions with delayed reward, not by default.

common beginner misconceptions

A trained model doesn't "reason" about your problem — it's a function that interpolates between the examples it saw. Feed it something far outside the training distribution (a run shape it's never seen) and you get a confident, often wrong, extrapolation, not an "I don't know."

More data isn't automatically the fix. If the labels are noisy, or the inputs don't actually contain the information needed to predict the output, no amount of additional examples fixes that — this is a running theme covered in depth later in this track under feature engineering and data leakage.

"Deep learning" is a technique, not a separate field from "machine learning." A neural network is one particular family of functions you can fit with the supervised-learning recipe above; decision trees and linear models are others. Which one wins depends on the problem — gradient-boosted trees still beat neural nets on a lot of tabular business data.

where to go from here

This page is the map. Next up: The ML Pipeline: From Raw Data to a Deployed Model, then the individual algorithms (linear regression, decision trees) and the mechanics that make them trainable (gradient descent, regularization, evaluation) — one concept per page, beginner to advanced, all under ML Foundations.

ML Basics & Practical Notes — a running list of practical gotchas (feature scaling, label leakage) if you want hands-on notes alongside the theory.
Deep Learning & PyTorch Engineering — once "fit a function to examples" becomes "train a neural network in PyTorch."

reference

Google Machine Learning Crash Course
scikit-learn — An Introduction to Machine Learning