Design an AI-Supported Learning Activity

Most AI-in-the-classroom activities are designed forwards: here is an interesting tool, what could students do with it? These activities are engaging, students enjoy them, and they frequently produce no evidence that anyone learned anything. The lesson looks successful and cannot be assessed.

Designing backwards fixes this, and it is not a new idea — it is ordinary backward design applied to a new tool. The difference is that generative AI makes the second step, deciding what counts as evidence, much harder to skip.

Four steps, in this order

Start with the objective: what should a learner understand, do, or be able to explain afterwards? Write it as something observable. "Understand bias in sources" is not observable. "Identify which of three sources is least reliable and say why" is.

Then decide the evidence — before you design any activity. What would convince you the learner can do the thing? This is the step people skip, and it is the one that makes everything else work. Once you have written down "a two-sentence justification naming a specific weakness in the source," the activity almost designs itself, and you immediately know which parts a generated answer would invalidate.

Then build the activity that produces that evidence. Then, and only then, ask where AI genuinely helps.

Working in this order also answers the question teachers actually have, which is not "should students use AI?" but "for this task, where is the line?" The objective draws the line for you.

The same tool, on both sides of the line

Whether a use of AI supports or destroys the learning depends entirely on what you are trying to teach. There is no tool-level answer.

If the objective is revision and editing, having the model produce a rough draft is support: the student's work is everything that happens next. If the objective is drafting, the same action removes the entire task.

If the objective is evaluating arguments, asking the model to argue the opposing side is excellent — it produces a sparring partner that is always available and never gets tired. If the objective is constructing an argument, the same prompt hands over the work.

This is why blanket policies fail. "AI is allowed" and "AI is banned" are both wrong for some tasks in every course. The workable policy is per-assignment and stated in one line: for this task, you may use AI for X; the part being assessed is Y.

Make the thinking visible

If the only artifact is a finished answer, you cannot distinguish learning from retrieval. Build the activity so it produces process evidence as a natural byproduct rather than as extra work.

A plan captured before the tool is powerful precisely because of the ordering — it cannot be reverse-engineered from an output that does not exist yet. Two minutes of writing at the start of the lesson is enough.

Source choices with reasons ask why these three and not the first three returned. The reasoning is the skill; the list is not.

A revision trail shows what changed between drafts and why. Where AI was used, a short usage note belongs here: what was asked, what came back, what the student did with it.

The strongest and cheapest technique is the critique of a supplied flawed output. Give every student the same AI-generated answer containing two real errors — a fabricated citation and a plausible but wrong inference work well — and ask them to find and explain them. This is hard to fake, quick to grade, discriminates sharply between levels of understanding, and teaches the exact scepticism you want them to carry out of the room. It also inverts the usual dynamic: the model produces, the student evaluates.

Practice: build a twenty-minute activity

Write these four things on one page.

One objective, observable, in a single sentence.

One two-minute AI interaction, specified precisely enough that you could hand it to a substitute teacher. "Ask the model to argue against your position and note its strongest point" is specific. "Explore the topic with AI" is not.

One student-created artifact that contains the process evidence — the plan, the reasoning, or the critique.

A three-item rubric where at most one item is about the polish of the final answer.

Then add a no-AI fallback path that reaches the same objective. This is not optional. Some students will not have access, some tools will be down, and some learners should not be creating accounts. If the fallback is impossible to write, the activity depends on the tool rather than on the learning, and it will stop working the moment the tool changes.

Finally, apply the durability test: if this specific product disappeared next term, does the activity still teach something? Skills like source evaluation, critique, and iteration survive. Prompt syntax for one particular interface does not.

Access, privacy, and equity constraints

Requiring a tool account sends student data to a third party, which brings institutional policy, age limits, and data protection rules into scope before any pedagogy. Check these first, because they can rule an activity out entirely and it is better to know before you have built it.

Access is not uniform. Paid tiers produce better output than free tiers, home connectivity differs, and device availability differs. An activity graded on output quality partly grades subscription status.

The last row cuts the other way, and it is the one most often missed: for some learners, generative assistance is an accommodation rather than a shortcut. A blanket ban written to preserve rigour can remove support someone depends on. Per-task policies handle this gracefully; blanket ones do not.

Common mistakes

Designing from the tool. If you cannot state the objective without naming the product, start over.

Confusing engagement with learning. Students enjoying a lesson is necessary and not sufficient. Ask what evidence you would show a sceptical colleague.

Treating a polished output as evidence. Fluency is now free. The plan, the reasoning, and the critique are not.