1 - Start: Read Code You Did Not Write ~4 mins
You did not write today's program, so you have to work out what it does by reading it. This is one of the most useful skills a coder has: most of the code you will ever meet was written by someone else.
You will trace a short Scratch program by hand, work out what it prints, then find a bug hiding inside it. After that you will read an AI assistant's explanation of the same code and decide whether to trust it, check it, or reject it.
This lesson is about reading, not building. Students do not write this program from scratch; they read it, trace it, and judge it. Keep the framing to about four minutes so the trace and the AI comparison get their time.
The AI explanation in step 4 contains a deliberate mistake. The whole point is that students catch it against their own trace, so do not preview the answer here.
2 - Trace It by Hand Before You Run It ~9 mins
Here is the whole program. Read it top to bottom before you touch anything. It counts up through the numbers 1 to 5 and adds the even ones to a running total.
Do not click the green flag yet. On paper, keep two columns, one for number and one for total, and step through the loop five times by hand. Write down what you think the final total will be. Then run it and compare.
when green flag clicked
set [total v] to (0)
set [number v] to (1)
repeat (5)
if <((number) mod (2)) = (0)> then
change [total v] by (number)
end
change [number v] by (1)
end
say (join [Total of evens: ] (total))
Predict first, before anyone clicks the green flag: what will the sprite say at the end?
The right answer is 6: the even numbers from 1 to 5 are 2 and 4, and 2 + 4 = 6. The common wrong prediction is 9 (2 + 3 + 4, if a student reads the condition as odd, or forgets mod tests the remainder). A trace table settles it: number goes 1, 2, 3, 4, 5 and total only changes on the even steps.
Look-for: students who run first and reason backwards. Ask them to fill the table before the flag.
3 - Find the Planted Bug ~9 mins
Here is a second version of the program. It is meant to count how many even numbers it finds between 1 and 5 and say the count. It runs without any error message, but the number it says is wrong.
Read it against what it is supposed to do. Use your debugging routine: read the symptom, find the block, form a hypothesis, test it. The variable count should end on 2, because there are two even numbers. Work out which single block is wrong and what it should be.
when green flag clicked
set [count v] to (0)
set [number v] to (1)
repeat (5)
if <((number) mod (2)) = (1)> then
change [count v] by (1)
end
change [number v] by (1)
end
say (join [Even numbers found: ] (count))
The bug is on the if condition: it reads (number) mod (2) = (1), which tests for odd numbers, so it counts 1, 3 and 5 and says 3 instead of 2. The fix is to change the 1 to 0.
The symptom is a wrong output with no crash, which is the harder kind of bug to find and exactly why tracing matters. Push students to name the hypothesis (it is counting odds) before they change anything, then test the fix by re-running.
4 - Judge the Ai's Explanation ~3 mins
An AI assistant was asked to explain the second program, the counting one. Here is exactly what it wrote:
"This Scratch program counts how many even numbers there are between 1 and 5. It starts count at 0 and loops five times. Each time round, it checks whether number is even, and if it is, it adds one to count. At the end it says the answer, which is 2."
Read the AI's explanation against the code and your own trace from the last step. Where is it right? Where is it vague? Where is it simply wrong? Decide your one-line verdict: trust, check, or reject.
The explanation reads confidently and is right about the setup, the loop count, and the intention. It is wrong on two linked points: the condition tests for odd (mod 2 = 1), not even, and the answer it states, 2, is what the code was meant to give, not what it actually gives (3). The AI described the intended program, not the real one, and missed the very bug the students just found.
The verdict should be reject, or at least check: it did not catch the error and stated a false output as fact. Draw out the lesson: an AI explanation is a claim to test against your own trace, not an answer to accept.
5 - Your Turn ~8 mins
Open the counting program you traced and fix the planted bug so it correctly says how many even numbers it finds. Run it and check it says 2.
Then write your one-line verdict on the AI's explanation. Done looks like:
- The condition is fixed so the program says the right count.
- You have run it and confirmed the output.
- You have written trust, check, or reject, with one reason.
- You can point to the exact line where the AI went wrong.
Save your work the class way before we pull back together.
Grouping: students work solo, then compare verdicts with a partner. The task is the fix plus the one-line judgement, not a rebuild.
Optional extension (no time attached): paste the fixed program into an AI assistant and ask it to explain the code, then judge that new explanation too. Does it describe the real program now?
Circulate for the student who fixes the output but still writes trust: press them to reconcile a correct fix with an explanation that stated the wrong answer.
Unlock the full learning experience
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.
This lesson is copyright of Coding Ireland 2017 - 2025. Unauthorised use, copying or distribution is not allowed.
Scratch is developed by the Lifelong Kindergarten Group at the MIT Media Lab. It is available for free at https://scratch.mit.edu