AI and what it actually is

AI is the field of making software do tasks we'd normally call intelligent. That's the starting point for this course, and it matters because the word AI gets used for more than one kind of system.

For developers, the useful definition is practical. AI is the umbrella field. Under it, you can have expert systems that reason with rules, search, planning, and machine learning.

Machine learning, or ML, is one part of that umbrella. It means learning patterns from data instead of coding every decision.

AI is the umbrella field

When someone says AI, they might mean a broad system with several moving parts. The reel names expert systems, search, planning, and ML as parts of that umbrella.

That distinction is worth keeping in your head during design and debugging. If a feature is built from rules, data, search, planning, and a model, each part can fail in a different way. Calling the whole thing AI is fine in conversation, but it can hide which part you need to inspect.

An expert system reasons with rules. Search and planning are also inside the AI bucket. ML is inside the same bucket, but it has a specific shape. It learns from examples.

So when you write an AI design doc, be specific about which part you mean. If the decision comes from a rule, call it a rule. If the behavior comes from examples and labels, call it ML.

ML learns patterns from data

The basic ML flow in the reel is simple.

Examples go into training. Training produces a model. The model produces output.

That's the key difference from coding every decision. With ML, you give the system data so it can learn patterns. The learned model is then used to produce an output.

The spam filter example makes this concrete. A spam filter learns from labeled emails. Those examples are marked spam or not spam. The labels are part of what lets the model learn the pattern.

The model then answers the question, spam?

This is why ML work often turns into data work. If the model learned from labeled emails, the labels matter. If the examples are the source of the pattern, the examples matter too.

Why developers should care

The distinction matters most when something breaks.

If the bug is in a rule, tuning the model won't fix the rule. If the issue is with data, changing search or planning may miss the point. If the output comes from a model, debugging it like a hand coded decision can send you in the wrong direction.

The reel's practical version is this. Don't tune a model if the rule is wrong.

That's a useful check before reaching for ML fixes. Ask what part of the system produced the bad behavior. Was it rules, data, search, planning, or the model?

If you keep only one line from lesson 1, keep this one. AI is the umbrella field, ML learns from data. Next, look at rules vs learning.