Notice what you are not doing at each step. You are not writing code from scratch in the first four steps. You are reading, comparing, questioning, and adapting. Production — writing new code — comes last, after understanding is established. This ordering is deliberate and important.

A good prediction is precise. "It prints Hello a few times" is not a prediction — it is a vague impression. A precise prediction states exactly which lines appear in exactly which order:

Hello, Alex
Hello, Alex
Hello, Alex
Hello, Sam

To get to that precision, use the trace skills from the other articles in this section. Trace the function call, follow the loop, count the iterations. Write the output line by line.

If you are not sure what the program will do, that is fine — write your best guess and note what you are unsure about. Uncertainty is not a reason to skip the prediction. It is the reason to make one.

The Run step is not about running the program. Any computer can do that. It is about the comparison. Here are the three things to do after the program runs:

1. Mark each line of output as predicted or not predicted. A tick for lines that matched. A cross for lines that did not appear or appeared differently.
2. Count the discrepancies. One wrong line is different from five wrong lines. The number tells you how confident your mental model was.
3. Write a one-sentence note on each discrepancy. "I thought the loop ran four times but it ran three." or "I forgot the comma in the print statement." This note becomes the starting point for Investigate.

For the example program, Investigate might look like this:

Question from the Run step: Why does greet("Alex", 3) print three lines?

Investigation: The function has a for loop using range(times). When times is 3, range(3) produces 0, 1, 2 — three values. The loop body runs once for each value, printing one line each time. Three values, three lines.

Question: What is i used for inside the loop body?

Investigation: It is not used at all. The loop body only uses name. The variable i exists only to count iterations — its value is never referenced inside the body. This is a common pattern: a loop variable used purely as a counter.

Question: What would happen if I called greet("Alex", 0)?

Investigation: range(0) produces an empty sequence. The loop body never runs. The function prints nothing. Testing this confirms it.

Each modification is a small experiment. You have a hypothesis ("if I change X to Y, the output will be Z"), you test it, and you compare. This is the scientific method applied to code.

The most important discipline in the Modify step is changing one thing at a time. Changing two things simultaneously means you cannot be sure which change caused the effect you observed. If the output is wrong, you do not know which change to undo. One change at a time is not slower — it is faster, because you always know what caused what.

Modifications should get progressively more ambitious. Start with something trivial (changing a string value). Move toward something structural (changing what the function does). Here is a structural modification for the example:

Modification task: Change the function so it prints the greeting in uppercase.

def greet(name, times):
    for i in range(times):
        print("Hello,", name.upper())

Before running: what will this print? The name will appear in uppercase. "Alex" becomes "ALEX". Predict the exact output, then run and check.

The Make step is where you find out whether you understood the example or just memorised it. A student who memorised the example will find it hard to write a function with a different purpose. A student who understood the pattern — function takes parameters, loop uses a parameter to control repetition, body does something each time — will find the Make step much more straightforward.

Here is what the Make step is not:

• It is not copying the example program into a new file and changing the variable names.
• It is not adding more features to the example program.
• It is not asking AI to write a new program based on the example.

It is also not starting from a completely blank page with no support. You may look at the example for reference. You may look at the Investigate notes you made. What you must not do is copy code without understanding it.

AI-generated code has a particular risk: it looks correct. It is usually syntactically valid, runs without errors, and produces plausible-looking output. This makes it more dangerous to accept without investigation, not less — because the usual signals that you do not understand something (errors, crashes, wrong output) may not appear.

The Investigate step is especially important with AI-generated code. Ask:

• Does every line do what I think it does?
• Are there any lines I cannot explain?
• Does this program handle edge cases — empty input, zero, a very large number — correctly?
• Is there a simpler way to write this that I would understand more easily?

If there are lines you cannot explain, do not submit the code. Either investigate further, ask the AI to explain those specific lines, or rewrite those parts in a way you understand. In this course, submitting code you cannot explain is not a shortcut — it is a gap that will be found in the oral defense.

Predict

The function takes a list. It sets best to the first item (4). It loops through every item. If an item is greater than best, it replaces best. At the end, it returns best.

Trace: best starts at 4. n=4: 4 > 4 is False. n=9: 9 > 4 is True, best becomes 9. n=2: 2 > 9 is False. n=7: 7 > 9 is False. n=1: 1 > 9 is False. Return 9.

Prediction: 9

Run

Output: 9. Prediction matched.

Investigate

Why does best start at numbers[0] rather than 0? Because if all numbers in the list were negative, starting at 0 would give the wrong answer — 0 would appear to be the largest, but it is not in the list at all. Starting at the first element guarantees best is always a real value from the list.

What happens if the list has only one item? best is set to that item. The loop runs once, comparing the item to itself — which is not greater than itself, so best does not change. The function returns the single item. Correct.

What happens if the list is empty? numbers[0] would raise an IndexError. The function has no protection against an empty list. This is a limitation worth noting.

Modify

Task: change the function so it finds the smallest value instead of the largest.

Prediction: change if n > best to if n < best. With the list [4, 9, 2, 7, 1], the result should be 1.

def smallest(numbers):
    best = numbers[0]
    for n in numbers:
        if n < best:
            best = n
    return best

Run: output is 1. Prediction matched.

Make

Task: write a function called average that takes a list of numbers and returns their average. Use the same pattern of starting with an initial value, looping through the list, and accumulating a result, then returning it.

def average(numbers):
    total = 0
    for n in numbers:
        total = total + n
    return total / len(numbers)

print(average([4, 9, 2, 7, 1]))

The structure is recognisably the same — a function, an initial value set before the loop, a loop through the list, a return statement — but the purpose is different and the accumulation logic has changed. This is a successful Make step.