This was the challenge I faced when teaching Object-Oriented Programming (OOP) to a Year 10 class. Object-Oriented Programming underpins most modern software development, including many of the games students play every day. Yet it is often difficult for students to grasp because it involves understanding relationships, structures and interactions that cannot be easily seen.

For several years, I approached this topic in the traditional way. I explained the concepts, demonstrated examples and worked through code with students. While many students could recall the terminology, deeper understanding was often harder to achieve.

This year, I approached the problem differently by asking:

How can students experience these ideas before learning the terminology?

The answer was a role-playing game inspired by The Matrix.

Each student created a character with particular strengths and abilities. As the game progressed, characters developed, specialised and interacted with one another. Students made decisions, responded to changing situations and experienced how a system of interconnected rules operated. Only after the game did we begin introducing the programming terminology.

What I found was the concepts were no longer abstract definitions on a slide. Students could connect each new term to something they had personally experienced during the activity.

Rather than starting with theory and hoping students could apply it later, the lesson worked in the opposite direction. Students first developed an intuitive understanding of the underlying ideas. The formal language then provided labels for concepts they already understood.

The result was that conversations about programming became more concrete. Students had something tangible to refer back to when discussing ideas that are normally difficult to visualise.

Interestingly, the students never used AI during the lesson, but I did.

Designing a game-based learning experience is significantly more complicated than preparing a set of slides. The activity needed to be engaging, manageable and aligned with the learning objectives. The rules needed to be clear enough for students to follow while still illustrating the programming concepts I wanted them to understand.

Traditionally, refining an activity like this would involve numerous cycles of trial and error. AI dramatically accelerated that process.

Before the lesson, I used AI as a design partner. It helped me identify weaknesses in the rules, test different scenarios and refine the structure of the game. Instead of manually working through every possible outcome, I could quickly explore alternatives and improve the activity before students ever encountered it.

Importantly, AI was not making pedagogical decisions.

AI could help identify whether a game mechanic was balanced. It could not determine whether the activity would support learning. It could not decide what students needed to understand or what experience would best help them develop that understanding.

When discussions about AI in education occur, the focus is often on students using AI tools. This experience highlighted a different possibility.

Students still had to do the learning themselves. They had to think, participate, make decisions and build understanding through experience. AI did not replace that process.

What it did was give me more capacity to design and refine the conditions in which that learning could occur.

Perhaps this points to a broader lesson about teaching in an AI-rich world. The most important question is not what AI can do. The more important question is what we want students to learn.

Once that goal is clear, AI can sometimes help teachers create better pathways towards it. In this case, AI helped design the game. But the learning came from students experiencing, discussing and making sense of the ideas for themselves.