AI coding helpers are in your classroom whether or not you allow them, so the useful question is not how to keep them out but how to keep the learning honest while they are around. The answer is a handful of small guardrails that keep the reasoning with the student, because that reasoning is the thing an AI is happiest to skip. Three habits do most of the work: give hints not solutions, predict before you run, and explain before you merge.

Decide what you are actually protecting

The point of a coding class is not working code. It is the reasoning that produces working code: reading a problem, forming a plan, predicting what a piece of code will do, and closing the gap between what you expected and what actually happened. An AI helper can hand over a finished function in seconds. If a learner pastes it in without reading it, the code runs but the thinking never happened.

That reframes the whole debate. You are not policing whether AI was used. You are protecting the mental work. A guardrail is good if it keeps that work with the student, and pointless if it only tries to keep the tool out of the room.

Three guardrails that keep the thinking with the student

Hints, not solutions

Set the house rule that AI is allowed to give the next step, a question, or a nudge, but not a finished answer. In practice this is one instruction plus one prompt habit. Teach students to ask what should I check next rather than write this for me. With younger learners, the teacher models the good prompt on the board first so the class hears the difference between asking for a clue and asking for the solution.

Predict-then-run

Before running any code, the student's or the AI's, the learner says or writes what they expect to happen. Then they run it. The gap between the prediction and the result is the lesson. This one habit quietly exposes copy-paste: a student who cannot predict what a block or line does has not understood it yet, and now both of you know that before it is buried in a working program.

Explain-before-merge

Nothing goes into the project until the student can explain it in plain language, line by intent. If they cannot say what a part does and why it is there, it does not get merged. This is the code review move that professional teams use, scaled down to a classroom. It turns AI output from something to accept into something to interrogate.

Shift assessment toward process, not just the artifact

If your marks reward only the final program, AI makes that program cheap and your assessment stops measuring anything. Move weight onto the things a tool cannot produce on the student's behalf. A verbal walkthrough of their own code. A short predict-then-run log. A note on what they got stuck on and how they got unstuck. Best of all, live modification: ask the learner to change a working program in front of you, for example to make the robot turn left where it currently turns right. A student who understood their code can do that in a minute. A student who only pasted it cannot.

This also fits how CAPS-aligned assessment already values process and evidence of reasoning, so you are not inventing a new rubric, just weighting it toward things AI cannot fake.

Teach directing AI as a skill, not only as a temptation

Directing a tool well is itself worth teaching. Breaking a problem into pieces, describing the behaviour you want precisely, reading the output critically, and rejecting an answer that is wrong are exactly the decomposition and specification skills a coding class exists to build. So do not only restrict. Set aside time to teach the good version: how to write a clear request, how to test what came back, and how to spot a confident answer that does not actually work. Students who can do that are practising real engineering judgement.

Where hardware makes this easier

Physical robotics gives you a guardrail for free, because the robot is the ground truth. You cannot argue a line-follower into working, and predict-then-run becomes natural when the class is watching a real machine either do the thing or not. There is also a practical South African bonus: a kit that runs its program on the board keeps working through load shedding, when a cloud AI tool may be offline anyway.

This is how we run classes at the sheen academy. The sheenbot∞ board gives learners something they have to explain and modify in front of a peer or teacher, and the same predict-then-run and explain-before-merge habits carry through our holiday workshops. The tools change; the guardrails do not.

A starter AI policy you can post on the wall

• Hints only. Ask AI for the next step or a question, never a finished solution.
• Predict before you run. Say what you expect to happen, then run it.
• Explain before you merge. If you cannot explain it, it does not go in the project.
• Be ready to change it live. Assume you will be asked to modify your own code on the spot.
• Own the mistakes. Wrong AI answers are normal; your job is to catch them.

Takeaway

Banning AI helpers is neither enforceable nor educational. Guardrails are both. Keep the reasoning with the student through hints not solutions, predict-then-run, and explain-before-merge, then assess the process rather than only the artifact and teach students to direct the tool well. Do that and an AI helper stops being a shortcut around learning and becomes one more thing a young coder has learned to command. For more teacher notes like this, browse our newsroom.

Should I just ban AI tools in class?

A ban is hard to enforce and misses the point, because students will meet these tools everywhere else. Guardrails that protect the thinking, plus assessment that rewards process, do far more than a rule you cannot police.

How young is too young for this?

The habits scale down well. With early learners the teacher models the good prompt and runs predict-then-run out loud as a class; older students do it independently and start directing the tool themselves.

What if a student's AI answer is wrong?

That is the lesson, not the failure. Catching a confident but wrong answer is the skill you want, so treat every incorrect suggestion as a chance to practise predict-then-run and explain-before-merge.