AIQ
AIQ
Part of the Step-by-Step Instructions lesson guide. Teaching a different grade? 🌈 Explorer (5–7) · 💻 Hacker (11–14) · ⚡ Architect (15–18)
Open with the lesson's actual hook line, read with energy: "What if I asked you to teach a ROBOT to make a sandwich? 🥪🤖 You can't just say 'make a sandwich.' You have to explain EVERY. SINGLE. STEP. Welcome to algorithms!"
Ask the class: "Show of hands — who thinks they could give clear enough instructions that a robot with zero common sense could actually make a sandwich?" Most will say yes confidently. Say: "Let's put that to the test — and I promise, someone's robot is going to fail in a funny way."
Mention the badge students can earn for finishing this lesson in the app: "Algorithm Ace." Frame the day's goal: "By the end of today, you'll know exactly what an algorithm is, and you'll be able to spot one in almost anything."
If a few students immediately object "but a robot could just ask a question if it's confused" — hold onto that instinct rather than shutting it down; it's actually correct about some modern AI systems, but not about the plain, hand-written algorithms this particular lesson is about. Tell them you'll come back to that idea once they've seen why "asking a clarifying question" isn't something a basic algorithm does on its own — that's a good hook for their curiosity through the activity.
Walk through the lesson's three learn scenes as a guided sequence, having students follow along on their own devices or on a shared screen. Budget about 20–25 minutes for all three scenes combined, with Scene 2 (the robot sandwich exercise) taking roughly half of that time.
Introduce the definition directly: an algorithm is a set of ordered instructions for solving a problem or completing a task. Then work through the four examples in the app with the class:
For the sorting example specifically, it's worth a slightly longer pause: ask two students to sort a shuffled set of ten number cards, one working alone and describing their method out loud, the other timing them. Then ask the class to guess whether a different method (say, always finding the smallest remaining card versus repeatedly swapping neighboring cards that are out of order) would be faster or slower for a much bigger pile — 100 or 1,000 cards instead of 10. You don't need to name any sorting algorithms formally here; the goal is just planting the idea that different sets of steps for the same task aren't automatically equally good, which is a concept Hacker- and Architect-mode students will return to explicitly.
Ask: "What do all four of these have in common?" Guide students toward: they all have steps, the steps happen in a specific order, and skipping or reordering a step changes the result. Push a little further: "Which of these four would still work even if you did the steps in a slightly different order?" (Arguably none of them fully would — even sorting numbers depends on comparing them in a consistent way — which is a useful nudge toward the idea that order isn't just a nice-to-have, it's part of what makes an algorithm an algorithm.)
Run this as a live exercise before revealing the app's version. Split the class into small groups. Each group writes out, on paper, the exact steps to make a peanut butter sandwich — as if for a robot that has never seen a jar, bread, or knife before.
Collect one group's instructions and read them aloud exactly as written, nothing more. This almost always exposes a missing step — most commonly "open the jar" or "which side does the peanut butter go on." When it happens, stop and ask the room: "What just went wrong, and whose fault is it — the robot's, or the instructions'?" Land on: the instructions', because a computer executes literally rather than filling gaps with common sense.
Then show the app's own walkthrough: Step 1 (get bread) needs arm-and-grip-level detail; Step 2 (add filling) needs jar, knife, and quantity; Step 3 (close it) needs "on top" specifically stated, or the robot could place the second slice sideways. Emphasize the app's own line: "Miss a step = fail!"
It helps to name, out loud, the three qualities good instructions need — not as vocabulary to memorize, just as a checklist the class can use for their own writing: complete (no step is missing, even ones that feel obvious), specific (no vague verbs like "handle" or "fix" that could mean more than one thing), and in the right order (the same steps, reordered, produce a different result). You'll use this same checklist again in the extension activity.
Once a group has been "caught out" once, have them revise their own list and read it aloud again. Almost every group finds a second small gap on their revision — usually amount ("how much peanut butter?") or orientation ("which side of the bread?"). Point out that this is completely normal, not a sign they did it badly the first time: professional software developers go through the same cycle of writing instructions, watching them fail in an unexpected way, and fixing the gap, over and over, as a routine part of the job.
Connect the idea to apps students actually use, using the four examples from the lesson: Google's search algorithm checks billions of pages in about half a second; a game's enemy character follows simple rules like "if the player is near, chase; if health is low, hide"; Instagram's feed algorithm decides what to show first based on what you've liked before; and a traffic light runs on a simple, fixed algorithm — green for 30 seconds, yellow for 5, red for 30, repeat.
Ask: "Which of these four do you think involves AI, and which is just a simple, fixed algorithm?" (Traffic lights are the simple, non-AI one — they never change based on data. The other three adapt or make decisions based on huge amounts of information.) Follow up: "Why do you think a traffic light doesn't need to be 'smart'? What would it even mean for a traffic light to learn something?" This plants a seed for later World lessons about how AI systems learn from data, without needing to explain machine learning today.
Close with: "Every app on your phone, every game character, and every traffic light you walk past is running some kind of algorithm. Today you learned what that word actually means, and you saw firsthand how easy it is to accidentally leave a step out."
Remind students of the "complete, specific, in the right order" checklist one more time before moving to the extension — it's the one thing worth them remembering even if everything else about today fades: any time something built to follow instructions does something unexpected, the fix is almost never "the machine is being difficult," it's finding which of those three things the instructions were missing.
Extension activity (15–20 minutes): Have each small group choose one everyday task (making instant noodles, folding a paper airplane, walking from the classroom to the cafeteria) and write it as a numbered algorithm with at least 8 steps, precise enough that another group — acting as a "robot" that can only do exactly what's written — could follow it without asking a single clarifying question. Swap lists between groups and have the "robot" group perform the task literally. Debrief on which steps had to be added after the first failed attempt.
If you have extra time: Challenge groups to write an algorithm for something with a decision built in — for example, "what to wear based on the weather." This introduces the idea of a conditional step ("if it's raining, bring an umbrella; if not, don't") without naming it formally, which is a natural stepping stone toward the game-AI style "if/then" rules students saw in Scene 3.