Before you got to this room, software almost certainly decided something on your behalf. What you saw at the top of a feed. Whether a photo was of you. What word you meant when you mistyped it.
Every one of those decisions came out of an AI model. A model is just the part of a program that decides. Today you meet the main kinds, then you build one by hand and watch it break.
Two minutes, no more. Take three or four examples from the class rather than supplying your own, so the lesson starts from what they actually use. If nobody offers anything, prompt with a video feed, a photo app, and predictive text.
Teams compete. Five real things software does are revealed one at a time. For each one, call out the kind of model behind it. Fastest correct team takes the point, scoreboard on the board.
The answers, and why:
Notice number 5 is different in kind, not just in difficulty. The first four answer a question when asked. An agent is handed a goal and goes off and does things.
Reveal one at a time and take the call before you show the answer, or the game collapses into reading. Item 3 is the one worth dwelling on: a code assistant is not a special kind of model, it is the same generative model as the picture one, pointed at code. Item 5 is the one they will argue about, and that argument is the lesson.
Write these four down. You will use the words for the rest of the course.
| Kind | What it does | Where you meet it when coding |
|---|---|---|
| Generative | Produces something new: text, an image, code | An assistant that drafts a function, or explains code you did not write |
| Recommendation | Ranks options for one person | What a shop, a feed or a music app shows a given user |
| Classifier | Sorts an input into categories | Is this a cat or a dog, is this message spam, is this hand rock or paper |
| Agent | Takes a goal, plans, uses tools, acts in a loop | Software that carries out a multi-step task rather than answering one question |
The one you are about to build is a classifier. It takes something in and puts a label on it. It is the simplest of the four to build by hand, and building it by hand is the point.
Keep this to five minutes and resist expanding it. The table is a reference they will come back to in Lessons 32 and 33; it is not the teaching. If a student asks whether a chatbot is an agent, the honest answer is that a plain chatbot is generative, and it becomes an agent when it is given tools and a goal and allowed to loop.
Start a new Scratch project. You are going to write a classifier that tries to tell a cat from a dog, using nothing but yes or no answers.
Your first rule: if it barks, it is a dog. The person answering presses y for yes or n for no.
Predict before you run it: if you answer n to this one question, what will the program do? Say it out loud before you click the flag.
when green flag clicked
say [Think of a pet: a cat or a dog. Answer with y or n.] for (3) seconds
say [Rule 1. Does it bark?]
wait until <<key [y v] pressed?> or <key [n v] pressed?>>
if <key [y v] pressed?> then
say [I think it is a DOG.] for (4) seconds
stop [this script]
end
This is the predict beat: take the prediction before anyone clicks. The correct answer is that with n it does nothing at all and simply ends, because there is no rule for n yet. Students who expected it to say CAT have just discovered that a rule only covers what it was written to cover, which is the whole lesson in one line. The wait until block is the only unfamiliar one; it holds the script until either key goes down.
One rule is not a classifier, it is an opinion. Add two more so every answer leads somewhere.
Rule 2: if it purrs, it is a cat. Rule 3: if it fetches a ball, it is a dog, otherwise call it a cat.
The extra wait until after each rule waits for the key to come back up. Without it, one long press on n would answer all three questions at once.
when green flag clicked
say [Think of a pet: a cat or a dog. Answer with y or n.] for (3) seconds
say [Rule 1. Does it bark?]
wait until <<key [y v] pressed?> or <key [n v] pressed?>>
if <key [y v] pressed?> then
say [I think it is a DOG.] for (4) seconds
stop [this script]
end
wait until <not <key [n v] pressed?>>
say [Rule 2. Does it purr?]
wait until <<key [y v] pressed?> or <key [n v] pressed?>>
if <key [y v] pressed?> then
say [I think it is a CAT.] for (4) seconds
stop [this script]
end
wait until <not <key [n v] pressed?>>
say [Rule 3. Does it fetch a ball?]
wait until <<key [y v] pressed?> or <key [n v] pressed?>>
if <key [y v] pressed?> then
say [I think it is a DOG.] for (4) seconds
else
say [I think it is a CAT.] for (4) seconds
end
Three rules stacked in a row is deliberately plain: students should be able to read the whole model at a glance and say what it will do. The release check is worth naming, because it is a real bug they will hit again with any key-driven program. Anyone who leaves it out will see the guesser answer instantly and wrongly, which is a useful thing to let happen once.
You're previewing this lesson. Get full access to this lesson and hundreds more — each one ready to teach, with interactive activities, printable resources and pupil progress tracking built in.