Most AI Training Teaches Teachers to Prompt. We Taught Them to Build

Part of How to Design AI Professional Development That Changes Practice. This post is a worked example of the Create level of UNESCO’s AI competency framework for teachers, drawn from the KFAS Future Educator programme in Kuwait.

Everyone is teaching teachers to use AI. Almost nobody is teaching them to build with it.

That distinction matters. Using AI usually means typing a prompt into a chat tool and getting a response. Building with AI means designing a system where the model is one step in a larger process: pull data from a spreadsheet, generate content against a rubric, run a quality check, and deliver the output to a classroom channel, automatically, on a schedule.

UNESCO’s AI competency framework for teachers defines three progression levels: Acquire, Deepen and Create. Most teacher AI training stops at the first two, learning to use tools and integrating them thoughtfully into practice. The Create level asks for creative configuration of AI systems, including combining or modifying open-source and customisable toolkits for local educational challenges. In practice, I have seen almost no programmes that take educators there.

In Kuwait, on the KFAS Future Educator programme, we tried. This post explains what we built, the teaching sequence that made it work, what participants produced in two hours, and what I would change next time. The case study for the wider programme is on Future Educator: AI for STEM teachers. The design principles sit in the AI professional development guide.

The ask

In November 2025, participants asked for something specific: more technical sessions. They wanted to move beyond prompting and explore what happens when AI becomes part of a larger system. We responded with a workshop focused entirely on building working AI automation workflows.

We used n8n, an open-source automation platform with a visual interface. You drag nodes onto a canvas and connect them. Each node does something specific: read data from a spreadsheet, call a model to generate content, send an email, save to a document. The power is in the connections. It is not what any single node does, but what happens when you chain them together.

We ran separate two-hour sessions for primary, secondary and higher education groups. Each worked with workflows designed for their teaching context:

• Primary educators explored a differentiated reading comprehension generator.
• Secondary educators worked with an exit ticket generator that produces both student and teacher versions at the same time.
• Higher education instructors tackled batch essay feedback: a set of student submissions processed against structured rubric criteria, with feedback written back to a spreadsheet and a class-wide patterns report generated automatically.

Within two hours, educators who had never seen a workflow tool were designing and running their own AI-powered systems.

Explore first, then build

The approach that made this work was not the tool. It was the teaching sequence.

Each group received two versions of their workflow: a full version that was production-ready, with quality loops and multiple outputs, and a starter version simplified to four or five core nodes. We showed the full workflow first. Participants then explored it through a structured scavenger hunt: where does the data come from? How does it flow through AI processing? Where are the quality checks? What are the outputs?

Only after understanding the complex version did they switch to the starter workflow and begin modifying it themselves. Primary educators added a difficulty dropdown. Secondary educators added a quality check loop. Higher education instructors added new rubric criteria.

This sequence, study the expert version, then modify the simple version, is deliberate. It draws on the worked example effect from cognitive load theory: for novices, studying a complete worked example before attempting their own work produces better learning and transfer than jumping straight into problem-solving. The cognitive load of understanding a new tool, a new paradigm and a new task all at once is too high. Separating “understand the pattern” from “apply the pattern” made each step manageable.

Exploring the full workflow built understanding. Modifying the starter workflow built confidence. Participants left with both: a professional tool they could use the next day, and the skills to customise it.

What participants built

The hands-on session produced workflows that went well beyond our templates.

A primary teacher created a workflow triggered weekly to generate a curriculum-aligned, locally contextualised story for her class. It pulls from her curriculum standards, generates age-appropriate content set in familiar Kuwaiti contexts, and automatically posts to her Microsoft Teams classroom channel every Sunday evening.

A secondary teacher built a daily research briefing: the workflow searches for recent news on topics she teaches, filters for relevance, generates a personalised summary, and emails it to her each morning before school.

Both workflows took shape within the 30-minute hands-on period. Neither teacher had used n8n before that morning.

One group discussed automating parent communications in both Arabic and English. Another explored generating differentiated homework based on that day’s lesson performance. The ideas went further than what we had prepared. Participants were not asking whether they could do things, but how.

Why this matters beyond the workshop

There is a widening gap between what the frameworks call for and what teacher training actually delivers.

UNESCO’s Create level is explicit about customising and modifying AI toolkits for local challenges. The OECD and European Commission’s AILit Framework includes a Manage AI domain: decide whether AI is appropriate for a task, choose an approach, decompose a problem so that some steps are automated and others stay with the person, and monitor the result. That is workflow design described in policy language.

The problem is not that educators lack the ability to work with AI systems. It is that we are not teaching them how. We have collectively decided that “AI training for teachers” means prompt engineering and stopped there. Prompting is a useful skill. But it keeps educators in a reactive loop: type a request, get a response, evaluate, repeat. Workflow design is different. It asks: what process do I want to automate? What inputs does it need? What checks should it include? Where should the output go? That is systems thinking, not just tool use.

The speed at which participants in Kuwait moved from “I have never seen this tool” to “here is how I would automate my weekly lesson prep” suggests the barrier is not technical aptitude. It is exposure. Give educators a visual tool, a clear pedagogical sequence and a realistic use case, and they will build things that surprise you.

What I would do differently

The starter workflows were probably too simple. We had worried about technical overload, but participants consistently wanted to add more features: additional quality checks, extra outputs, integration with other school systems. Next time, I would pitch the starter version slightly higher and see what happens.

I would also add a collaborative design phase. The strongest ideas emerged from table conversations, not individual work. Building in structured time for pairs to design a workflow on paper before touching the tool would likely produce even better results.

And I would connect the workshop more explicitly to the rest of the programme. In Kuwait we already used a simple Human-AI Partnership pattern (Define, Draft, Refine, Validate, Deliver) so that review sat inside every classroom workflow. The automation session works best when that judgement loop is already familiar, so teachers treat quality checks as part of the design rather than an optional extra.

What this means for AI training design

This workshop reinforced something I keep coming back to in the professional development guide: educators do not need to be convinced that AI is useful. They need structured pathways to move from using it to building with it.

The two-workflow approach, a professional version to study and a simplified version to modify, provides that pathway. It works because it respects both the complexity of the tool and the intelligence of the learner. It also matches Design principle 3 in the guide: practise on real tasks teachers already own, rather than toy demos.

The question I am sitting with now is about scale. This worked with educators in a well-resourced workshop setting. What does it look like when a school or ministry tries to build this capacity internally, without an external facilitator? That is the design challenge I am working on next, and it is why the train-the-trainer path in the Kuwait case study matters as much as the workshop itself.

If you are designing AI professional development and want to push past prompting into Create-level practice, start with one real workflow your teachers already need, show them a finished version, then give them a simpler one to change. The tool can be n8n or something else. The sequence is the point.

Related reading: How to Design AI Professional Development That Changes Practice, Future Educator: AI for STEM teachers, AI in Education: Lessons from Kuwait, and Designing a 24-week AI training programme.