What is Artificial Intelligence?

Theory clicks when you run it yourself. This post takes everything from 'How AI works' and compresses it into about fifteen lines of Python you can run on any laptop. The aim is a single 'aha': watching a program learn a rule we never wrote.

We'll use the classic iris dataset — flower measurements and their species — and train a model to classify them. Crucially, at no point will we write 'if petal length is greater than X, it's species Y'. We just hand the model examples and answers, call one method, and it discovers the rules itself. If you've only ever read about machine learning, running this will change how real it feels.

The idea we're going to prove is the heart of machine learning, made concrete. Instead of a human studying flowers and hand-coding identification rules, we show a model labelled examples — measurements paired with the correct species — and let it infer the decision boundaries on its own. The dataset (iris) is tiny and famous precisely because it's perfect for this first demonstration.

Keep your eye on what's NOT here: no botanical expertise, no hand-written thresholds, no long list of cases. That absence is the point. In traditional programming you'd need a domain expert to articulate the rules; in machine learning the data plays that role. By the end of these few slides you'll have watched a program go from knowing nothing about flowers to classifying ones it has never seen with around 97% accuracy — and you'll understand exactly how.

Every project starts with setup, and getting this habit right early saves you pain. We install scikit-learn — the friendly, batteries-included library that powers most classic machine learning — and import the specific pieces we need: a dataset loader, a function to split data, a model, and a metric to score it. Importing exactly what you use keeps code readable and makes dependencies obvious.

A professional note that pays off forever: do this inside a virtual environment (with venv, conda, or uv) rather than installing packages globally. Mixing project dependencies into your system Python is one of the most common sources of 'it works on my machine but not yours' bugs. It feels like an unnecessary step on day one, but it's the difference between projects that stay reproducible and projects that mysteriously break in six months.

Here we load the data and split it — and that split is more important than it looks. load_iris gives us X (the flower measurements, our inputs) and y (the species labels, the answers we want predicted). We then carve off 20% of the data as a 'test set' that the model will never see during training.

Why hold data back? Because the only honest way to know if a model truly learned — rather than memorised — is to test it on examples it hasn't encountered. If we scored it on the same data it trained on, a model that simply memorised every example would look perfect and tell us nothing. The random_state=42 just makes the split reproducible so you get the same result each run. This train/test discipline is the bedrock of trustworthy machine learning; skip it and your accuracy numbers become fiction.

This is the line where 'learning' happens, and it's almost anticlimactically simple. We create a DecisionTreeClassifier (a model that learns a series of yes/no questions about the features) and call .fit(X_train, y_train). That single .fit() call is the entire training loop from the previous post — guess, measure, adjust — running under the hood, automated by the library.

The max_depth=3 is a deliberate guardrail: it limits how many questions deep the tree can go, which keeps it from memorising the training data (overfitting) and forces it to find general rules. Notice how much the library hides: all the gradient-style optimisation, all the bookkeeping, condensed into one method. That's the gift of modern tooling — but never forget that the simple guess-measure-adjust loop is still what's happening beneath that friendly API.

Now we use the trained model on the held-out test set and score it. We call .predict() to get the model's guesses for flowers it never saw during training, then compare them to the true answers with accuracy_score. The result is around 0.97 — roughly 97% correct on genuinely unseen data.

Sit with what just happened: a program that started knowing nothing about flowers now identifies species it has never encountered, and it learned to do so purely from examples, with no rules from us. That's not a parlour trick — it's the same fundamental capability that, scaled up enormously, powers everything from fraud detection to language models. The scale and the data change; the essence does not. You've just run, end to end, the thing this entire field is built on.

Let's name exactly what happened, because it's easy to skim past the miracle. We never told the model how to identify a flower. We gave it measurements and answers, called .fit(), and it discovered the decision boundaries itself — then applied them correctly to new data. That move, from 'human writes rules' to 'machine infers rules from examples', is the whole conceptual leap of machine learning.

This is why the field scales so well. Writing rules by hand doesn't scale — every new case needs a human. Learning from data does scale — give it more examples and it improves on its own. The 15-line version you just ran and a billion-dollar frontier model differ in scale, data, and engineering, but not in this core idea. Once you've internalised this single .fit() moment, every later topic is an elaboration of it.

This little flow captures the reusable mental model for almost all supervised machine learning: .fit(X, y) to learn, the resulting model holding the learned knowledge, and .predict(new) to apply it. Once you see this three-step shape, you'll recognise it everywhere — in scikit-learn, in deep learning frameworks, even conceptually in how large models are trained then queried.

It's a powerful abstraction because it cleanly separates two phases that beginners often blur: learning (expensive, done once, needs labelled data) and applying (cheap, done repeatedly, needs only new inputs). Whenever you meet a new ML library or API, look for this shape — where does it learn, where does it predict? — and you'll orient yourself in minutes instead of hours. The names vary; the pattern is remarkably constant.

This comparison crystallises why machine learning matters by contrasting it with the old way. The traditional approach has a human writing and forever maintaining hundreds of if/else rules — and those rules shatter the moment a case appears that nobody anticipated. The ML approach shows the system examples and lets it write (and update) the rules itself, generalising to situations no one explicitly coded for.

But be honest about the trade-off, because it's not free magic. Rule-based systems are transparent and predictable — you can read exactly why they did something. Learned models generalise beautifully but can fail in surprising, hard-to-explain ways, precisely because no human wrote the rules. Knowing which approach fits a problem — and when a humble rule beats a model — is a mark of real engineering judgement, not a beginner's reflex to always reach for ML.

The fastest way to actually learn this is to break it and rebuild it, so here are four experiments worth running. Swap the DecisionTree for a RandomForestClassifier and compare accuracy — you'll usually see an ensemble of trees beat a single one. Print model.feature_importances_ to see which measurements the model leaned on most; it's a small window into what it 'learned'.

Then deliberately set max_depth=1 and watch it underfit (too simple to capture the pattern), and max_depth=10 and watch it overfit (memorising training quirks). Seeing both failure modes with your own eyes teaches the bias-variance trade-off better than any lecture. Finally, replace iris with your own CSV loaded via pandas — applying the exact same pattern to data you care about is where it stops being a tutorial and starts being a skill. Curiosity-driven tinkering is how this knowledge sticks.

A warning that separates careful engineers from demo-driven ones: don't stop at the accuracy number. 97% sounds fantastic until you ask the right questions. Was the test set genuinely representative, or unusually easy? Were the classes balanced, or could a lazy model score high just by always guessing the majority? Did any test data accidentally leak into training, inflating the score?

And most importantly: what does a wrong prediction actually cost in the real world? 97% accuracy is wonderful for sorting flowers and potentially catastrophic for diagnosing disease. A metric without context is exactly how impressive demos quietly mislead people. The habit to build is reflexive skepticism toward any single number — always ask what's behind it. That instinct will save you from shipping models that look great in a notebook and fail the people who depend on them.

You've now trained a real model, scored it on unseen data, and seen the rules-versus-learning leap firsthand — plus you've got four experiments to deepen it and a healthy skepticism about lone accuracy numbers. That's a genuinely solid first hands-on milestone. Code that you've run and tinkered with sticks in a way reading never does.

Tomorrow we close out Day 1's topic from the angle that saves the most pain: the common mistakes. We'll cover the five thinking traps that catch nearly everyone starting in AI — from trusting confident outputs to skipping evaluation — and how to avoid each. Save this post, actually run the code if you haven't, and come back tomorrow to learn the mistakes the easy way instead of the expensive way.