Teaching AI to people who do not write code

The most useful thing I have seen in a training room is a commerce student shipping a working application before the computer-science students in the same room have finished arguing about which framework to use.

It happens more often than you would expect, and it taught me most of what I now believe about teaching this subject.

The barrier is permission, not difficulty

People arrive having already decided this is not for them. The word “AI” carries about fifteen years of accumulated implication that you need a doctorate and a GPU cluster. By the time someone sits down in front of you, the sorting has happened in their head and they are waiting for confirmation.

So the first job is not teaching. It is removing the reason they had already prepared for why this would not work for them. Everything else follows from that, and almost nothing works before it.

Build in the first hour. Not the last.

The instinct is to teach foundations first: what a model is, how tokens work, a little history, then eventually let people touch something. This is exactly backwards for this audience. The foundations are much easier to absorb once someone has already made a thing work, because now the concepts are explaining something they experienced rather than something they are told to anticipate.

The sessions I run put something live and public in front of every person in the room, in one sitting, with a URL they can open on their own phone. That moment — their thing, on the internet, that they can send to somebody — does more for their willingness to learn the theory than any amount of preamble.

Non-coders ask better questions

Given the same brief, an engineering student tends to ask how to build it. A commerce or arts student tends to ask what it is for, who would use it, and why it should exist at all.

The second set of questions is much harder to teach and much scarcer in the wild. Anyone who has watched a technically excellent product fail commercially knows exactly how expensive their absence is. Mixed rooms work better than streamed ones for this reason, and I now deliberately avoid separating them.

Structure beats motivation

People leave a good session genuinely energised, and that energy has a half-life of roughly a week. Anything that depends on sustained enthusiasm will not survive contact with a normal semester.

So the on-demand courses I build are deliberately rigid where it counts. You cannot skip ahead. A session unlocks only when the one before it is genuinely complete — every checkpoint done, the mastery quiz passed, not merely attempted. Across the platform that is five hundred and fifty-one hands-on lab steps and four hundred and ninety-six mastery questions, and none of it is optional.

It sounds harsh, and learners occasionally tell me so. But the failure mode in self-paced learning is almost never that the material was too hard. It is drift — a missed week, then a vague sense of being behind, then quietly never returning. Structure is what carries someone through the week their motivation does not.

What I got wrong

For a long time I taught tools. Here is the interface, here is the button, here is the prompt that works. It demos beautifully and it ages terribly — the interface I taught eighteen months ago has been redesigned twice since.

What I teach now is the loop: describe what you want, generate, then verify, then correct. The whole weight sits on verify, because that is the step everybody skips and the only one that reliably separates people who get useful results from people who get confident nonsense.

Which is, I notice, the same lesson I keep relearning in my own work. The tools change constantly. The discipline of checking whether the answer is actually true does not.