1.1 Yang in the 1990s: Claiming Pedagogical Agency

In the 1990s, Yang began his career as an English teacher at a Hong Kong primary school, bringing fresh ideas from his teacher education program and recent professional development workshops. During these workshops, researchers happened to introduce him to “whole body sense-making,” a pedagogical approach that enhanced instructional clarity by combining verbal explanations with visual aids and purposeful body language in creating a better English learning environment. Yang was captivated by the strategy’s potential and introduced it to his new school.

The principal was supportive and even asked Yang to lead professional development workshops for other English teachers. Yang found colleagues who shared his passion and wanted to form a teaching team around these ideas. But he also encountered resistance from older teachers who, while appreciative of his efforts, saw the approach as “for younger teachers.” They cited physical limitations and worried they would be laughed at by students if they adopted Yang’s gestural teaching style.

Despite this resistance, Yang persisted. He did not simply implement a method handed down by researchers: He adapted it to his context, built a community of practice around it, and claimed agency over how pedagogical innovation would unfold in his classroom and school. This was teacher agency in action: the capacity to evaluate, adapt, and champion approaches that aligned with his professional judgment about what his students needed.

1.2 Yang in 2023: When Teacher Agency Meets AI

Fast forward to 2023. Yang had spent decades at the same primary school, beloved by students and respected by colleagues. Then one day, he noticed something troubling: Students who typically underperformed in his class were suddenly producing exceptionally good English writing. His first fear was that students were plagiarizing, copying from each other. The truth turned out to be both simpler and more disorienting. His students had discovered ChatGPT.

Those carefully designed assignments crafted from decades of teaching experience and refined through countless iterations to support student learning were being completed in seconds by an AI agent that required no thinking, no struggle, no learning process from the students at all. Everything Yang had built his career around seemed suddenly rendered helpless.

Around this time, Yang’s school established a partnership with a university research team to integrate ChatGPT and other AI tools into teaching. Yang was asked to carve time from his already overloaded schedule to attend training sessions on “teaching English with ChatGPT.” But in his mind, he already knew how to teach English well without it. This new thing called AI, which everyone now talked about breathlessly, seemed only to devalue his decades of accumulated expertise.

Yang experienced a discomfort eerily similar to what those older teachers must have felt in the 1990s when he had urged them to adopt whole-body sense-making. He recognized, with some irony, that he had long since stopped using those gestures himself. The passionate innovator of the 1990s had become the reluctant adopter of the 2020s.

1.3 The Question of Agency

After reading Yang’s story, questions likely emerge. Will AI prove to be just another wave washing through education, like whole-body sense-making and countless other pedagogical innovations before it, exciting on arrival, forgotten within a decade? What transformed Yang from an innovative teacher eager to experiment with new ideas into someone troubled by his students’ use of ChatGPT, viewing it as disruptive to his teaching and dismissive of his hard-won expertise?

The answer lies in a concept that forms the core of this Element: teacher agency. The integration of AI into education should not become yet another wave of technological innovation that strips teachers of agency, along with their capacity for innovation and their professional passion. As scholars have long critiqued regarding university-led research interventions, when innovations are done to teachers rather than by or with them, agency erodes.

But here is the crucial difference between the 1990s and now: In the 1990s, Yang could claim agency through pedagogical means alone – by adapting teaching methods, building communities of practice, and advocating for approaches he believed in. In the 2020s, the innovations reshaping his classroom are not primarily pedagogical; they’re technological. And unlike pedagogical methods that researchers present for teachers to evaluate and adapt, AI technologies often arrive as closed systems developed by distant tech companies, implemented through top-down mandates, leaving teachers as users rather than agents (International Task Force on Teachers for Education 2030, 2025).

The question Yang faces is not whether AI will influence his classroom; his students have already answered that. The question is whether he can reclaim the same kind of agency over AI that he once exercised over pedagogy.

1.4 How to Read This Element

If you are a technologist or AI developer working in education, you might be tempted to skip the theoretical sections about teacher agency and professional identity. Please don’t. The teachers you are building for or, better yet, building with, experience technical work not as neutral tool use but as deeply connected to their professional identity, autonomy, and sense of meaning in their work. Understanding this is not peripheral to your technical practice; it is central to building educational AI that actually serves learning. The theoretical framing helps you see what is at stake for teachers when they engage with your “tools.”

If you are an educational researcher or theorist, you might be tempted to skip the technical sections as implementation details beneath the level of critical analysis. Please don’t. Theory that remains disconnected from the material practices of building technology risks becoming what teachers often experience as “discussion above the clouds,” making it intellectually sophisticated but practically inert. The technical sections are not just examples illustrating theory; they are where theoretical commitments meet real constraints, where abstract critical principles encounter actual decisions, where you discover what your critical analysis actually means when you have to make something work.

If you are a teacher considering whether to engage with AI development or questioning whether you should resist it entirely: You need both what the theorists bring (frameworks for understanding what’s happening to your professional agency) and what the technologists bring (demystification of what’s actually possible). You should not have to choose between critical consciousness and practical capability. You need both.

The integration itself is the argument. Teacher agency in the AI era cannot be reclaimed through theory alone; rather, you have to build something. But building without critical reflection on purposes and conditions risks reproducing exactly the problems we are trying to solve. And technical work disconnected from teacher identity and pedagogical purposes creates tools that teachers experience as alienating rather than empowering.

So we are asking everyone to stretch into uncomfortable territory. Theorists, engage with code. Technologists, engage with questions of meaning and identity. Teachers, engage with both, not because you must become computer scientists or critical theorists, but because the integration of these perspectives is how we create different futures for educational AI.

The messiness of moving between theoretical argument, personal narrative, and technical guidance mirrors the messiness of actually doing this work. We have tried to make that messiness productive rather than apologizing for it. Stay with us through the sections that feel least familiar because that is often where the most important learning happens.

1.5 The Technical Mystique

One of the most significant factors preventing teachers from claiming agency over technological innovation is what we call the “technical mystique”: the widespread belief that AI development requires specialized expertise far beyond educators’ reach. This mystique creates a psychological barrier that relegates teachers to the role of consumers, and sometimes dummy ones, rather than creators of educational technology. It suggests that while teachers might adapt new classroom pedagogy (like whole-body sense-making), they cannot possibly engage with the technical substrates of AI systems.

This Element challenges that mystique directly. We argue that the technical barriers teachers face are often more perceived than real, and that educators can become active creators of AI technology (Zhai, Reference Zhai2025), developing solutions that are pedagogically tailored, ecologically sustainable, and responsive to their students’ actual needs. The path to reclaiming agency in the AI era does not require teachers to become computer scientists. It requires demystifying AI development enough that teachers can apply the same adaptive, innovative thinking they have always used in their pedagogical practice (Fengchun & Mutlu, Reference Fengchun and Mutlu2024; International Task Force on Teachers for Education 2030, 2025).

Yang’s story illustrates what happens when agency is lost. The sections that follow show how it can be reclaimed not by rejecting AI, but by teachers becoming developers of the AI tools that serve their educational communities.

1.6 Why Teachers as AI Developers?

Beyond dismantling the technical mystique, we must address a fundamental question: Why are teachers potentially invaluable contributors to AI in education? The answer lies in understanding what differentiates teacher-developers from commercial AI developers and why that difference matters.

Developers at commercial AI companies often pursue goals centered on scale and competitive advantage: training ever-larger models, topping benchmark leaderboards, and outperforming rival firms’ products. These are legitimate business objectives, but they do not necessarily align with the nuanced, context-specific goals that drive teaching and learning in actual classrooms.

Teachers, by contrast, work toward classroom-based and community-specific goals that AI could help achieve but often at a scale and specificity that commercial products overlook. Consider Yang’s situation: He finds himself increasingly exhausted by answering the same foundational questions from students, questions that are absolutely necessary for learning but repetitive. Could Yang delegate some of this repetitive work to an AI agent, freeing time for his own professional development or simply for rest and family, without positioning his own needs against his students’ learning needs?

Of course, Yang could subscribe to ChatGPT or encourage his students to do so, enabling more self-directed learning. But this solution comes with impacts on student learning and significant financial and environmental costs that deserve scrutiny. Commercial AI services, trained by consuming enormous amounts of computational resources and energy, are undeniably powerful (Muldoon et al., Reference Muldoon, Graham and Cant2024). Yet they may not be the most sustainable solution for teachers’ everyday goals and tasks, particularly when similar levels of effectiveness could be achieved with only a fraction of the cost, energy consumption, and environmental footprint.

This realization points to a crucial possibility: Teachers can benefit from acquiring a certain amount of technological knowledge, not an overwhelming amount but just enough to utilize freely shared resources from technology communities with similar goals and far smaller environmental footprints. The question then becomes: What does “just enough” knowledge look like?

1.7 Three Levels of Teacher Technical Proficiency

We propose a framework of three levels of technological knowledge and skills that can enable teachers to accomplish different kinds of tasks and reach varying degrees of autonomy in AI development. These levels are not rigid stages but rather overlapping capacities that teachers can develop based on their goals, interests, and contexts.

1.8 The Power of “Just Enough” Knowledge

Figure 1 demonstrates the three levels with an explanation of the transition phase. These levels are not rigid stages but overlapping capacities that teachers can develop based on their goals, interests, and contexts. Teachers may operate at different levels for different tasks, and progression is not necessarily linear. The framework serves to clarify what kinds of autonomy different levels of technical knowledge enable, helping teachers make informed decisions about how much technical proficiency they want to develop for their specific purposes.

Figure 1

Three levels of teacher technical proficiency.

These three levels are not meant to establish a hierarchy where Level 3 is inherently superior to Level 1. Different teachers with different goals, contexts, and interests will find different levels appropriate for their needs. A teacher who primarily wants to make informed decisions about adopting AI tools may thrive at Level 1. Another teacher who wants to create custom classroom applications may aim for Level 2. A teacher who delights in technological tinkering may pursue Level 3 and beyond.

What matters is that teachers have access to pathways for developing the level of technical capacity that serves their professional goals, not the goals imposed by commercial vendors or technical gatekeepers. The technical mystique would have teachers believe that meaningful engagement with AI requires expertise far beyond reach. Our framework suggests something different: that “just enough” knowledge, thoughtfully acquired and purposefully applied, can transform teachers from passive consumers into active agents of educational AI innovation.

In the sections that follow, we explore visions for teacher-led innovation and sustainable practice that we have recently come across in our research and collaboration with teachers.

1.9 AI Development as Familiar Pedagogical Practice

Teacher-led AI innovation, as we envision it, actually mirrors processes already deeply familiar to educators – the same exploratory, iterative approaches teachers use when adopting new pedagogical methods or designing curriculum. When teachers encounter a new teaching approach, they do not immediately implement a fully formed system. They go through stages: exploring possibilities, deconstructing what the method entails and what it could achieve, experimenting with adaptations, reflecting on outcomes, and gradually building toward confident implementation.

The process of teacher-led AI development, particularly when working with AI coding assistants, follows remarkably similar patterns:

• Exploration and discovery – teachers begin by exploring what is possible with current AI technologies. This stage involves curiosity-driven investigation: What kinds of educational tools can be built? What problems do existing solutions solve? What gaps remain? This exploration requires no coding ability but the same evaluative judgment teachers apply when assessing any new educational resource.

• Educational design and conceptualization – the crucial work happens at the design stage, where teachers leverage their pedagogical expertise to envision what an AI tool should accomplish. What learning outcomes should it support? What kind of interactions will benefit students? How should it provide feedback? What contextual factors matter? This is fundamentally educational design work that teachers excel at rather than technical implementation.

• Partnership with AI coding assistants – here is where the paradigm shift occurs: Teachers do not need to write code from scratch. Instead, they communicate their educational vision to AI coding assistants, which handle the technical implementation. A teacher describes the desired functionality such as “I need a tool that helps students practice English conversation with cultural context sensitivity” and the AI assistant generates the code. The teacher’s role is to provide clear specifications, evaluate whether the results match their pedagogical intentions, and iterate through refinements.

• Testing and pedagogical refinement – as with any educational innovation, the first version is never perfect. Teachers test AI-generated tools in their classrooms, observe how students interact with them, and identify what works and what needs adjustment. But critically, these adjustments are driven by pedagogical insights, not technical expertise. Teachers communicate needed changes to their AI coding assistant such as “students need more scaffolding at this stage” or “the feedback should be more encouraging” and the AI handles the technical modifications.

• Iteration based on educational insight – the iteration cycle continues, but it remains grounded in educational judgment rather than technical prowess. Teachers are not debugging code; they are refining educational experiences. The AI coding assistant serves as a responsive implementation partner that translates pedagogical vision into functional technology.

• Community and knowledge sharing – teachers can share not just finished tools but also design patterns, pedagogical approaches, and effective ways of communicating with AI assistants. A teacher who successfully created a vocabulary learning tool can document their design thinking and prompt strategies, enabling other teachers to adapt the approach to different subjects or contexts. The focus shifts from sharing code to sharing educational design wisdom.

1.10 From Consumers to Educational Designers

The vision we propose fundamentally repositions teachers as educational designers who leverage AI coding assistants as implementation partners. In this model:

• Teachers with Level 1 proficiency (AI literacy) understand enough about AI capabilities and limitations to envision appropriate applications, evaluate existing solutions, and articulate educational needs clearly.

• Teachers with Level 2 proficiency (AI-assisted development) can work fluently with AI coding assistants to develop custom educational tools, translating their pedagogical vision into functional applications through iterative dialogue with AI.

• Teachers with Level 3 proficiency (code-informed adaptation) can directly examine and modify AI-generated code when needed, enabling more sophisticated troubleshooting and refinement which remains optional rather than essential.

Importantly, the center of gravity stays with educational design throughout. The technical implementation becomes a translation process handled primarily by AI assistants, freeing teachers to focus on what they do best: designing meaningful learning experiences.

2.1 Demystifying AI

The barriers teachers face in implementing AI may not lie in understanding the novelty or complexity of how AI works but rather in learning to navigate a techno-social space with conventions and abstractions that lack clear equivalents in everyday experience. Consider, for instance, the difference between a portable document format (PDF) document that allows you to copy and paste text versus one that does not. To our eyes, these two types of documents look nearly identical – we wouldn’t usually notice any difference. Without knowing that text might be stored as images in a PDF file, we might develop other explanations for why we cannot simply copy and paste certain sections of text from a PDF file. And with advances in some PDF readers that now automatically perform OCR during copy–paste actions, the distinction blurs further. We are left puzzled when the copied text appears garbled or improperly formatted, not understanding why it works smoothly in some cases but not others. We then explore other possible solutions that are destined to fail, such as that the mouse might not be working properly or the PDF reader needs to be removed and reinstalled.

This is usually where frustration sets in and self-questioning begins: “Ah, I’m not a tech-savvy person” or “This isn’t for me.” Gradually, these small but repeated incidents, moments when we feel we cannot perceive what’s actually happening, accumulate into perceived barriers. The technical dimensions of work seem impossibly difficult, and we conclude that we should leave it to the technology experts. Yet these are not personal failings but rather just some gaps in our understanding of some invisible technical distinctions. Similar significant differences hiding behind seemingly identical things pervade development work. Here’s another example: In Python programming, the number ‘5’ (in quotes) and the number 5 (without quotes) may look nearly identical on screen, but they represent fundamentally different data types: ‘5’ is text (a string), while the other (5) is a numeric value. Try to perform mathematical operations on ‘5’ and you’ll encounter cryptic error messages which, without this context, seem to confirm your worst fears about your technical inaptitude.

These invisible technical distinctions are not arbitrary quirks. They are the sediment of decades of specialized problem-solving, in which each solution is optimized for technical efficiency rather than intuitive understanding. For instance, PDF technology was developed in the early 1990s to ensure documents would display identically across different computers, even when recipients lacked the original fonts or software (hence the name PDF: portable document format). This “portability” was revolutionary for its time, but it created a fork in the road: PDFs could either prioritize text extractability (storing actual text data) or visual fidelity (essentially creating a picture of the page). When documents are scanned from paper or created by certain applications prioritizing appearance, they take the “image” path, looking perfectly readable to the human eye while being invisible to copy–paste functions. Similarly, today’s AI systems emerged from a fundamental paradigm shift in how we approach language understanding. Earlier systems (from the 1960s through the 1990s) relied on “natural language processing” (NLP) linguists and programmers painstakingly coding grammatical rules and logical relationships. Modern generative AI (GenAI) took a radically different path: Rather than explicit rules, these systems learn statistical patterns from vast amounts of text, developing their own implicit “understanding” through exposure. Therefore, AI “understanding” is not exactly the same as human understanding but perhaps more in the sense of statistical pattern associations. Each of these technical evolutions solved real problems for their creators, but in doing so, they created new layers of abstraction: new “grammars” that diverged further from everyday intuition. The result is a techno-social landscape shaped by the accumulated decisions of specialists solving specialist problems, leaving nonspecialists to navigate a space that was never designed to be compatible with their intuitions.

2.2 From Mystification to Professional Disempowerment

Teachers encounter invisible technical distinctions repeatedly. For example, when a tool works perfectly in a tutorial but fails mysteriously in their hands (e.g., a PDF file does not release its text for the copy-and-paste function), the error message seems to blame them for something they do not understand. This is when the technical mystique becomes internalized. What begins as an external perception (“AI development requires specialized expertise”) gradually transforms into a personal belief (“I lack the capacity for this kind of work”).

This pattern resembles what researchers term learned helplessness, a phenomenon where repeated experiences of uncontrollable outcomes lead individuals to stop trying to exert control. First identified by Seligman and Maier (Reference Seligman and Maier1967) in psychological research, the concept was subsequently applied to educational contexts by scholars such as Dweck and Repucci (Reference Dweck and Repucci1973) and Fincham et al. (Reference Fincham, Hokoda, Sanders and Jr1989), who demonstrated how this dynamic manifests in classroom settings where students develop stable beliefs about their inability to succeed despite having the capacity to do so. However, what teachers experience is more bounded and specific: a domain-specific erosion of what educational researchers call “technological self-efficacy” (Bandura, Reference Bandura1997; Wang et al., Reference Wang, Ertmer and Newby2004), the belief in one’s capability to successfully engage with technology. The paradox is striking: A teacher who confidently masters complex pedagogical frameworks, who navigates intricate classroom dynamics, who advocates effectively for students, may simultaneously hold a firm belief that “I am not a tech person.” This narrowing of perceived capability does not reflect actual inability. Rather, it reflects the accumulated weight of frustrating navigation in techno-social spaces that were never designed to be intuitively navigable by nonspecialists.

The technical mystique thrives in this psychological space. Each unexplained failure becomes evidence that “I’m not a tech person,” that “this is beyond me,” that “I should leave this to the experts.” What begins as a reasonable response to confusing feedback calcifies into a stable belief about personal capacity: “I can’t understand what’s happening.” The distinction is crucial. The former is a gap in conversational fluency that can be developed; the latter is a perceived limitation in ability that becomes self-fulfilling, preventing the very learning-through-practice that could build fluency.

But here is what makes this particularly consequential in educational contexts: Teachers are not just individuals struggling with technology in private. They are professionals whose relationship with learning is constantly on display. When faced with a technical obstacle in the classroom, such as struggling to display a PowerPoint in full screen or being unable to connect to the projector, the teacher’s identity seems to demand transparency and honesty about their limitations. Many teachers respond by delegating these seemingly simple technological tasks to students who “know the tricks.” While this solves the immediate problem, it comes at a hidden cost. The technological knowledge required becomes reframed as mere “tricks” that young people would “naturally” possess or dismissed as “just technical details” peripheral to the real pedagogical work that remains firmly in the teacher’s agentic control.

Both patterns, attributing technical fluency to youth as an innate quality and minimizing technology as auxiliary to “real” teaching, create an artificial and unnecessary boundary around teacher agency. They prevent teachers from recognizing that technological capability could be as much within their professional domain as curriculum design or classroom management. The result is a self-imposed limit on what teachers believe they can control: Pedagogical goals remain theirs, but the technological means to achieve those goals are ceded to others, be it tech-savvy students, IT departments, or commercial platform providers. What begins with “Can someone help me get this in full screen?” can gradually expand into “I’ll let the experts handle the AI tools.”

It is important to point out that there is nothing inherently wrong with these choices. Every teacher must decide their own comfortable level of technological engagement, and delegating technical tasks can sometimes be a perfectly reasonable division of labor. However, if you find yourself sensing that these arrangements have become limiting, that is, if you have begun to wonder whether your pedagogical vision is constrained by what you believe you cannot do technologically, then it may be worth revisiting the three levels of AI engagement we discussed in the previous sections. The question is not whether you should want to move to a different level, but whether you could if you wanted to, and whether current beliefs about your capabilities are based on actual limitations or on the accumulated mystification we’ve been examining. Of course, the danger is that we simply replace one mystique with another – celebrating the “teacher-developer” as the new hero narrative. The point is not to romanticize coding or educational AI development but to keep it within professional reach, just as learning the assorted tricks for showing a PowerPoint in different rooms is within reach, rather than proof of some innate technical gift. The story that follows traces the thinking and planning process behind developing an AI-assisted dialogue system (ADS) for nursing education, from its initial conception through Version 1. Along the way, we will illustrate how we gradually learned the “grammar” of AI development – how we became more familiar with the techno-social space created by AI specialists and learned to articulate our pedagogical goals in ways that allowed AI agents to help us achieve them. The technical implementation details of this project and its subsequent iterations (Versions 2, 3, and 4) can be found in Section 4. In this section, we focus on the bigger picture of the learning process itself: how we moved from feeling mystified by AI technology to reclaiming our agency as educators who could shape technology to serve our pedagogical vision.

2.3 Breaking Down Our Project: How an ADS for Nursing Education Was Built Using Basic Web Technologies and AI Libraries

Recently, our research team launched an innovative project: creating an ADS for English-medium nursing education. This system, developed for our nursing educator collaborators and their students, embodies our research-informed understanding of authentic nursing communication. Drawing on years of ethnographic research in content- and language-integrated learning within Hong Kong’s English-medium nursing programs (e.g., Liu & Lin, Reference Liu and Lin2025) and grounded in our theoretical framework of ecological languaging competencies, we conceptualize nurse–patient communication as situated within a holistic, ecological system. This approach reflects the plurilingual and pluricultural scenarios nurses encounter in everyday practice.

2.4 The Learning Journey Begins

It would be tedious and unhelpful to paste our entire chat record with various AI systems here. Instead, we have analyzed our conversations and identified the key learning breakthroughs: the moments when mysterious technical concepts suddenly clicked into place.

We communicated our theoretical perspective and our vision for the system to GenAI, asking it to suggest possible pathways we could pursue to achieve our development goals step by step. During this process, we also made clear what we did not want to use, such as solutions that would lock us into expensive commercial platforms or require server infrastructures. Through these initial conversations, we encountered many technical terms we were not familiar with, but the journey began.

3.1 Barrier 1: Conceptual Barriers – Learning to Think in Technical Abstractions

Conceptual barriers emerge when technical concepts do not map neatly onto anything in our everyday experience. These are not “hard” barriers in the sense of requiring advanced mathematics or computer science degrees, but they require learning the community of practice, including thinking and talking about issues in the techno-social space. As pointed out by Lemke (Reference Lemke1990), it requires not only understanding individual concepts but also grasping the thematic relations between these concepts.

For example, after we explained our needs to our AI coding assistant, we got an AI-coded HTML (HyperText Markup Language) file. This file, containing both content and layout information and widely used in coding webpages, in fact needs to be “deployed” through services like Netlify, which uses its server space to publish the website on the internet without requiring us to manage server-side issues (web servers, networks, etc.). The word “deploy” already contains many important steps that are not known to many educators. Recall our earlier discussion of the techno-social space: These are the “levels of abstraction” that are hard to find concrete equivalents in our everyday life. The challenge is not cognitive complexity; it is conceptual reorganization and compression, especially regarding the thematic patterns involved.

We further categorize these conceptual barriers into three domains: web-related concepts, programming-related concepts, and AI model–related concepts. We offer key examples from each rather than exhaustive lists.

3.2 Barrier 2: Decision-Making Barriers – Navigating Trade-offs with Incomplete Understanding

If conceptual barriers involve learning new ways of thinking, decision-making barriers involve acting on incomplete understanding and making consequential choices before fully grasping all their implications and being ready to accept painful but sometimes necessary setbacks as lessons learned. This is, in many ways, the most psychologically difficult barrier we faced because it can easily leave us disheartened and tempted to surrender to the discourse of “this is not for me.” As linguists and educators, we are comfortable in our own field and are able to articulate precisely what we want to achieve, such as describing in rich detail the kind of nurse–patient interaction we want to simulate, including the emotional nuances we want students to navigate. But translating these clear educational visions into technical implementations requires constant compromise, and we often cannot fully understand the trade-offs we are making until afterwards.

3.3 Barrier 3: Iterative Learning Barriers – Navigating Steep Learning Curves and Cascading Complexity

The third type of barrier emerged from the recursive nature of technical development: Solving one problem reliably surfaces new problems requiring new learning. Just when we felt we had achieved some solid understanding, implementation would reveal new gaps in our knowledge, often with sharp learning curves that felt overwhelming. This iterative learning process has a particular emotional texture: Each time we thought we were “almost done,” we would discover another layer of complexity requiring substantial new learning. The finish line kept receding.

3.4 Synthesis: How the Three Barriers Interact

These three barriers – conceptual, decision-making, and iterative learning – do not occur sequentially but are intertwined throughout the development journey. Conceptual barriers make decision-making harder (how can you choose between approaches you do not fully understand?). Decision-making creates iterative learning needs (implementing a decision reveals usually new concepts to master). Iterative learning surfaces conceptual gaps (trying to use GitHub revealed we did not understand “version control” as a concept).

Understanding these barriers as distinct but interrelated helped us recognize what kind of difficulty we were facing at any moment. Feeling overwhelmed by technical terminology? That’s a conceptual barrier and we have strategies for that. Paralyzed by choosing between two implementation approaches? That’s a decision-making barrier that we can make a best pick for now and adjust if needed. Frustrated that “one more thing” kept emerging? That’s an iterative learning barrier and we can time-box our learning and accept good-enough understanding for now.

Most importantly, recognizing these as navigable barriers, as challenges that could be worked through with strategies and persistence, rather than evidence of fundamental unsuitability for technical work, was itself a crucial conceptual shift.

4.1 AI Created a System in One Click

Our first version emerged from enthusiastic naivety. We knew almost nothing about web development, but we knew that Claude and ChatGPT could write code. So we did what felt natural: We described what we wanted in plain language. “Create a web-based system where nursing students can speak to a simulated Cantonese-speaking patient. The system should recognize student speech, determine appropriate patient responses, and speak those responses back.” Within minutes, AI generated a complete HTML file, claiming it contained the functions we required, including interface, speech recognition, conversation logic, and audio synthesis, all bundled together. It felt almost magical when we opened the file in a browser, clicked “Start,” spoke to it in Cantonese, and heard the simulated patient respond. The voice sounded robotic, but it worked! The technical mystique we discussed in Section 1 seemed suddenly dissolved. If AI can generate working code from plain descriptions, perhaps the barriers to teacher-led development are lower than we imagined?

This initial success was intoxicating but misleading. Yes, AI created a functioning prototype. But along the robotic-sounding voice made it more like a toy than pedagogically useful. In addition, AI made countless decisions that we did not understand, such as which service to use for speech recognition, how to structure the conversation logic and flow, when to trigger responses, and how to handle errors.

The code (see Figure 2) looked like an alien language:

Figure 2

Code sample 1.

We can now read this code after approximately six months of working on and further developing the system. We can now understand that it creates a speech recognition object (const recognition), tells it to listen continuously through the microphone (recognition.continuous = true), and processes recognized speech through a function called “processStudentInput.” But at the time, it was opaque. We had a working system that we did not understand, and therefore could not modify or maintain ourselves. At this stage, if we wanted to make any modifications or changes, we had to ask AI to write the complete code again and again.

4.1.2 Learning to See Structure through Working with AI

We asked AI: “Explain the structure of this HTML file. Which parts do what?” This meta-question, asking about code structure rather than asking for code modifications, proved to be transformative. AI explained:

• The <style> section contains visual appearance rules (CSS).

• The <body> section contains the page structure users see (HTML).

• The <script> section contains the behavior and logic (JavaScript). Within the script, there are variable declarations, function definitions, and event listeners.

This explanation gave us a mental map, although specific terminology such as “event listeners” remained opaque. The file was no longer an undifferentiated mass of mysterious text as it had distinct regions with different purposes. Although we still did not understand what CSS or JavaScript actually means, we developed a relatively vague idea that the CSS seemed to be about how the system would appear in a browser. We could see elements related to color and numbers indicating the width and height of buttons. In the JavaScript sections, we encountered elements that seemed to be performing the logic of the system. We found the annotations written by AI to be useful; they provided clues about what each chunk of code would do, and the code then became at least partially readable to us.

For example (see Figure 3), the annotation (the sentence following “//”) tells us that this chunk will perform some initialization of the page. Guessing from sentences like “Checking authentication …” we could assume that it represents a process of checking whether the user has logged into the system, potentially preventing users from accessing the system when they are not logged in. Because of this insight, we develop a new workflow: Instead of asking AI to regenerate everything, we started copying a specific function and asking, “Explain what this function does line by line.” For example, in relation to the code in Figure 4, AI responded: “This function takes the student‘s spoken words (transcript), converts them to lowercase for easier matching, then searches through predefined responses for keywords … ” Understanding one function at a time makes the code gradually less alien. In addition, we gradually acquired the ability to partially understand the code (although we are still not able to master the “grammar” and begin writing it ourselves independently).

Figure 3

Code sample 2.

Figure 4

Code sample 3.

This iterative learning with AI as a tutor rather than merely a code generator changed our relationship to the system. We were no longer only passive recipients of generated code; we became people who could understand, modify, and maintain code to the extent just enough for us to fix issues or add new features to our system. Still beginners, certainly, but beginners who can read and understand some part of the hidden processes rather than merely hoping the magic would work.

4.2 Version 2: Strategic Retreat and Deeper Understanding of Our Options

After the one-click version’s keyword-matching struggles and the limitations of the voice engine that generated robotic-sounding patient responses, we made what colleagues initially perceived as an admission of defeat: Version 2 abandoned real-time conversation entirely. Instead of attempting to understand student speech and generate responses through voice engines, we created a library of pre-recorded audio files, each accompanied by descriptive metadata (see Table 1). Based on this metadata, the system would simply select and play one of the pre-recorded patient voice files to the student.

This may sound like a retreat in terms of technical complexity, from having AI generate responses to having AI choose from pre-recorded sound files. However, although it may be a retreat in technology applied, it may well be an advance in pedagogical fitness. We were not yet able to remove the limitation of the open-source lightweight LLMs we were using, but we could control something immediately important: the authenticity of the patient’s voice. One of our team members who is a fluent Cantonese speaker volunteered to record patient responses with authentic emotion, pacing, and Hong Kong dialect variations. The recordings we have sound genuinely like an elderly lady from Hong Kong in ways that browser speech synthesis can never produce. With the metadata stored in an Excel file that labeled each voice recording, we were able to launch our Version 2, which simultaneously solved the problem of lagging time caused by the duration needed to generate text and synthesize speech. In the process of developing Version 2, we also accidentally learned another useful skill that greatly improved our workflow in collaborating with other team members. As mentioned, we pre-recorded patient voice files and simultaneously needed to label each recording with the metadata in Table 1. It would have been a huge burden adding to the already heavy workload of our usual teaching and research work, so we have learned Python (a programming language widely used in AI development and machine learning) to the extent that we could use a Python program written by AI to help us streamline the process of managing the metadata for each recording. We used the same Python program to help us generate an Excel sheet in which our collaborator could easily choose from the predetermined choices (like the choices in Table 1) built into the Excel file to help us manage the metadata of the recordings. The Python program was also able to help us process the metadata and then create JSON (JavaScript Object Notation), which could store the metadata in our system and make it ready for use. Consequently, the workflow became:

AI creates a Python program

↓

The Python program creates an easy-to-use Excel sheet

↓

The team works in the Excel sheet to add metadata to the patient’s voice recording

↓

The Python program parses the Excel sheet and generates a JSON file for the system

In the above workflow, the Excel sheet became an important intermediate communicator between the team members who conducted the engineering work and the team members who did the recording and possessed better knowledge about the information of each recording and its intended purposes.

4.3 Version 3: When Growth Demands Structure and Pedagogical Fit

Version 2 worked well for individual practice sessions, but accumulating use revealed a fundamental limitation: This was still a system that served individual practice in private. It did not yet possess the functionality to record or assess the practice. We tested the system within our research team and with a few other colleagues to gain feedback from them. After consulting nursing educators, we realized that the nursing program wanted to expand beyond a single wound-care scenario. Our collaborators envisioned different patient personas, such as an anxious young mother, a resistant elderly man, a confused patient with dementia, and each requiring different communication approaches. In addition, to ensure that nursing students are equipped with sufficient knowledge to carry out medical procedures such as wound cleaning, our collaborators wished to explore installing pre-assessments before the training conversation. They also wanted usage analytics: Which students practiced most? Which conversation stages caused difficulty? How long did typical sessions last?

After some discussion within our team, we concluded that Version 2’s single-file architecture could not accommodate this complexity. We brought our question to AI again and were told that our single file was already very complex, which could potentially cause issues. We could not simply keep adding features to one HTML file as it was already unwieldy. We needed multiple pages with different purposes: a landing page explaining the system, a registration page for student accounts, pre-test and post-test pages, separate training interfaces for different scenarios. We needed these pages to share information and coordinate their behavior. We then followed AI’s suggestion to embark on a new journey of modularizing the system. This was somewhat daunting at first because, as mentioned, we were already familiar with the single-file approach and were required to step into new territory again.

4.3.3 Learning Database Concepts through Supabase

AI recommended Supabase, a service providing database capabilities accessible through JavaScript, designed specifically for situations like ours where non-professional developers need database functionality without managing servers. We asked AI to explain the overall concept of databases conceptually before showing us code: “Explain how databases organize information differently than simply saving files.” We developed a relatively vague idea about databases, and then we embarked on our journey.

Implementing this required learning new concepts: SQL (Structured Query Language, though Supabase abstracted away most of it), table schemas (defining what columns exist and what type of data each holds), relationships (how tables connect), and authentication (verifying student identity to prevent unauthorized access). We in fact only half understand these concepts. However, we followed our AI coding assistant’s instructions and used SQL code to create our database, and now the structure appears as shown in Figure 5.

Figure 5

Database schemata.

The database schema that emerged represented our growing understanding of the relationships between different types of information: user profiles connected to training sessions, training sessions linked to specific patient profiles, video recordings tied to individual users, and pre-test results tracking student progress over time. We did not design this structure ourselves from scratch; we only described to AI what information we needed to track and why, and it generated the code for us to set up this database architecture. But we learned to read these diagrams, to understand what the connecting lines meant, and to recognize when the structure aligned with our pedagogical goals. This is another instance of developing “just enough” knowledge, not database administration expertise but sufficient literacy to verify that the technical implementation matched our educational intentions. Working with AI on this implementation taught us something crucial about learning technical concepts through AI assistance: The most valuable questions were not “write me database code” but rather “explain the concept of database tables” followed by “show me a simple example” followed by “now how would this work for my specific case?” This progression from concept to example to application proved more educationally sound than jumping straight to complete implementation.

4.4 Version 4: Orchestrating Intelligence

Version 4 represents our most ambitious leap: integrating lightweight LLMs that can process student communication and determine contextually appropriate patient responses, combined with professional voice synthesis and cloud-based data storage. But the technical complexity is not what made Version 4 significant. What mattered was how building it again transformed our understanding of what teacher-developers can do. We did not implement Version 4 by suddenly mastering AI systems, database management, and service orchestration. We implemented it by applying everything we had learned about working with AI coding assistants, combined with a growing comfort with technical concepts and a willingness to learn iteratively through failure.

4.5 The Sustainability Learning Moment

One crucial insight came from comparing our approach to what we may have built with commercial AI APIs. A colleague asked: “How much would this cost and what would be the environmental impact if you used ChatGPT or Claude instead of Transformer.js?” We did not calculate this precisely, but the comparison is stark. With commercial APIs, every student utterance would trigger a cloud AI query – dozens or hundreds per practice session, multiplied by all students in a nursing cohort, repeated throughout the semester. The monetary cost would accumulate quickly, potentially making the system financially unsustainable for educational institutions. The environmental cost, including the energy consumed by data center servers processing millions of queries, would be substantial. With Transformer.js, the model loads once per session, then processes all interactions locally with much less energy cost beyond what the device already consumes. No ongoing fees. No server infrastructure. No data center energy consumption. The trade-off is accepting that our intent matching is not as sophisticated as GPT-4 or Claude, but it is sophisticated enough. This crystallized an insight that became central to our understanding of teacher-lead development: The goal is not to build the most technically impressive system but to build a system that achieves educational goals sustainably. Sometimes “just enough” AI, running locally, serves students better than “state-of-the-art” AI that brings unsustainable costs and environmental impacts.

4.6 The Pattern of Teacher-Developer Growth

Our development trajectory followed a pattern that may be instructive for other teachers considering similar journeys:

5.1 The Open-Source Community: A Foundation for Sustainable Development

The open-source community represents one of the most significant resources for reducing the carbon footprint of educational AI development. Platforms like GitHub and Hugging Face have become vast repositories of freely available code, models, and educational resources that teachers can adapt rather than building from scratch. This ecosystem fundamentally changes the sustainability calculus of teacher-led development.

Hugging Face, often referred to as “the GitHub of machine learning,” hosts a great number of AI models from leading providers through a unified platform. More importantly, it provides many useful pre-converted models optimized for browser-based inference, educational toolkits translated into different languages, and countless examples of educational applications that teachers can study, adapt, and deploy. We have found this platform to be very useful for us, as it makes powerful AI accessible to educators, researchers, and developers regardless of their institutional resources or technical background.

Consider a few concrete examples of how existing open-source resources can dramatically reduce both development effort needed and environmental impact. A teacher wanting to build a language-learning application might discover an existing speech recognition model on Hugging Face that was trained on multilingual data. Rather than training a new model from scratch, the teacher can download this pre-trained model and adapt it to their specific pedagogical needs. Perhaps they need to change the user interface to align with their school’s branding, adjust the feedback mechanism to be more encouraging for younger learners, or modify the assessment rubric to match curriculum requirements. These modifications require minimal AI assistance compared to building the entire system from scratch.

Similarly, GitHub hosts countless educational AI applications with open-source licenses. A teacher may find a basic chatbot tutorial application and realize it contains all the functionality they need for their classroom. With AI as a coding assistant to help make targeted modifications – such as changing color schemes, adding a database to track student progress, or adjusting conversation flows to match specific learning objectives – the teacher can create a pedagogically appropriate tool while consuming only a fraction of the energy that building from scratch would require. This approach aligns perfectly with the learning-through-practice framework we have advocated throughout this Element. Teachers do not need to understand every line of code in an open-source project to adapt it successfully. They need sufficient literacy to identify which components handle which functions, to articulate what modifications would serve their pedagogical goals, and to work with AI assistants to implement those changes. The open-source community effectively provides the scaffolding that makes teacher-led development both feasible and sustainable.

5.2 The Importance of Continuous Learning with AI Coding Assistants

The relationship between technical learning and sustainability may not seem obvious at first, but it proved crucial in our development journey. The more we learned about code structure, programming concepts, and system architecture, the less we depended on AI to generate large amounts of code, and consequently, the lower our environmental footprint became. This connection between learning and sustainability represents one of the most compelling arguments for teachers investing effort in developing technical literacy.

Consider our early development phase with Version 1, when we treated AI as a magical code generator. Each time we wanted to modify something, we would ask AI to regenerate the entire HTML file, often 700 lines or more. Because AI frequently hits length limits, breaking code into incomplete chunks, we asked for multiple regenerations before achieving working code. Each regeneration consumes computational resources, including energy to run the AI model, cooling water for data center infrastructure, and electricity for data transmission. Multiplied across dozens or hundreds of modification cycles, this approach creates a substantial carbon footprint. As our technical literacy grew, our interaction pattern with AI fundamentally changed. By Version 3, when we understood code structure well enough to identify specific functions or sections needing modification, we asked AI to generate only those targeted pieces, such as 20–30 lines instead of 700. We then copied those lines into the appropriate location ourselves, tested the modification, and iterated if necessary. This reduced the computational burden on AI systems by an order of magnitude. Moreover, because we could read the generated code and identify errors ourselves, we also needed fewer iteration cycles, further reducing energy consumption. The environmental benefit compounds when we consider maintenance and updates. A system built without understanding requires AI regeneration for even trivial changes. But a system whose structure we comprehend can be maintained with minimal AI assistance. For example, when our nursing simulation system needed a small adjustment to the user interface, changing button text from “Start” to “Begin Practice,” we made this change ourselves in seconds without AI.

Beyond the direct environmental benefits, this learning process connects deeply to the teacher identity and agency themes we have explored throughout this Element. As we developed technical literacy, we experienced the same kind of professional growth that occurred when we first learned new pedagogical approaches. The difference is that this growth simultaneously enhanced our capability and reduced our environmental impact. Each concept mastered represents both professional development and environmental responsibility. This dual benefit creates a virtuous cycle that reinforces sustainable practices. When teachers recognize that learning to modify code themselves not only increases their autonomy but also reduces energy consumption, the motivation to develop technical skills strengthens. When they experience the satisfaction of making changes quickly and efficiently without depending on extensive AI generation, they develop appreciation for the elegance of targeted modifications over wholesale regeneration. The environmental imperative thus becomes woven into the learning journey itself, rather than being an external constraint or sacrifice. This learning-driven approach to sustainability challenges the false dichotomy between technical sophistication and environmental responsibility. One might assume that more advanced development requires more AI assistance and therefore higher energy consumption. Our experience suggests the opposite: As developers become more sophisticated in their understanding, they can work more efficiently with AI, making more strategic requests that generate less code but achieve more precise results.

5.3 The Sustainability Level of Our Whole System

The sustainability considerations we faced extended far beyond our interactions with AI during development. They fundamentally shaped the technical architecture of our ADS nursing training system, particularly in our selection of AI models for processing student conversations. The decisions we made regarding which AI technologies to employ represent one of the most consequential sustainability choices teacher-developers face.

The critical decision point came when we needed to determine how our system would understand and respond to nursing students’ speech during practice sessions. We essentially faced two pathways: using commercial API services from providers like OpenAI, Anthropic, or Google, or implementing browser-based AI using Transformer.js with locally processed models. In fact, we anticipated that it would be easier to go with commercial APIs because the performance is reliable and users will feel our system is as smart as OpenAI’s ChatGPT or Anthropic’s Claude. But in that case, we would have to make significant compromises on our sustainability goals, and we decided to go for the browser-based AI approach. This alternative approach using Transformer.js fundamentally altered this environmental equation. By implementing browser-based AI processing, we moved computation from energy-intensive data centers to the students’ own devices. The AI model loads once when the student opens the practice system, consuming a one-time energy cost equivalent to a few minutes of web browsing. After that initial load, all conversation understanding and response selection happens locally in the browser, with no additional cloud computation required beyond the initial model download.

We should acknowledge the trade-offs inherent in this architectural choice. The browser-based AI models we could use are necessarily smaller and less capable than the massive models available through commercial APIs. GPT-4 or Claude 3 would provide more sophisticated language understanding, more nuanced response generation, and better handling of unexpected student inputs. Our Transformer.js implementation, running a model with perhaps 100–300 million parameters rather than hundreds of billions, cannot match that level of sophistication. So, even some of our colleagues who tried our system has commented that it is not able to provide the level of sophistication in responses provided by commercial products in markets. However, we do not need our simulated patient to engage in philosophical discussions or demonstrate creative problem-solving. We need the system to understand nursing students’ questions and instructions, recognize their emotional tone, and select appropriate pre-recorded patient responses from our carefully designed library. For these specific tasks, a smaller model proved “powerful enough” while consuming a fraction of the energy and generating a fraction of the emissions.

Beyond the AI processing component, we implemented other sustainability-focused optimizations throughout the system. One significant example involves how we handled video recordings of practice sessions. Initially, we implemented video recording in high resolution with minimal compression, reasoning that higher-quality video would better capture students’ facial expressions and body language for later assessment. However, we quickly recognized that these uncompressed video files consumed substantial storage space, approximately 200–300 megabytes for a 10-minute practice session. The sustainability implications of this storage footprint extend beyond the obvious disk space consumption. Data storage in cloud services requires energy for the storage hardware itself, for cooling systems to maintain optimal operating temperatures, and for redundancy systems that maintain multiple copies to prevent data loss. AI helped us do the calculation: Storing 100 students’ practice videos at 300 megabytes each creates a 30-gigabyte footprint. Maintained over a semester with multiple practice sessions per student, this could easily reach hundreds of gigabytes, all requiring continuous energy consumption.

We addressed this by progressively adjusting video quality downward until we reached a level that remained “good enough” for our pedagogical purposes – specifically, sufficient resolution to observe students’ communication approach and body language during automated assessment but not unnecessarily high. By implementing higher compression and reducing the resolution from 1080p to 720p, we reduced file sizes to approximately 50–60 megabytes per session, which is an 80 percent reduction in storage requirements and corresponding reductions in the energy footprint of storing and processing these files. We continue to monitor whether this quality level adequately serves our assessment purposes and are prepared to adjust it if necessary, but initial testing suggests that 720p captures sufficient detail for evaluating nurse–patient communication competency.

These optimizations – from browser-based AI processing, judicious video compression, to efficient data storage – exemplify how sustainability considerations can become woven into technical decision-making without compromising pedagogical effectiveness. The key principle is matching technical capability to actual pedagogical need, rather than simply selecting the most powerful available solution. We do not need the smartest AI or the highest-resolution video; we need technology that serves our educational goals sustainably.

5.4 The Challenges of Educational AI Development While Maintaining Sustainability Goals

We would be dishonest if we portrayed our commitment to sustainability as unwavering and easy to maintain. Throughout our development journey, we repeatedly faced the temptation to abandon our environmental principles in favor of technical impressiveness or perceived competitive advantage. Understanding these temptations and how we navigated them may prove helpful for other teachers considering similar journeys.

The most persistent temptation arose from demonstrations and presentations. When preparing to present our system at academic conferences or to colleagues at professional development workshops, we acutely felt the limitations of our browser-based approach. We knew that if we switched to GPT-4 or Claude, the simulated patient responses would be dramatically more sophisticated. The conversation would flow more naturally. The patient would handle unexpected student questions more gracefully. The system would simply seem more impressive, more “cutting edge,” more aligned with the current enthusiasm surrounding LLMs. This temptation intensified when we observed colleagues presenting their own AI-enabled educational tools. Many had chosen commercial APIs or just having students use ChatGPT, Claude, DeepSeek, or Qwen. Their systems could engage in complex dialogues, generate novel scenarios dynamically, and showcase the full power of state-of-the-art language models. In comparison, our system with its pre-recorded responses and lightweight browser-based AI felt constrained, perhaps even dated.

We would fantasize about temporarily using commercial APIs “just for the demonstration,” reasoning that the environmental cost of a single presentation would be negligible compared to ongoing use. We could also show that the system is very capable. The tension became particularly acute when we considered funding and publication. AI-related research often depends on demonstrating great innovation and technical sophistication. Reviewers of grant proposals and research manuscripts may frequently favor work that pushes technical boundaries, that employs the most advanced available models, that generates results that could not have been achieved with simpler approaches. Our choice of lightweight, sustainable AI might be interpreted as a technical limitation rather than principled commitment. Would our work be taken less seriously? Would funding opportunities diminish? Would publication in high-impact venues become more difficult?

Moreover, we confronted questions about our responsibility to students. If commercial APIs can provide nursing students with more realistic practice experiences, are we not obligated to use them despite the environmental cost? The purpose of educational technology is to enhance learning. If our sustainability commitments compromise educational effectiveness, are we not prioritizing environmental principles over student needs? These questions haunted us during moments of doubt.

5.5 Contextualizing Pedagogical Need in the Global AI Frenzy

What ultimately kept us committed to sustainable development is a shift in how we framed the purpose and value of our work. An old Chinese saying from the Song Dynasty poet Xin Qiji – “为赋新词强说愁” (forcing oneself to express sorrow just to compose impressive verses) – captures precisely the temptation we faced. The saying describes someone manufacturing emotions they do not genuinely feel simply to create poetry that appears sophisticated. We realized that adopting commercial AI APIs merely to demonstrate technical impressiveness would be exactly this: adding complexity we do not need to appear cutting-edge, forcing sophistication onto our work for the sake of appearances rather than pedagogical purpose. We came to recognize that our contribution is not primarily about building the most technically impressive system. It is about demonstrating that teachers can build pedagogically effective educational AI while making responsible environmental choices. The value of our work lies precisely in showing that “powerful enough” technology, thoughtfully implemented, can serve educational goals sustainably. This realization connected to broader questions about the direction of educational AI development. The current trajectory, driven largely by commercial companies and their imperatives for competitive advantage, prioritizes ever-larger models, ever-more-sophisticated capabilities, and ever-increasing computational resources. This trajectory is neither inevitable nor necessarily beneficial. If teachers, researchers, and educational institutions simply accept it, if we adopt whatever technology companies offer without questioning the environmental costs, we cede our agency in shaping how AI develops and how it serves education. As scholars, teachers, and now AI developers, we recognize that we have a responsibility to articulate an alternative vision. Not everyone must follow this path, but there is space for people like us to have a say in the direction of educational AI development, to practice and demonstrate how sustainability can be emphasized in the development process, and to prove that pedagogical effectiveness and environmental responsibility are not necessarily in conflict.

This stance requires us to reframe success. We stopped measuring our system primarily against the technical capabilities of commercial alternatives. Instead, we asked different questions: Does our system achieve its pedagogical objectives? Do nursing students develop communication competence through practice with our simulated patients? Can the system be maintained and scaled without unsustainable resource consumption? Do we model for students and colleagues that environmental responsibility matters in educational technology choices?

This philosophical stance had practical implications for how we engaged with critiques and comparisons. When colleagues or reviewers noted that commercial API-based systems could generate more sophisticated dialogue, we learned to respond not defensively but with clarity about our design principles. Yes, GPT-4 is more capable than our Transformer.js implementation. But our system meets our pedagogical needs while consuming a fraction of the energy and generating a fraction of the CO2 emissions. That trade-off represents an intentional choice, not a technical limitation we would overcome given sufficient resources.

We also found it important to frame our sustainability commitments not as sacrifice but as responsibility. We are not giving up impressive capabilities for environmental principles; we are taking seriously our role as educators in modeling responsible technology use. Every tool we build teaches a hidden curriculum, not just about nurse–patient communication but about what we value in technology: extraction or stewardship, convenience or care, spectacle or sustainability. Just as we teach students to evaluate sources critically, to question assumptions, and to consider the broader implications of their actions, we model for students and colleagues that technology choices have consequences beyond immediate functionality. The environmental footprint of our tools matters. The energy consumption of our infrastructure matters. These concerns do not compete with educational quality because they constitute part of what educational quality means in an era of climate crisis.

This does not mean teachers should never use commercial AI services. There may be applications where the sophistication of large models genuinely enhances learning in ways that justify environmental costs. But it does mean that educational AI development should involve conscious choice about when such resources are truly necessary, rather than automatic adoption of whatever is newest or most powerful. It means building literacy about the environmental implications of different technical architectures. It means valuing “powerful enough” solutions that achieve pedagogical goals sustainably.

As we reflect on our development journey, we recognize that sustainability shaped not only what we built but who we became as teacher-developers. The constraints forced creativity. The learning reduced dependency. The ethical commitments enriched purpose. We did not build the most technically sophisticated nursing ADS possible. We built a system that works, that serves our students effectively, that we can maintain and improve ourselves, and that embodies our values about education and environmental responsibility. That accomplishment, we believe, represents genuine innovation not in technical sophistication but in demonstrating sustainable pathways for teachers to reclaim agency in educational AI development.

6.1 Positionality, Shared Struggle, and Honest Reckoning

This Element is not a prescription from those who have succeeded to those who should follow. We write as academics who feel the weight of contemporary academic life: the pressure to publish, to secure funding, to meet institutional KPIs. These pressures erode agency for university-based educators, just as commercial AI pressures erode agency for school teachers. The forms differ, but the underlying dynamic is similar: external demands displacing intrinsic purposes, metrics substituting for meaning, performance replacing genuine engagement with our work. Our project began not as a research output to satisfy metrics but as an attempt to do something that felt meaningful on our own terms. We wanted to take the initiative rather than being pushed. The nursing ADS we built emerged from this desire: not primarily from a gap in the research literature or an opportunity for publication, though it became both of those things. It emerged from wanting to reclaim some portion of our professional lives for work that feels genuinely purposeful.

In this sense, we are not here to help teachers regain agency; we are doing it ourselves and sharing that process. The distinction matters. We are not dispensing advice from a position of achieved mastery. We are fellow travelers on a journey that remains incomplete, sharing what we have learned so far while acknowledging how much we have yet to understand. When we describe barriers and how we navigated them, we speak from recent experience of those barriers, not from distant recollection. The frustrations we describe were genuinely frustrating. The doubts were real doubts. The moments of wanting to abandon the project and leave it to “real” developers – those moments happened. This positionality shapes everything that follows. We are not claiming that our pathway is optimal or that our technical solutions are elegant. We are claiming that we, as scholars trained in linguistics and semiotics, not computer science managed to build a working educational AI system that serves our pedagogical purposes. If we can do that, then perhaps the barriers are lower than they appear. Perhaps other educators, with different backgrounds and different purposes, can also find their own pathways. That possibility is what we hope to open.

Intellectual honesty requires that we name the conditions that made our specific pathway possible. We hold postdoctoral and professorial positions at a research university in Hong Kong, a knowledge production hub with substantial research infrastructure. Our principal investigator is willing to grant intellectual freedom and embrace our sustainability initiative rather than directing us toward more conventional research outputs. We have research funding that allowed time for learning and experimentation, time that many educators simply do not have. These conditions enabled this particular form of agency reclamation. We state this not to discourage educators in different circumstances but to resist the false suggestion that our experience is simply transferable. It is not. A primary school teacher in an under-resourced school, already working sixty-hour weeks, cannot realistically undertake the kind of extended learning journey we describe. A university lecturer on a teaching-only contract, measured entirely by student evaluations and course completion rates, faces different constraints than we did. An educator in a context where AI tools are mandated from above, with no room for local innovation, operates under different conditions entirely. What we can say is this: Our conditions were not extraordinary. Many educators have some degree of the resources we had, such as some time for professional development, some institutional tolerance for experimentation, some access to the free tools and communities we utilized. The question is whether those resources, however modest, might be directed toward opening cracks rather than merely responding to external demands. Different educators in different conditions will find different cracks, different ways of bringing light in. Our pathway is one possibility, not the possibility.

The time pressures we face are not unique to us as they are structural features of contemporary education at all levels. School teachers face marking, planning, meetings, pastoral care, administrative duties, and the emotional labor of supporting students through difficulties that extend far beyond the curriculum. University educators face teaching loads, publication pressures, grant applications, committee work, and the increasing expectation that they will be available to students at all hours. The feeling that one is always responding to external demands rather than pursuing intrinsic purposes. We emphasize this shared burden because we want to be clear about what we are not suggesting. We are not adding “one more thing” to an already overwhelming load. We are not proposing that teachers should learn to code in their nonexistent spare time. We are not romanticizing technical work as inherently liberating while ignoring the very real constraints that make such work difficult or impossible for many educators. What we are sharing is one way we found to reclaim space within that load: to do work that felt like ours. For us, that meant building an educational AI system. For other educators, it might mean something entirely different: developing new pedagogical approaches, engaging in collective advocacy, pursuing critical evaluation of existing tools, or simply refusing to adopt technologies that do not serve their students. The common thread is not AI development but the decision to take the initiative rather than merely respond and to shape one’s relationship with technology rather than being shaped by it.

6.2 Dealing with Self-Doubt and Agency

Throughout this journey, we encountered advice from people who appeared more technically knowledgeable than us. Colleagues suggested different system architectures. Reviewers proposed more advanced technologies. Online commenters recommended alternative approaches. Some readers of this Element may be thinking the same: “I could do this better than the authors.” Of course, that may well be true. There are always smarter people, more elegant solutions, more sophisticated technologies. But here is what we learned: Blindly following advice from those who appear more expert does not necessarily make the work easier or better. In fact, it can undermine the very agency you are trying to build. When we defer completely to technical suggestions we do not understand, we lose the thread of our own pedagogical purposes. We end up with code we cannot maintain, decisions we cannot justify. This is not an argument against taking advice; we learned enormously from others throughout this project. It is an argument for taking advice from a position of agency. We needed to know our pedagogical goals clearly enough to evaluate whether a suggestion served them. We needed to understand enough technically to assess whether an alternative approach was genuinely better for our purposes or simply more impressive. And we needed to be willing to say: “That may be a more sophisticated solution, but I do not understand it well enough to maintain it, and my current approach serves my students adequately.”

Agency in learning means: “I take your advice seriously, I will try to understand it, and I will decide whether it serves my pedagogical purposes rather than assuming you must be right because you know more than I do.” This requires developing enough literacy to evaluate advice, which is precisely what we described in earlier sections as “just enough” technical knowledge. You do not need to know as much as the advisor to assess whether their advice fits your situation. You need to know your situation well enough, and understand the advice well enough, to make an informed decision about fit. This stance can feel uncomfortable sometimes, even presumptuous. Who are we, with our limited technical knowledge, to question advice from those with vastly more expertise? But the alternative is worse: building systems we do not understand to solve problems we do not have, pursuing sophistication for its own sake, recreating dependency under the guise of collaboration. Teacher-led development requires teachers to lead, which means teachers must ultimately decide what serves their students, even when that means respectfully declining expert suggestions.

6.3 Returning to Yang: Agency, Identity, and Multiple Pathways

Let us return to Yang, the teacher we introduced at the beginning of this Element. In 2023, Yang found himself feeling that his expertise had been devalued, positioned as a consumer of AI technology rather than an agent who could shape it. The question we must now address is not whether Yang should become an AI developer. The question is: How might Yang reclaim professional agency in an AI-influenced landscape? And crucially: What would it mean for Yang to take the initiative rather than being pushed? To understand Yang’s predicament theoretically, we draw on Bakhtin’s concept of dialogism: Meaning and identity emerge through responsive interaction, not isolated action (Bakhtin, Reference Bakhtin, Emerson and Holquist1981). Yang’s agency is not something he possesses individually but something constituted through his relationships, with students, colleagues, technologies, and institutions. His professional identity as a teacher is not a fixed property but an ongoing achievement, continually negotiated through these relationships. When AI enters his classroom uninvited through his students’ use of ChatGPT, it disrupts the network of relations through which his identity has been constituted.

We also draw on Latour’s actor-network theory: Agency is distributed across human and nonhuman actors (Latour, Reference Latour2005). Yang’s relationship with AI is not simply that of user and tool but a network of mutual shaping. The AI shapes what is possible in Yang’s classroom, but Yang’s responses also shape how AI functions in that context, what tasks it is assigned, how its outputs are evaluated, what role it plays in student learning. The implication is that reclaiming agency does not require mastering technology but requires repositioning oneself within the network of relations (Law, Reference Law1992). Yang need not become a programmer to become an agent. He needs to shift from being shaped by AI to actively shaping his relationship with it. This theoretical framing opens space for multiple pathways to agency. Becoming an educational AI developer, as we have described, is one viable pathway but not the only one. Consider several directions Yang might pursue:

Yang might pursue critical evaluation and informed refusal. He develops enough AI literacy to evaluate tools critically and advocate for rejection of those that do not serve his students. He learns to ask penetrating questions: What data was this system trained on? What values are embedded in its design? What does it optimize for, and at what cost? He becomes the colleague others consult when considering new AI tools, not because he can build them but because he can assess them. This is agency through informed resistance and the capacity to say no from a position of understanding rather than fear.

Alternatively, Yang might pursue pedagogical adaptation and creative repurposing. He does not build AI tools but develops pedagogical strategies that redirect AI use toward his educational goals. He becomes expert at prompt design, at structuring assignments that use AI productively rather than as a shortcut, at teaching students to be critical AI users who can evaluate and improve upon AI-generated content. He transforms the threat of AI-enabled cheating into an opportunity for teaching critical literacy. This is agency through pedagogical innovation, using educator expertise to shape how technology functions in learning contexts.

Or Yang might pursue AI development as we have described throughout this Element. He learns to work with AI coding assistants to build tools serving his specific pedagogical vision, perhaps a system that helps students practice English conversation with culturally appropriate feedback, or a tool that analyzes student writing to identify patterns he can address in instruction. This is agency through technical creation, developing the capacity to build rather than only use educational technology.

Most realistically, Yang would pursue some hybrid path, combining elements of these approaches based on his interests, constraints, and context. Perhaps he develops critical evaluation skills that inform selective development, building some tools while advocating against others. Perhaps he combines pedagogical innovation with collective advocacy, developing classroom strategies while also working to change institutional policies. The pathways are not mutually exclusive; they can reinforce each other.

The point is that there is no single “correct” response to AI’s presence in education. Different teachers will find agency through different means, based on their interests, constraints, and contexts. A teacher with programming experience might naturally gravitate toward development. A teacher with strong writing skills might contribute through professional publications and policy advocacy. A teacher with deep pedagogical expertise might focus on instructional strategies that redirect AI use. All of these represent legitimate forms of agency.

What unites these pathways is more important than what distinguishes them. All require moving beyond passive consumption of whatever technology arrives, which is the stance of accepting tools provided by others without questioning whether they serve one’s purposes. All require some degree of demystification to understand enough about AI and to make informed choices rather than being paralyzed by the technical mystique. All position teachers as agents who shape their relationship with AI rather than being shaped by it. All involve what Bakhtin might call “answerability” – taking responsibility for one’s response to the situation rather than simply reacting to external pressures. And all represent taking the initiative rather than being pushed.

Yang’s choice among these pathways should be genuine, not forced by barriers that could be lowered. Those who wish to develop educational AI should find the path navigable, which is why we have written this Element. Those who wish to pursue other forms of agency should not be made to feel inadequate for choosing differently. What matters is that the technical mystique no longer forecloses possibilities, that teachers understand they have options, and that they can pursue whichever options align with their purposes and circumstances.

6.4 Toward Collective Dialogue: Bridging Communities

A problematic separation exists between technology communities and educator communities. Technologists often build educational tools without deep understanding of pedagogical knowledge, such as what makes learning happen, how students actually engage with content, and what teachers need to do their work effectively. Educators often adopt or reject technologies without understanding technical possibilities and constraints, such as what AI can and cannot do, why certain features are difficult to implement, and what trade-offs different architectural choices involve. Each community has developed caricatured views of the other: Technologists sometimes see educators as resistant to innovation and wedded to outdated practices; educators sometimes see technologists as naive about classroom realities and driven by profit rather than learning. This divide serves neither students nor the goal of meaningful educational technology.

Yet people on both sides want connection; they simply do not know how to achieve it. In technology communities, many developers genuinely care about education and are frustrated by building tools that miss the pedagogical mark. They want educator input but do not know how to access it authentically as the focus groups and user testing sessions they conduct often feel superficial, capturing surface preferences rather than deep pedagogical insight. They see educational products driven by metrics and marketability rather than learning outcomes, and they wish it were otherwise. In educator communities, many teachers are exhausted by being told what to use without being consulted, to always having tools imposed from above that do not fit their teaching contexts and create more work rather than less. They have ideas for tools that would actually help but no pathway to realize them, no way to communicate their vision to those who might build it. They want partnership, not product placement.

Genuine dialogic exchange would look different from current patterns. Not technologists building for educators, treating them as dumb end users whose preferences must be satisfied in the so-called easiest possible ways with preferably no learning curves. Not educators consuming from technologists, choosing among options that others have defined and requiring their compliance. But genuine dialogue where both communities learn from each other and create together. Educators would contribute pedagogical vision, like what learning should look like, what students need, what classroom realities must be accommodated. They contribute contextual knowledge such as how their specific students learn, what their institutional constraints are, what cultural factors matter. Technologists would contribute technical possibilities – things like what current AI can do, what emerging capabilities might enable, and what architectural approaches might work. They together would contribute constraint knowledge, such as why certain features are difficult, what trade-offs different choices involve, and what resources different approaches require. Most importantly, shared language would develop through collaboration, not be imposed by either side. Currently, technologists and educators often talk past each other because they use the same words to mean different things or different words to mean the same things. “Learning” means something different to an educator steeped in constructivist theory than to a machine learning engineer. “Model” means something different in pedagogical contexts than in AI contexts. Genuine dialogue would develop shared vocabulary through working together on concrete problems.

Drawing on Bakhtin again: Dialogue requires genuine others, not ventriloquism. When technologists claim to speak for educators based on user research, or when educators claim to understand technology based on using consumer products, both are engaging in a form of ventriloquism, which is putting words in the other’s mouth rather than genuinely listening. Authentic dialogue requires each party to encounter the other as genuinely other, with different knowledge, different values, different ways of seeing the problem. This encounter is uncomfortable as it requires acknowledging the limits of one’s own perspective, but it is the only path to solutions that genuinely serve both pedagogical and technical goals.

Practical spaces for this dialogue already exist and could be expanded. Open-source communities offer one venue where educators and developers can collaborate on shared projects. Professional development programs can be redesigned to bring both communities together rather than training each in isolation, such as workshops where educators and technologists jointly design educational tools, each contributing their expertise to the process. Research partnerships can be structured as genuine collaboration rather than extraction, not researchers studying teachers as subjects but researchers and teachers working together as co-investigators with different but complementary knowledge.

Policy conversations must also include both technical and pedagogical voices. Bringing educators and technologists together in policy discussions could produce more informed decisions about technology adoption, data privacy, and resource allocation. Teacher-developer communities, like the one we are trying to model in this Element, represent one bridge between these worlds, but they are not the only bridge, and they should not be expected to bear the entire weight of connection.

Schools and universities must create institutional conditions that support dialogue rather than just technology adoption. This means allocating time for teachers to engage with technical communities, not as an add-on to already overwhelming schedules but as a recognized part of professional work. It means providing recognition for collaborative innovation such as valuing the teacher who co-develops an educational tool as much as the teacher who publishes a paper or raises test scores. It means creating funding streams that support partnership rather than just purchasing. And it means developing policy frameworks that require educator voice in AI decisions, mandating teacher input in technology adoption processes rather than allowing administrators to make these choices unilaterally.

The larger stakes of this dialogue are significant. Who shapes educational AI matters, not just for teachers and students but for the future of education itself. Currently, commercial imperatives dominate the field, and understanding the specific challenges of commercial platforms helps clarify what alternatives might offer.

6.5 Commercial Platforms and Teacher Agency: A Critical Examination

Low-threshold commercial AI platforms – what we refer to as commercial educational AI products that aim to make their applications “easier” for teachers – are, we argue, creating new dependencies that ultimately constrain teacher agency. Commercial platforms’ appeal is understandable. They require minimal or no technical knowledge, provide customer support, and offer professional legitimacy. For administrators, they provide contracts and accountability. For time-pressed teachers, they promise immediate solutions to pressing problems.

Yet three critical tensions are likely to emerge. First, erosion of pedagogical specificity: Platforms optimize for broad markets, not specific contexts. For example, a tool designed for generic learners cannot address Hong Kong students’ transition from Cantonese to English-medium instruction with their particular linguistic needs. As teachers begin to rely on these platforms, they have fewer opportunities to develop solutions tailored to their specific pedagogical contexts. At a higher level, when schools adopt identical platforms, teaching converges around platform affordances. Diverse pedagogical approaches, characterized by teachers’ varied backgrounds and students’ specific needs and personal and cultural backgrounds, give way to platform-determined patterns, which we see as marked by a loss of meaningful pedagogical opportunities. In addition, teacher education emphasizes TPCK (technological pedagogical content knowledge) as integrating content knowledge, pedagogical expertise, and technological understanding. Commercial platforms positioned as “teacher-proof” bypass TPCK development. Teachers aren’t asked to reason through how tools can be designed differently to serve diverse learning needs; they’re encouraged to trust that platform designers have already done that thinking. This shifts teachers from professional decision-makers to implementation technicians, fundamentally altering their professional identity.

In what we propose as teacher-led communities of practice, knowledge flows horizontally: Teachers talk with teachers, sharing practical wisdom and contextual adaptations. Early-career teachers facing institutional precarity can learn from mid-career teachers who have navigated similar challenges. This reciprocal exchange contrasts with university-led professional development positioning researchers as knowledge producers and teachers as recipients. Crucially, teacher-led COPs can develop an alternative infrastructure. When teachers collectively build and share tools and tips, they create ecosystems parallel to commercial offerings: for example, open-source educational AI, collaborative documentation of what works and what doesn’t. Technical knowledge distributes across communities; one teacher’s programming strength complements another’s prompt engineering expertise and another’s pedagogical depth.

This is not an argument against all commercial tools. Pragmatically, teachers must work within existing systems. The goal is strategic engagement informed by critical awareness. Teachers understanding AI principles while using commercial platforms can evaluate whether platforms truly serve their pedagogical goals, identify when custom-built tools will provide greater long-term value despite requiring added effort, and advocate in institutional technology decisions from an informed position.

Understanding these dynamics prepares us to examine the specific boundary conditions: the enabling and constraining factors that shape whether and how teachers can pursue alternative pathways.

6.6 Boundary Conditions: What Enables and Constrains Teacher-Led AI Development

The pathway to teacher-led AI development is shaped by specific enabling and constraining boundary conditions that operate at multiple levels (see Table 2).

Table 2Boundary conditions in teacher-led AI development

a

Table 2a Long description

The table consists of three columns: Boundary conditions, Enabling factors, and Constraining factors. It reads the following data. Row 1. Boundary conditions: Resource-related conditions. Enabling factors: Access to A I coding assistants (some free-tier options available), Open-source models, Browser-based development environments that eliminate expensive infrastructure requirements. Constraining factors: Limited institutional budgets for professional development, Lack of dedicated time for experimentation, Resource inequities between schools. Row 2. Boundary conditions: Policy and institutional context. Enabling factors: School leadership supports teacher innovation, Flexibility in curriculum implementation. Constraining factors: Rigid A I policies that mandate specific commercial platforms, Availability of certain technologies (as experienced in Hong Kong contexts), Neoliberal accountability measures that demand justification through excessive administrative labor. Row 3. Boundary conditions: Teacher status and positionality. Enabling factors: Senior teachers possess institutional authority to champion new approaches, Early-career teachers bring technological fluency and eagerness to experiment. Constraining factors: Senior teachers sometimes resist innovation (as Yang’s older colleagues demonstrated), Early-career teachers face precarity in their institutional positions, making them vulnerable when taking pedagogical risks, Teachers in probationary periods or temporary contracts may avoid A I development for fear of being seen as diverting effort from conventional responsibilities

b

Table 2b Long description

The continuation of the table consists of three columns: Boundary conditions, Enabling factors, and Constraining factors. It reads the following data. Row 1. Boundary conditions: Knowledge and capacity. Enabling factors: Teachers’ pedagogical content knowledge (P C K), Technological pedagogical content knowledge (T P C K), Multilingual repertoires for accessing global resources. Constraining factors: The technical mystique – the misconception that A I development requires unreachable expertise, Inadequate teacher education programs that fail to prepare educators for critical evaluation of commercial A I tools and platforms. Row 2. Boundary conditions: Community and support structures. Enabling factors: Peer support through teacher-teacher communities of practice (C O P), Shared problem-solving within teacher-teacher communities of practice (C O P), Validation that contrasts with top-down university-led initiatives. Constraining factors: Absence of such communities, Reliance solely on external experts, Constrains teachers capacity to develop sustained, context-appropriate innovations.

Consider a mid-career English teacher in a Hong Kong secondary school wanting to develop an AI chatbot for grammar practice. Enabling conditions might include: (1) availability of free AI coding assistants like Claude or ChatGPT; (2) school leadership that values teacher innovation; (3) participation in a teacher learning community that shares coding resources; and (4) strong TPCK from years of teaching experience (Mishra & Koehler, Reference Mishra and Koehler2006). On the other hand, constraining conditions might include: (1) lack of protected time; (2) school policy requiring all AI tools to go through lengthy approval processes; (3) emotional labor of justifying the project to skeptical administrators who prefer commercial solutions; (4) language barriers in accessing English-language technical documentation; and (5) precarity from being on a fixed-term contract, making risk-taking professionally dangerous. Understanding these boundary conditions helps us move beyond simplistic narratives of “teachers just need training” toward recognizing the complex ecology of entangled factors that can enable or constrain teacher-led AI development. Not all these conditions can be controlled by individual teachers, which is why we emphasize building communities of practice and advocating for institutional support structures that expand enabling conditions and mitigate constraining ones.

6.7 An Invitation to Continuing the Dialogue and Journey

We return, in closing, to what this Element has tried to offer: not a manual but a provocation. A story of opening one crack with honest acknowledgment of its limitations and conditions. An argument that multiple pathways to agency deserve exploration and that no single pathway is right for all teachers. A call for dialogue between communities that have too often talked past each other, to the detriment of students and educators alike.

To educators considering this or other pathways to agency: You are not alone in feeling that something has been lost and wanting to reclaim it. The erosion of professional meaning, the displacement of intrinsic purposes by external demands, the sense that your expertise is being devalued by technologies you did not choose and do not control – these experiences are widespread. They are not signs of your inadequacy but symptoms of structural conditions that affect educators across contexts. Taking the initiative to address them, whatever form that initiative takes, is not self-indulgence but professional responsibility.

To technologists seeking genuine educational partnership: Educators are ready for dialogue. Many teachers are eager to contribute their pedagogical knowledge to technology development; they simply need pathways for doing so that respect their expertise and accommodate their constraints. Creating those pathways is partly your responsibility. It means going beyond focus groups and user testing to genuine collaboration. It means treating educators as co-designers rather than end users. It means being willing to have your assumptions challenged by people who know things you do not know.

To institutions, schools, universities, education systems: Create conditions for agency, not just adoption. Teachers cannot take the initiative if their time is consumed entirely by external demands. They cannot develop technical literacy if professional development focuses only on using predetermined tools. They cannot contribute to shaping educational AI if their voices are excluded from technology decisions. The structural conditions that erode teacher agency are not inevitable; they are choices that institutions make and can unmake.

We close with a final, smaller invitation. Return to the very small: the PowerPoint that will not go full screen, the projector that will not connect. Consider the assumption that pervades many classrooms and conferences we have been to: that technology is naturally young people’s domain, that students possess innate “tricks” that teachers lack. When teachers routinely ask students to handle these moments, something subtle but consequential happens. Technical capability becomes reframed as generational property rather than learnable skill. Each small delegation reinforces the narrative that “this is not for me.” We are not suggesting teachers must never ask for help since asking for help is reasonable and often efficient. But we are suggesting that the pattern of routinely outsourcing even trivial technical tasks to students participates in constructing the very mystique that excludes teachers from larger technological agency. The accumulated weight of these small surrenders shapes professional identity over time, reinforcing the sense that technology belongs to others.

Perhaps before building an AI system, a teacher might simply decide to learn how to put their own PowerPoint in full screen. Not because it is difficult, but precisely because it is not. And because reclaiming agency sometimes begins with the smallest refusal to cede it.