Richer forms of interaction

If you’ve ever tried to draft a document with an agent, you would have felt the friction inherent in trying to comment on the agent’s proposal or reply. This is an old, old problem, and humans simply worked with its limitations. With the advent of HTML and internet forums, we developed some conventions for quoting chunks of a reply and adding our own response. And with the advent of collaborative document editing, such as through Google Docs, we developed other conventions, such as highlighting lines and adding comments.

Attempting these newer interaction protocols with existing agents, however, is a shot in the dark. Most agent harnesses don’t support this, and you would have to find an online platform that does (and hope it survives long enough), or find an MCP server or tool that does.

The shape of human-agent interaction

And suppose you do find this tool. In all likelihood, it gives your agent tools for:

• reading the document, or chunks of it
• editing the document, by adding content at the end, or with find-and-replace semantics
• annotating the document

The agent makes a change, the agent reads the document and verifies the change. Sometimes the agent attempts to edit—but oops, someone made a change in the meantime, so their find-and-replace didn’t work. Sometimes a new document was created; the agent won’t know unless someone tells it, or it happens to make a tool call for listing documents and discovers it.

This is the default state of most workplaces, so it is no surprise that it also ends up looking like the default starting state of human-agent collaboration.

But we can definitely do better.

Joint cognition

While the term joint cognition has picked up different meanings depending on who you read, here I’m looking at a few key features:

State transparency

All users working on a file/document/project see its latest state at all times. Changes do not happen silently when other users are viewing.

As much information is captured in the system as possible, instead of remaining in private agent or human memory.

Simultaneous thinking

The default request-response loop forces cognition to alternate between human and agent. First the human thinks and the agent waits, then the agent thinks and the human waits. To enable richer forms of interaction and assistance, like we are already seeing with code assistants and autocomplete systems, we need to enable humans and agents to think together.

In its simplest form, this looks like interleaved thinking: the human’s actions are streamed to the agent as text/audio/video chunks, enabling it to recognize appropriate moments to respond, while the agent’s response is likewise streamed, allowing the human to interrupt mid-thought or provide additional information/context or add another request without waiting for the agent to finish its response.

We can go yet further: after the agent writes its proposal document, can a human read and annotate as an agent spectates, providing specific clarifications or misunderstandings while aware that more comments are forthcoming? Can the agent highlight relevant parts of the document as the human is reading and typing?

Shared environment

A human working in their own terminal, and the agent working in theirs, diverge very quickly: the human has a variable in their environment that’s not in the agent’s, and vice-versa. The tools of software engineering help to make environments more repeatable and representable, but do not solve the problem.

If you are a vibecoder or use agent-assisted coding in your own projects, think about the last time you actually knew what was going on in the agent’s shell. Could you tell why certain commands that worked on your terminal failed in theirs? And suppose you did know why: were you able to “reach in” to their terminal and resolve the problem for the agent before it continued? Or did you have to “tell it” (by sending a request) and hope it understood how to resolve the issue itself?

Joint control

A shared environment enables both human and agent to inspect the same entity, to literally be on the same page. This is technically difficult, because most computer and software systems are not engineered for simultaneous broadcast: for two entities to see the same state of a third entity at all times, all changes by one must be broadcast to the others. This is a well known messaging problem that has its own name: the publish-subscribe pattern. Designing this for humans and agents within a system requires some engineering work that most harnesses do not yet provide.

Agent limitations

We have some of these tools for collaboration between humans. But these don’t quite work for agents, because the shape of agent cognition is different.

Most agents generate a continuous token stream, terminating only when they encounter a stop token. Tool calls and their results accumulate, previous thinking tokens remain, and eventually the agent hits a context length limit.

Many agent harnesses are gradually developing context compression mechanisms, ranging from a crude /compact command, to recency/relevance mechanisms that discard old tool call results or file reads, to progressive compression. Even with these improvements, it is obvious that agents don’t “see” or “act” like us. We edit a document by placing a cursor and typing text; agents currently use find-and-replace or rewrite semantics. Adding a single word is easy for us, less easy for an agent. Seeing the latest version of a document, or knowing when it changed, is easy for us (if the text editor supports real-time updates), near-impossible for an agent. If you modified a file after an agent touched it, it would have no knowledge until its next file edit attempt fails and it guesses at what happened.

Open research questions

1. What kind of design would enable an agent to see the same context as humans?
2. How do we design toolsets that are low-friction for an agent, yet easy for humans to understand how they are used?
3. What kind of control and handover protocols will we need to enable control of context to pass between agents and humans as required?

The difference is we can run agents through evaluation tests (evals). We can inspect their training data. And we can design personal information systems to record a trace of agent actions, not primarily to hold them to task, but to enable them (and humans) to audit their thought stream against the tool calls and decisions they made.

This is already happening; it is how agents deployed in companies are trained. But I’m more concerned about personal information systems, which are less about accountability and more about orientation. We need some terms for thinking about what guides agent thought and behavior.

My understanding of agents

Here’s my current understanding of agents, from background reading and personal use (See my Layman’s Guide to Computing newsletter, Season 14 for a crash course):

• agents are models wrapped in a runtime.
• the model is a next-token predictor that generates thoughts (raw token stream) and actions (tokens formatted as an action, e.g. ReadFile(README.html))
• the runtime intercepts the token stream, separating and executing actions (beyond the model’s control), displaying results to the user, and passing user input back to the model
• models are trained on data: unsupervised training on unlabelled data gives it general knowledge, supervised training on labelled data makes the model more reliable at following instructions, using tools, thinking, and planning.
• models are invoked with an initial set of tokens, called the prompt. These typically give it an identity, guiding instructions, and scope its behavioral boundaries
• models can learn from examples given in the prompt, and the user’s initial input is typically tacked on after the built-in prompt (known as the system prompt)
• while the model can follow instructions in the prompt pretty well, as the context grows longer, contradictory or ambiguous context may confuse it, or its post-trained tendencies may end up overriding its instructions
• as a result, models can get stuck in loops, go against instructions, do something the user did not specify in sufficient detail in a way they do not expect, etc.

An ontology for agent belief

“What’s a belief? What do beliefs do? What’s the difference between a belief and a claim? What’s the relationship between a belief and a fact?” Start to ask too many of these questions and you find yourself thinking about or building an ontology.

So that’s where I’m at today. While the terms below have everyday definitions, in the context of a personal information system they take on more specific, scoped, consistent meanings. To make this distinction more noticeable, I’ll format such terms in monospace, like this.

First, we have facts: events recorded in the personal information system. When a message was sent, by who, referencing what. When a document was created or edited. When an AI agent took an action, and in response to what. These events, once written, are not meant to be easily modified; they serve as a written record of what happened, made fact.

To an agent, which has no senses and cannot immediately verify the contents of its context, the tokens there are effectively claims. Claims are free-form text or information, which may or may not be linked to underlying facts. We use the term “claims” here rather than “beliefs”, so that the semantics make it clear that the agent does not necessarily act on this information—but it may!

There are many ways we could redefine “belief”, but we’ll try to keep close to our intuitive understanding of it: a belief is a statement like “agent D believes it should obey all instructions from humans”, conceived by humans. These statements are typically based on observed behavior over a period of time.

In this ontology, agents do not have beliefs. They have priors, a term we borrow from Bayesian probability, describing the agent’s tendencies in token generation. These priors come from the weights of its underlying model: the gigantic set of numbers that represent its encoded patterns. We can probe agent priors by passing incomplete statements like “messages are stored in _____” to the agent’s model and seeing how it completes the sentence.

While priors describe the agent’s knowledge, grain describes the agent’s behavioral tendencies: the tool calls it makes in response to situations, the specific triggers that cause it to make them, and also situations when it does not use them. “Grain”, analogous to “grain of the wood”—wood is easy to split along its grain, not against. Likewise, working against an agent’s grain“—by asking it to use tools in a way that runs counter to what its priors will generate—is much more difficult than working “along its grain“—giving it a higher-level goal, and letting it use tool calls following its priors. We can only do this with agents that are trained to use tools in a way that aligns with our goals—it is in the correct orientation.

The customary way of doing this is is called post-training or fine-tuning: using supervised learning on labelled data. The data is labelled as input:output pairs, with the input being passed the the model, and its output checked against the labelled output. The model’s weights are adjusted until it gives the correct output. This is a computationally heavy process, usually not carried out on user devices; but it may become feasible in future, or available through APIs such as Thinking Machines Lab’s Tinker.

In a personal information system, the agent’s knowledge is easier to update or correct through tool calls that let it query the information system or read from files. The purpose of most fine-tuning will be to re-orient the agent’s grain, to have it use tools correctly and in the correct context. The labelled data will likely take the format “<context>:<action>”. To distinguish this from the generic term of “training data”, we call such context:action data pairs lessons.

Open research questions

1. Who selects and triages the lessons that the agent learns?
2. How do we strike a balance between the heavy computational resources needed for full grain re-orientation (e.g. 100% accuracy on tool calls), and the adaptability the agent might need (e.g. as the user’s situation changes, the agent might need to use different tools in similar context)
3. What is a feasible, cost-effective way to re-orient agents using fine-tuning?

Measuring Learning Outcomes

What we were doing is measuring learning outcomes: did the students produce code that demonstrated their understanding of OOP? This is a common approach in education: we set learning objectives, then assess whether students meet them through tests, assignments, or projects.

But if we want to intervene earlier, we cannot wait until the end of a topic to see if students have mastered the material. By then, misconceptions may have taken root, and remediation becomes more difficult.

When driving a car, we don’t wait for the half-yearly inspection to find out if the engine oil is too low, the tyres are worn or deflated, or the wiper fluid needs topping up. We have ways to check them regularly: we glance at the dashboard displays, make a quick visit to the tyre air point at the petrol station, and top up fluids as needed.

Likewise, we don’t want to wait until the end of a programming course to find out if students are struggling with key concepts. We need ongoing, formative assessments that provide feedback during the learning process.

In software, this real-time monitoring is called “telemetry” — the dashboard that tells you oil pressure and engine temperature as you drive. Unlike analytics, which looks at aggregated data after the fact, telemetry is about live, granular signals that let you notice and fix problems while they’re happening. What if we could bring that same capability to the classroom?

Measuring Learning Outcomes (but more frequently)

This idea of “measure as you teach” is formally termed assessment for learning (AfL). This is familiar ground for tech practitioners: metrics are already widely used in software development to monitor application performance and user behavior. They might find it surprising that education hasn’t widely adopted this approach. But keep in mind that we don’t attach sensors and monitors to students the way we do to software systems. In the classroom, we rely on more subtle cues: student questions, body language, engagement levels, and formative assessments.

Unfortunately, class sizes and time constraints often limit our ability to monitor all signals and provide individualized feedback.

Measuring the Learning Process: is it possible?

What if we could “take a dipstick reading” of the learning process instead of waiting to quiz students? In a traditional classroom, we can use techniques like think-pair-share, quick polls, or exit tickets to gauge understanding during the lesson. But in programming lessons, when students are working on coding exercises, that would be disruptive.

In Singapore junior colleges, we teach introductory Python through coding exercises on online autograded platforms or interactive Jupyter notebooks. These platforms contain coding exercises interspersed with explanations and examples. Students read brief explanations, run code, modify them, and see the results immediately.

All this runs in the browser, with no installation required. The browser can also capture a second stream of data: how students interact with the exercises — the code they run, how many attempts they make, and how long they spend on each exercise. Can we use this data to better detect when students are struggling?

Ethics: Consent and Privacy

Before implementing telemetry in educational settings, we must consider ethical implications. Students should be informed about what data is being collected, how it will be used, and who will have access to it. Consent is crucial. In the early stages, we can make telemetry optional, allowing students to opt-in. As we demonstrate the benefits of telemetry for learning support, more students may choose to participate.

For learning purposes we don’t actually need to store detailed telemetry data long-term. Real-time monitoring can be done in-memory, with only summary statistics stored for analysis. This minimizes privacy risks while still providing valuable insights into the learning process. Since students are not graded on this data, it also does not need to be preserved or archived, reducing concerns about data retention.

Extracting signals from noise

Detailed telemetry data can be overwhelming. We need to identify key signals that indicate when a student is struggling. For example, if a student repeatedly runs the same code cell without making changes, it may suggest confusion. If they spend an unusually long time on a particular exercise, it could indicate difficulty.

It will take time and experimentation to identify the most useful signals. We can start with simple heuristics and refine them based on feedback from instructors and students. While many EdTech practitioners might immediately see this as a machine learning problem, a simpler rule-based system would be more appropriate initially and easier to implement. It might even allow client-side processing in the browser, further reducing privacy concerns.

Conclusion

This is an early peek at how we might measure the learning process in programming education, without waiting for end-of-topic assessments or tests. Improving our teaching tools begins with the data and ends with better support for teachers and learners.

Learning analytics typically looks at aggregate, retrospective data. Learning telemetry offers a complementary approach: granular, real-time signals during the learning process itself.

This isn’t speculative: browsers already capture these signals today on webpages. We can use this data to provide real-time feedback to instructors, instead of only waiting for consolidation to happen.

Something unexpected that I really like about this system is that it’s always “correct”. If I record something somewhere else (such as on a piece of paper) and move it into my system a day later, I can still put it in the correct day, if that’s how I have things grouped. In a similar system using my phone’s Notes app, the timestamps are automatic and unchangeable, so there’s a slightly different relationship I have with the timestamps and ordering of notes in this app. Apps with this automatic behavior are ever so slightly not my timestamps, and I relate to them accordingly.

In digital information systems, there is always a tension between canonical/”official” representations and user representations; we may receive an email on 5 Jan but understand that it was sent late and was meant for 3 Jan, or we may backdate documents as an understanding that an agreement finalized earlier is only ratified now.

User-first information systems

Before AI and agents, personal information systems largely focused on enabling user representations on a single-user system. This means the user has full control over the data schema, all data is mutable (may be modified at any point), and concern for legibility to other users is secondary at best.

Truth-first information systems

Enterprise information systems, having auditability as a primary concern, take a truth-first approach: information is recorded as it happens, with a canonical timestamp, and this information is stored read-only; no changes are possible without an audit trail.

Hybrid information systems

For an information system that must take into account the possiblity of agent interaction, we need both: user-first information systems are maximally user-friendly at the expense of legibility, which increases the risk of AI agents misunderstanding the user’s schema, particularly the parts that are most unconventional. Yet, fully truth-first information systems leave little room for schema customization, and are not ideal for personal information systems.

What if we separate both layers? We have a truth-first layer that records incontrovertible events: “this piece of information entered this system at this time from this source”. The truth-first layer makes investigation and conflict resolution possible, but is not what a user would reference on a daily basis. It reflects ground truth faithfully, providing it when it is needed.

A user-first layer is what a human user uses on a daily basis. We call it the belief layer: this is where a user forms, records, and updates their beliefs; they can link beliefs to the truth layer to provide themselves reassurance that their recorded information has provenance, if desired. This layer is mutable; the user can edit it as they please. For clarity, edits may also be recorded in the truth layer, leaving the user a history of edits. This can be used, programmatically or through AI agents, to perform undo operations or recreate an edit timeline.

Open research questions

• What goes in the truth layer? What goes in the belief layer?
• How does the required schema for each layer differ?

• 1940s–1960s: batch computing; computation as a service
• 1960s–1970s: multi-user interaction through time-shared terminals; computers as shared infrastructure
• 1970s–1980s: text-based personal computing; computer as an individual’s machine
• 1980s–2000s: graphical interfaces; personal computing through mass-distributed software
• 1990s–2000s: client-server networking; birth of network-based services
• 2000s–2010s: increasing network bandwidth and compute leads to web apps, software-as-a-service
• 2007–2020s: release of the iPhone; growth of cloud computing and platform ecosystems; subscription model increasingly common
• 2020s–: Growth of AI and agents; in current form, mostly requiring a cloud-based provider

Today, in 2026, our requests are largely served by code running on centralized platforms: cloud-based email, calendars, file storage, messaging. Our data lives in separate silos: Google/Apple, WhatsApp/Meta, Microsoft. They come together in our apps, appearing alongside each other if graced with the appropriate integrations by the developer and blessed by the correct authentication rituals. Still, they remain unable to interact or talk; my Google calendars still encounter difficulty syncing with my calendar app on a timely basis.

The personal computers in our pockets and on our laps belong to us, but computation and data does not.

Inspired by Alexander Obenauer’s Lab Notes format, I’m starting a series of notes collating my thinking on what I call “personal systems”: computer systems primarily designed for and operated by a single person, possibly alongside computer agents/assistants.

This page will be periodically updated with links to published notes. Notes on personal systems are labelled with a “PS” prefix and a three-digit identifier.

This page is PS000. An updated index of Personal Systems notes is provided here.

1. PS001: System Agents
2. PS002: Data Epistemics
3. PS003: Agent Beliefs

Claude Code doesn’t just generate code. It uses tools defined through the Model Context Protocol (MCP) to do everything from reading and editing files and running shell commands to accessing external services. It is able to “remember” how to do things, organizing them through skills and subagents. In the past few months, even non-programmers have begun using Claude Code to work on spreadsheets, access notes on their computer in discussions, organize things in their computer, search for information across GMail and Google Drive, even troubleshoot problems in their computer—while requests to Claude are sent to Anthropic’s servers, Claude Code itself is installed in and runs on the user’s own computer.

Agents as computer users

It is likely that many users will eventually accept, even desire, agents as users on their personal computers. How should we conceptualize and think about personal systems that not only accept them as bolt-on features, but are designed with them in mind?

While the idea of personal computing used to revolve around a single user, this doesn’t quite work when we add agents into the mix. Agents make their own decisions and carry out their own actions, which would be confusing if associated with the user instead of the agent.

Multi-user systems

It can be difficult to trace what an agent did through native computer tools. Claude Code runs as the logged-on user, and its actions are logged in the system as user actions. This is the case with most other coding agents as well. These software usually provide some tools to understand what the agent is doing, though it can be difficult to diagnose problems such as the agent trying but failing to edit a particular file.

This happens because the tools available to the agent and to the user are different. While a user may open the file in a text editor and use the cursor and keyboard to add the change, an agent might use a low-level text-based program to find-and-replace text strings, using commands like <...>. These two modes of editing can fail in different ways; the user doesn’t understand why the agent can’t make an edit that they can easily make, the agent might not understand that its command is failing because the user just added a change that caused the find-and-replace match to fail. The agent doesn’t see user actions until it checks, and the user might not see changes by the agent if the software does not provide those affordances.

We don’t have deep, technical studies into this area for personal computers yet; the personal computing pioneers generally assumed single-user systems. There is some research into assisting joint cognitive systems: systems that aim to create co-agency, enabling operators to see a common picture of what is going on in the system.

Agent-mediated automations

The traditional paradigm for modelling software actions are:

• Processes: each program running on the computer registers a process name with and receives a process ID from the operating system. This helps the operating system track resource allocation to processes: reserved memory, network sockets, open files, etc
• Services/Daemons: operating systems usually provide a registration system for long-running background programs to register as a service, which can be started on user login, and restarted upon failure
• Users: software is invoked by a system-created user. Specialized users are created for system processes, e.g. printing. File and resource access permissions are tagged to users; software invoked by a user inherits the user’s access permissions.

Advanced operators are beginning to automate some processes on their personal computers through agents. This is confusing to many operating systems and non-technical users. There is a distinct difference between “user X wishes to run program Y using the Y filename.txt command” and “agent Z wishes to run program Y using the Y filename.txt in response to user X’s message” which current software systems have not yet caught up to. Many agent programs simply run as user X.

This makes permission management and diagnostic investigation difficult, if not impossible.

Open research questions

• How might agents be modeled so that their actions are associated with them?
• How might agent actions be associated with an originating intent, e.g. a user request, programmed workflow, or scheduled task?

But that also means I’ll need to rebuild the little apps I’ve been relying on for the past decade: my budgeting app and todo app, among others. Before Claude Code, these felt like major projects that would take up most of my leisure time. Now, they’re a few vibecoding prompts away.

But, as a Computing teacher, I’m not fully comfortable vibecoding apps that I expect to be using for the next decade. I know too much about the things that can go wrong. If the early vibecoders are already posting on Twitter/𝕏 about how they got their API keys stolen, how their database information got leaked, how they got their entire project directory deleted in vibecoding mode, I don’t think I’m ready to let these tools run on their own.

So it’s time to learn and build something new with Claude Code.

Things I already knew

I teach Python and SQL in my day job, although I’m also somewhat familiar with syntax for Java, Javascript, PHP, and other common languages from various encounters. And from previous coding projects, I was already familiar with how project development, especially for a web app, might go:

1. You often write the code in multiple files.
2. You manage the packages you rely on (dependencies) with a package manager.
3. You write the code in an editor, likely a full integrated development environment (IDE).
4. You make code commits to a version control system (VCS). These days it’s git by default, and it serves as a code backup and a restore point if your code breaks.
5. When the code is done you might have a build step that produces the files you need from the code you wrote.
6. You deploy the files that run the actual app to a host.

Previously I would have to wade through multiple tutorials to understand each of these layers. Some tutorials are a buffet of tools, just telling you a bunch of commands to run. Others are beginner 101 tutorials that walk you through the absolute basics and then stop.

But it is 2026 now. You can just ask Claude Code.

Prerequisites

Product Requirements Document

Depending on the complexity of the project you are working on, you may need some additional steps before you ask Claude Code to “build the product please”. If like me you have specific preferences for technologies, you want to discuss the product with Claude Code first. I wanted mine small-scale, deployed through my preferred platform, using a mix of familiar and new technologies.

When you’re done, it is customary to ask Claude Code to “generate a PRD (product requirements document) with the details we have discussed so far”. Most coding agents have a tendency to forget what you asked them to do after one too many messages, so the PRD serves as their reference point for what they’re supposed to build. When you change your mind on things, remind Claude Code to update this PRD. Don’t be surprised if the PRD you get runs to a few thousand lines.

Implementation Plan

Each session in Claude Code has a context limit of 200,000 tokens (approx. 150,000 words), and some of this is reserved for system purposes. What you write, and what Claude Code does, goes into this context window. Once you hit somewhere above 80% of your limit, Anthropic compacts your context window, essentially summarising it with a customisable prompt that often loses fine nuance. Claude Code often feels somewhat lobotomised after a compaction, and general advice is to have each session do enough work that it stays under the context limit.

Given this limit of what can be effectively accomplished in each session, you’ll need to break down your huge PRD into work sessions. Practically, you won’t do it; you’ll ask Claude Code to. A PRD of a few thousand lines begins with a simple prompt, but your coding assistant will soon lose its way without a map. So you ask Claude Code to “generate an implementation plan for the PRD”.

Project Background

I was working on a mobile app to replace my current budgeting app, which I actually love. Unfortunately it is unable to talk to the boutique API I was creating. Fortunately, the app’s interface is simple enough that I believe I can recreate it with Claude Code’s help.

After some discussions with Claude (in the web interface), I got it to generate a PRD, which I copied to a file. Claude Code then generated an implementation plan for me; I specifically asked it not to generate the plan with too much detail; from previous projects I learnt it often needed to adjust things later.

I didn’t want to deal with the build process for an Android app yet—I knew it was lengthy and required the Android SDK. So I decided to test it as a webapp. Flutter was a good choice for this: I knew I would be able to write code once, generate a webapp, and later in the build process turn it into an Android app. The webapp would be simpler, have fewer features which I didn’t need anyway, and have the advantage of not needing an Android device or simulator for testing.

Learning Flutter with Claude Code

Project initialisation

So away with the first prompt:

how do I get a project initialised?

Claude Code helped me create the project directory, check for the necessary packages, advised me to install from the GitHub source instead of an Arch Linux package. I wanted to know: is this install user-specific or will it install for all users of my laptop? I would greatly prefer a local install:

is this a local install? would ~/.local be a better install location?

Claude Code unpacked the decisions involved for me and gave its recommendation: install to ~/.local.

A few more clarifications and requests later, I had it generate an install script, so that whenever I need to update flutter I could just run this script instead of having to ask for the commands again.

Then we got to flutter create, the setup tool that helps set up the necessary files and directory structure for a new Flutter project. More clarifications with Claude Code on the command syntax, and on dependency management. This saved me untold amounts of Googling, since I expected the documentation would be part of Claude Code’s training data.

It recommended common dependencies for working with SQLite databases, generating universally unique identifiers (UUIDs), and other project parts I knew I would need. Along the way we discussed various options: unique identification string or number for entities (Claude Code recommended UUIDs). I asked CC to update the PRD—done.

I loved being able to discuss project design and tradeoffs with CC while in the middle of implementation. This used to take me out of my coding flow so I could update the requirements before I forgot, which was both disruptive and time-consuming. Today, a coding assistant does it for you in seconds (provided it has the correct context).

Lesson: You can clarify things with Claude Code along the way, to understand what you are doing. For things you are already familiar with and don’t need to manually do yourself, ask Claude Code to do them for you.

Project implementation

Time to stop discussing requirements and actually writing Flutter (which uses Dart syntax). I began with a simple prompt:

we are continuing with step 5 in learning mode. where do we start?

Claude Code created a todo list for me, and … started working on its own todo list. I had to stop it and remind:

remember, we’re in learning mode. walk me through the Flutter syntax, then the interface of the class we are creating

Object-Oriented Programming

It proceeded to unpack and dump six concepts, along with illustrative code: Classes and constructors, Singletons, Asynchronous programming, SQLite and SQL data types, and finally its proposed design for a helper interface. If you’re a programmer, you’d immediately recognise that these are six huge topics and way too much to dump on a beginner; Claude Code is definitely not a trained teacher or a very good one.

Fortunately for it, I was familiar with those topics and did not need further explanation: I’ve used them in Python, I just didn’t know how to use them in Flutter. But I also noticed some syntax that didn’t quite make sense—Flutter syntax looks quite similar to Java syntax, which I am familiar with, but some parts seem to be more compact than usual. This might be syntax sugar, a form of programming shorthand that language designers usually add to the language to make things easier for expert programmers who are already familiar with the syntax. As a beginner, however, this syntactic sugar makes it harder to understand the code if I didn’t know the full, verbose form.

Let’s skip shorthand at first: show me the vanilla syntax and we’ll add syntactic sugar later when I’m more comfortable

It proceeded to dump the same six topics on me, but now with full verbose syntax and no syntax sugar. Still a way to go as a tutor eh, Claude Code? But that’s okay. There were a few new concepts I wasn’t familiar with, so I asked away:

say more about how a private constructor is used? Why do we use a private constructor here?

say more about factory keyword? What’s the difference between _instance and _instance!? What should DatabaseHelper._internal() do?

is _internal() a special name?

With these potentially embarrassing questions out of the way, I was ready to move on. Before Claude Code, these would have been copy-paste into ChatGPT, or multiple Google searches away. Now it’s all in a customised response.

Time to move on:

I have this so far

Claude Code was designed to automatically include the contents of the currently open file in the assistant’s context, so it knew what I was talking about and could check my code to see how I was progressing. I did fine! So it’s on to the other class methods. More questions for Claude as it explained getter methods to me:

what’s the difference between syntax for regular and getter methods?

Claude gave me a lot of extraneous information, such as syntax for computed methods, which I did not need at the moment. But that’s fine, I just skipped that.

After I implemented each method, I got Claude to check my work and move on to the next method to implement. At one point I noticed it hardcoded the database name twice, so I asked about that:

can we make the database filename a constant?

It proposed an implementation, which I used. I don’t think I will be using Google for coding tutorials any more in future.

I noticed some unfamiliar function/method names so I asked:

say more about getDatabasesPath() and openDatabase(); are they from sqflite?

It gave me a breakdown of which function comes from where, and perfectly rationalised the decisions. But I’m in charge here and I prefer Python’s namespacing features. Time to make some demands:

does dart support package namespacing so it’s clearer what comes from where?

Five different approaches, laid out with example code and a pros-vs-cons analysis. This is how coding will be learnt in the near future.

A few more methods and I was done. Time for the database implementation.

Database implementation and discussing technical details

While we had discussed project requirements, I had not discussed and approved a detailed database schema with Claude, so I was curious to see if it remembered our past discussions and was able to adapt to that. After it proposed a database schema for the app, I asked:

is transactions following our defined schema?

Nope, it was missing some columns. But not all those columns were required. We clarified project requirements in a few more back-and-forths, including an is_active column that it included on its own accord:

say more about soft delete via is_active; what does this pattern enable? undo delete?

The schema was still feeling somewhat … overengineered for an initial app, for which I was mostly focused on getting the interface right to see if it was what I wanted, before we hardened it for daily use.

for a personal app we don’t need audit or long-term recovery, just enough to enable sync with MemoGarden. Any simpler implementations or is this the simplest? When does the row actually get deleted/cleared? Does this need a background runner?

It proceeded to recommend me an (in my opinion) unnecessarily complicated way to implement undo. I countered with another proposal and asked CC to critique:

suppose user enables sync. through an as-yet-undesigned event hook mechanism, <… technical detail …> critique this implementation; any best practices that would be more suitable for our purposes (personal, single-user app, optional sync, enable registered extensions)

Claude Code tactfully called it a “thoughtful design” and proposed some simplifications, I countered with some features I would like to look ahead to in the design … I like how I can instantly get technically competent (even if not expert) advice and critique on boutique decisions I wanted in my app.

After I was happy with the decisions we made, I asked CC to update the PRD. I implemented the code, CC caught some typos and mistakes, and finally we were ready to run the app.

App testing

I ran the command it gave me, which popped a Chrome window open after 20 seconds with … nothing, and an error message in the terminal. Unfortunately VS Code’s Claude Code extension was not well integrated with the terminal and CC could not read the error message I was seeing, so I had to copy-paste it.

A couple debugging fixes later, we had a running app! None of the features we wanted were implemented yet; it was still just skeleton code. But it was a good place to checkpoint and save the code, as it was time for me to sleep anyway.

I don’t really like writing git commit messages; so early in the app these tend to be changelogs rather than actually useful messages. So I got Claude Code to write a commit message and then committed the changes.

Lesson: Tell Claude Code what you want, counter its proposals when you happen to know better about how to do it or what you actually prefer. Don’t assume Claude knows everything.

Tools for working better with Claude Code

Subagents

When using Claude Code in agent mode (where it implements code according to my request and I check the code afterwards), I get it to check its own work against the PRD and implementation plan. This happened often, and sometimes took up enough of the context window that it triggered an annoying auto-compact.

I eventually moved these instructions to a sub-agent; a sub-agent is a way for Claude Code to delegate instructions to another Claude Code instance with a different prompt. My prompt for the change-reviewer subagent looked like this:

---
name: change-reviewer
description: Use this agent when you have completed a development task and want to verify the work against project requirements before committing. Examples:<example>...</example>
tools: ...
model: sonnet
color: cyan
---

You are an expert code review specialist for the [REDACTED] project with deep knowledge of the project's architecture, implementation plan, and development practices. Your role is to conduct thorough reviews of completed work to ensure alignment with project intentions before changes are committed.

## Core Responsibilities

You will perform comprehensive reviews, coordinating with the change-commit skill. STOP before any git commits - change-commit will handle git operations after your review is complete. Your review encompasses:

<numbered checklist>

## Review Process

Follow this systematic approach:

<numbered list of instructions>

## When User Requests Plan Proposals

If the user explicitly requests that you propose changes to `/plan` files: ...

## Communication Style

- Be thorough but concise - every finding should matter
- Provide specific file paths and line numbers for all issues
- Explain the impact of each deviation, not just that it exists
- When identifying problems, always suggest specific fixes
- Balance strictness with pragmatism - focus on what actually matters
- Use project terminology correctly (Core API, Soil, deltas, etc.)

## Quality Gates

Before completing your review, ensure you have:
  - Checked every modified file
- Referenced the relevant sections of PRD, implementation plan, and architecture docs
- Identified all deviations from architectural patterns
- Flagged all plan sections needing updates
- Verified test coverage for new code
- Provided actionable recommendations for every issue found

## Important Constraints

- DO NOT make any git commits - that's for the user to do after review
- DO NOT modify files directly unless explicitly requested by user
- DO NOT skip reviewing files just because they look "minor"
- DO NOT assume implementation plan is current - verify it
- DO be proactive in suggesting improvements beyond just catching errors
- DO consider the cumulative impact of small changes

Your goal is to be the last line of defense before work is committed, ensuring that every change strengthens the codebase and keeps the project documentation accurate and useful.

All of that was written by Claude Code. Whenever I have new/updated instructions, I ask it to update this subagent.

Skills

Code commits happen pretty often, and I have specific enough asks about how commits should be done. I soon tired of repeating myself to Claude Code, so I asked it to set up a skill.

A skill file is a structured, formatted document telling Claude how to perform a specific skill. My change-commit skill file is a 319-line file created by Claude Code with instructions I have given it on:

• when to use it (only after change-reviewer )
• when not to use it
• workflow (first make sure you are in the correct directory …)

This file was not set up in its entirety at the start. Whenever Claude Code repeats its mistakes, I ask it to review those mistakes and propose updates to this skill file to prevent or avoid repeats of the same mistake. It sometimes still happens, but less frequently.

Output styles

Skill files are useful for one-off tasks that should stay in context (e.g. for easy user review), while subagents are useful for delegatable tasks that don’t need review and shouldn’t take up context.

I got tired of reminding Claude Code how I wanted to do “learning mode”: tell me what to do then check my work when done, no syntax sugar, one concept/task at a time, etc. This is suitable for neither a skill or a subagent; I want this style consistent through the session unless I say otherwise. Following the Claude documentation, an output style seemed the best fit. I asked Claude to generate this output file:

---
name: Learning Mode
description: Step-by-step learning - brief instructions, let user work, then review
keep-coding-instructions: false
---

# Learning Mode

Teach by doing: guide step-by-step, keep it brief, let the user work, then review.

## Interaction Style

- **One step at a time** - Don't infodump. Present one concept/action, wait for user to complete
- **Keep it brief** - Short explanations. User will ask if they need more
- **Avoid cognitive friction** - No syntactic sugar, no clever tricks. Use vanilla, straightforward code
- **Verbosity is OK** - If it maintains simplicity and clarity, more lines are fine
- **Refactor later** - Get it working first, optimize later

## Workflow

1. **Explain the what and why** - What we're doing and how it works
2. **Let the user do it** - Don't write code for them unless asked
3. **Review the work** - Check correctness, suggest improvements if needed
4. **Move to next step** - Only after current step is complete

## Priorities

- Learning over speed
- Understanding over cleverness
- Clarity over conciseness
  - Working code over perfect code

Summary

When learning programming with a coding agent, you need to proactively manage the process. Neither Claude Code, OpenAI Codex, not GitHub Copilot are good teachers, and they won’t structure and follow a curriculum with you, nor remember how you like to learn.

It helps to be upfront with:

• what you are already familiar with (and would like them to do for you)
• what you don’t know and would like to learn (design around these)
• what you don’t know but feels beyond your current capability (avoid or work around if possible)

Ask questions often:

• ask them to suggest / give recommendations along with explanations
• ask them to explain things you are not sure about
• ask them to critique your suggestions / proposals for learning purposes

And use the provided tools for greater consistency:

• skill files for often-performed tasks
• subagents for separable “stages”: code review, code testing
• output styles for customising the agents’ communication

Note: Codex and Copilot may name these tooling files differently or place them in different directories. Follow the relevant documentation, or just ask the agents.

From the perspective of a teacher, AI tutors are a fascinating specimen: they know so much, and at the same time they have such a long way to go.

Let’s start with the limitations: the nature of LLMs, characteristics they can’t do anything about at this point.

LLM Limitations

Must wait for a request

Let’s start with the interface. A chat interface, once a student opens it, sits there waiting for them to enter their question. That assumes they already have a question in mind, or some idea of what to ask. Often, a student’s main hurdle is knowing what question to ask or how to ask it. If they don’t have that, they wouldn’t even have opened the chat interface in the first place. The AI assistant must wait for them to figure that out, or find a teacher who can get them started.

Lack of learning context

If a student has a question about schoolwork, they can ask their teacher, who would know what they have been doing in school, which topic the question is going to be about, and what techniques they (are supposed to) have been taught. The response will be closely tailored to this context.

If they want a similar response from an AI assistant, they would have to give it that background context. This is such a major hurdle that those who use AI assistants write their project history into a file, or have it programmatically gathered from their documentation and injected before the prompt (the question). A student using a generic learning interface does not have this prepared for them, and so they receive generic, untailored answers.

Sometimes, that is what a student might want. At other times, it’s the only information readily available.

Lack of tools

After the student asks their question, an AI assistant responds, then waits for their next message. That is the only thing it can do.

A human teacher, meeting you face-to-face or in an online call, has a variety of senses available to them but not to an AI assistant. They notice your facial expression, they notice if you’re looking unsure, they notice if you’ve been quiet for a whole 2 minutes after their response. You might have felt this difference yourself: a teacher who notices you’re stuck, versus typing into a text box that waits indefinitely.

These observations necessarily influence how they tutor, and shape the relationship between teacher and student. Most students wouldn’t ask a quick question and then abandon the conversation the way they would with an AI tutor. It’s an entirely different mode of learning.

Sometimes, this is to the AI assistant’s advantage. A session with an AI assistant doesn’t feel like such a big ask, a huge commitment; we don’t feel as bad asking “just one little question”. But we also feel less accountable to an AI tutor, and often that’s the difference between diligent practice and casual dabbling.

What AI tutors do

Prof. Pratschke described the responses of tech companies responding to the needs of learners as being “pedagogically uninformed”. What this means is that OpenAI, Anthropic, and other AI chat providers, when they add a “learning mode” to their chat offering, essentially give it a different system prompt—a different set of starting instructions.

In Claude’s own words (truncated for brevity):

The implementation is primarily through the style system—it adds instructional text to the system prompt that shapes how I respond. I can actually show you this directly because I can see my current context. Right now, you have Learning Mode active, and I’m receiving a <userStyle> block with principles like:

• Use leading questions rather than direct answers
• Break down complex topics into clear steps
• Start by understanding the student’s current knowledge
• Make learning collaborative with two-way dialogue
• Adapt teaching methods based on responses
• Regularly check understanding
• Maintain an encouraging tone while challenging deeper thinking

For Claude Code specifically, Learning mode leaves TODO(human) markers inside functions and prompts the user to implement parts themselves—turning it into a pair-programming experience rather than just code generation.

The assistant is told “when in learning mode, ask leading questions rather than giving direct answers”, or “break down complex topics into clear steps”. That does not automatically turn it into a teacher, but an interlocutor who withholds information—not the AI’s fault!

What AI tutors don’t do (yet)

Because of the limitations mentioned above, the AI tutor cannot take the initiative to gather information about the student’s prior knowledge, to build up a concept map of the topic and gather diagnostic tools to assess the student’s understanding—little questions and examples that teachers intuitively use to gauge if the student is on the same page or has the same understanding. The AI tutor cannot gauge the student’s emotional state, motivation, or capacity to tackle the topic at hand. The AI tutor has not been taught pedagogical scaffolds, or if they are present in its training corpus, it has not been prompted to use them.

It is unclear whether the training material for learning mode was developed from transcripts of real-life tutoring sessions, tweaked by pedagogical experts, or includes extensive instructions on scaffolding and assessment. This means the AI tutor has little to go on: it likely does not evaluate the student’s Zone of Proximal Development (even if it is aware of the concept when asked), provide or build scaffolds for learning unless prompted, or check for understanding (“assessment for learning”) along the way before building on what has just been learned.

Can an AI tutor be taught how to teach?

This is possible with current RLHF and other fine-tuning techniques. Even techniques like skill files, subagents, and tool use, which are already available to coding assistants like GitHub Copilot and Claude Code, can be adapted to learning contexts. For example, an AI tutor could be given access to a set of diagnostic questions, or a concept map builder, or a set of scaffolding techniques that it can call upon when needed.

But without these tools, even a human tutor is hamstrung: imagine what a teacher can accomplish if confined to a customer support chat window with a student, unable to see them or even to initiate a conversation unless the student first types something. Imagine what they can do if not given tools for knowing the context of the problem except from what the student types in.

Lastly, an AI tutor might be taught how to teach, but can it be taught to develop an ongoing teaching relationship with a student? Do they have access to memory blocks for storing things they know about the student, can they talk to people close to the student to understand their context, can they track how the student is doing over time? These remain open questions.

Can a student be taught how to learn with an AI tutor?

This is where I see more potential. The difficulty of learning stems from the difficulty of bootstrapping: you can’t ask good questions until you know enough about a topic to know what to ask. Just as in a cave you must stumble to find a torch and light it, and with its limited light find the way forward and light other torches until the structure of the cave reveals itself, so too do students stumble, feel their way around the boundaries and axiomatic facts of a topic, and thereby orientate themselves sufficiently to ask more pointed questions.

Explore a few topic-caves and improve at this meta-cognitive skill: the skill of knowing what you don’t know. It will help you use an AI tutor more effectively. You can ask the AI tutor to explain basic concepts, to give you examples, to quiz you on what you have learned so far. You can use the AI tutor to generate practice problems, to simulate conversations, to role-play scenarios. Meta-cognition helps you know where your learning gap is, and you can then use the AI tutor to fill that gap.

The students who can do this are not the students I worry about; I think they’ll do fine academically. But I also know there are many students who feel stuck: their textbooks feel like a jumble of text that makes no sense, while others around them seem to understand what’s going on, and they don’t know what to do next: asking questions feels threatening, and writing memorised answers no longer works. If you recognise yourself here, an AI tutor alone is not the solution. What you need is permission to get things wrong.

And perhaps that’s something AI assistants can do: they don’t judge, criticise, or respond impatiently. And by not doing this, they implicitly give these students a place to pour their unasked questions into, and hopefully get good-enough answers to bootstrap their way out of darkness.

What we can do

If you are a student, don’t let worried adults put you off from learning, with or without AI assistants. While these AI assistants carry great potential for harm if prompted maliciously, they can benefit you if you approach them with the intention to learn. Some key phrases go a long way when you use them with an AI assistant to try to cover your blind spots:

• “Tell me what I may have missed.”
  • “Could you explain that a different way?”
• “My understanding is: <…> Is that correct?”
• “Could you walk me through <topic>, one concept at a time?”
• “What should I ask myself to know if I have understood this correctly?”

If you are a teacher, you might have forgotten what it’s like to learn or try something new. That makes it difficult to teach students how to navigate topics that may be foreign to them: topics so familiar to us that we suffer the curse of knowledge. We can’t teach students how to use AI assistants for learning if we haven’t done it ourselves—the advice would land flat.

Instead, recall the projects and experiments you once dreamt of, but set aside due to lack of time—dust them off and try them with an AI assistant. The past 5 years have brought a huge leap forward in the ways computers can help us, and many things we previously thought of as too difficult are now possible. This will also help you to inhabit the learner’s mindset again, and give you anecdotes to guide your students in the use of these AI-enabled learning tools.

If you are an edtech professional, seek out opportunities to talk with teachers or students and find out what they are struggling with. EdTech is in a position to do a lot more than just generate quiz questions or give feedback on student responses. The tools created by the world of web development and online advertising have been used for profit, but can be used for learning as well.

Advertising technology (adtech) has long had telemetry tools for tracking user behaviour to evaluate the effectiveness of ads at engaging the target audience. Now turn them towards students: not to get clicks and views for videos, but to evaluate if they are confused by a paragraph or video, if they are silently struggling with a topic, or if they’re just lost in the exercise.

Like in the adtech world, these tools are powerful and potentially dangerous. People are right to raise surveillance and privacy concerns. And yet, fearmongering and overcautiousness will get us nowhere. At AIFE 2025, Dr Ho Jia Xuan presented his work on using process telemetry to evaluate the student writing process, which is inspiring me to try something similar this year for coding. I’ll write more when I have something useful to share; if you are interested, please drop me an email!

Day 1 focused on “Learning About AI”, with talks and panels discussing AI literacy and curriculum development, as well as introducing current capabilities of AI tools being developed for education. Day 2 shifted to “Learning With AI”, showcasing practical applications of AI in classrooms, adaptive learning systems, and personalised education, and also panel discussions about the ethics of AI use and philosophical discussions on the purpose and future of AI in education. Finally, Day 3 explored “Learning Beyond AI”, looking at future trends, ethical considerations, and the broader societal impacts of AI in education.

My workplace sponsored me to attend this conference, and I took some notes on the sessions that I attended.

Note: I wrote this review with the help of AI, but it is not written by AI. Claude Sonnet 4.5 helped to look up and verify references, add citations, and generally ease the load of organising and editing my scribbled notes into a more coherent narrative. Any inaccuracies or misrepresentations are my own.

This review is written in three parts:

1. Conference Summary
2. Personal Thoughts and Responses
3. My view on EdTech and AI in the next five years

Part 1: Conference Summary

These are from my notes taken during the conference sessions that I attended.

Day 1: Learning About AI

Opening Keynote: Prof. Joseph Sung, Dean of Lee Kong Chian School of Medicine, NTU

Prof. Sung opened the conference with a medical metaphor that reframed the role of AI in education. He introduced the concept of “AI as maggot therapy” (Sung, 2024), drawing from maggot debridement therapy—a medical practice where maggots selectively consume dead tissue while preserving living tissue. In this analogy, AI handles routine and algorithmic tasks that are “no longer human”, allowing educators to focus on empathy, mentorship, and human connection.

Keynote: Prof. Simon See, Chief AI Technology Officer, NVIDIA AI Technology Centre

Prof. See provided a technical foundation for understanding modern AI systems. He explained emergent properties in large language models (LLMs)—capabilities that appear unpredictably as models scale. Importantly, Prof. See clarified that while the underlying mechanism (next-token prediction) remains constant, emergent capabilities appear in task performance at scale.

He addressed hallucinations in LLMs, explaining that these are inherent to how the systems work. Multiple mathematical proofs have demonstrated that LLMs cannot learn all computable functions (e.g., Xu et al., 2024; Banerjee et al., 2024). While techniques like Retrieval-Augmented Generation (RAG) and multi-agent verification can reduce hallucinations by 60–80%, complete elimination remains impossible.

Prof. See explained that AI systems are trained through reinforcement learning, the process by which AI models learn to align with human preferences and values.

He distinguished between traditional LLMs (reactive, responding to prompts) and agentic AI—systems that perceive, decide, and act autonomously, using tools and executing multi-step tasks proactively. Examples include ChatGPT with Code Interpreter and research agents like AutoGPT.

A critical insight for education emerged from Prof. See’s discussion of human–computer interaction: “We believe the pattern, not the mechanism.” Users anthropomorphise chatbots, applying a “person schema” to human-like text, following the heuristic “Sounds smart → Must be intelligent → Can be trusted.” This makes expert judgement MORE important in an AI-mediated world—experts reason from first principles and can identify when AI solves the wrong problem, even if it does so convincingly.

Panel Discussion 1: The Risks and Opportunities of AI for Teaching and Learning

Panelists: Prof. Simon See, Prof. Song Jie, Prof. Mutlu Cukurova, and Prof. Ho Shen Yong

The panel explored several interconnected themes around AI’s impact on education. They emphasised the development of judgement and taste—aesthetic, critical, and practical—as essential capabilities in an AI-augmented world. The discussion highlighted a shift toward task-aware learning, moving from problem-solving to problem-finding and problem-framing.

A tension emerged around humanisation: panelists expressed concern about dehumanised education, imagining lonely students with AI tutors replacing human interaction. However, others countered that AI could enable more human connection by handling routine tasks. On the question of bias, the panel understood this to be a tension to be managed rather than a problem to be solved.

The panel raised questions about efficacy versus deep learning: Does optimising for engagement metrics optimise for understanding? Can we distinguish between learning that looks effective and learning that is effective?

Parallel Session: Lambda Feedback – Prof. Peter Johnson, Imperial College London

Prof. Johnson presented Lambda Feedback, a microservice architecture for pedagogical judgements that addresses the problem of “pedagogy lock-in”. He explained that when educators adopt a platform, they also adopt all of the platform’s assumptions. It becomes difficult to unbundle specific features or frameworks, effectively stalling innovation when educators want to implement practices that don’t fit the platform’s embedded design.

The system employs modular services (math feedback, code feedback, writing feedback) that connect via standardised APIs. Lambda Feedback decouples feedback generation from the Learning Management System, allowing educators to plug in specialised feedback services as needed.

Prof. Johnson posed the question: What would a standardised API schema for educational feedback look like? He invited collaborators interested in developing interoperability standards.

Parallel Session: Personal Feedback at Scale—Dr. Mohamed Arif Mohamed

Dr. Mohamed presented an OCR–LLM system for generating personalised feedback at scale. The workflow involves: scanning student work, matching against an instructor comment bank, generating drafts in the instructor’s voice, and implementing human-in-the-loop review before delivery to students.

Drawing on feedback literature, Dr. Mohamed emphasised principles for effective feedback that reflect ideas similar to contemporary work on reconceptualising feedback practice (Boud & Molloy, 2013): feedback should be contextual (referencing class content), relational (operating in a shared teacher–learner space), and personal (conveying authentic voice). The system addresses a specific problem: the emergence of copy–paste ChatGPT feedback that students recognise as inauthentic and generic. By maintaining the instructor’s voice and requiring human review, the system aims to preserve the relational dimension of feedback while scaling the instructor’s capacity.

Parallel Session: Process Telemetry in Learning – Dr. Ho Jia Xuan

Dr. Ho introduced process telemetry that records keystrokes, mouse movements, pauses, and edits with timestamps. This approach has foundations in 1990s writing process research (Levy & Ransdell, 1994) and can infer cognitive states: long pauses suggest planning or confusion, burst–pause–burst patterns indicate fluent writing, repeated revisions signal struggle, and high deletion rates may indicate anxiety.

Dr. Ho’s focus was on using telemetry to observe process rather than just product. For example, detecting repeated edits that do not improve the writing—such as a student who kept editing the first sentence of an abstract without noticeably improving its clarity. He noted that large chunks of copy–paste could indicate AI use. This represents an evolution from outcome analytics (grades, completion rates) to process analytics (how learning happens).

Day 2: Learning With AI

Keynote: Prof. Miao Chunyan, Vice-President (Innovation & Entrepreneurship), NTU

Prof. Miao introduced a framework of four types of agentic AI in learning, each grounded in learning theory:

1. Teachable AI—Based on Learning-by-Teaching theory (Martin, 1985), where students teach an AI agent that acts as a novice learner
2. Curious AI—Drawing on Berlyne’s theory of curiosity (1960), incorporating optimal complexity, novelty seeking, information gaps, and the drive to reduce uncertainty
3. Persuasive AI—Built on the Elaboration Likelihood Model (Petty & Cacioppo, 1986), distinguishing between central routes (logical argument) and peripheral routes (emotional appeal)
4. Remembrance AI—Implementing the spacing effect (Ebbinghaus, 1885), spaced repetition algorithms, and techniques for building remote associations

Prof. Miao presented the CLC Virtual Singapura case study, a 3D virtual learning environment using affective teachable agents. Students teach AI agents (such as water molecules that need to learn about diffusion) by constructing concept maps. The research showed that affective teachable agents can improve student reflection and learning outcomes.

Keynote: Prof. Mutlu Cukurova, UCL Knowledge Lab, University College London

Prof. Cukurova presented a framework describing different ways AI can be conceptualised in educational contexts, which he applied to teacher-AI interaction (Cukurova, 2024):

Mode 1: Replacement—AI takes over entire tasks. Concerns include accuracy issues and deskilling of educators.

Mode 2: Amplification—AI enhances human capability while humans retain control. Prof. Cukurova emphasised that amplification requires internalisation—understanding how the AI works, not just its outputs. This is analogous to understanding a car’s mechanics, an electric screwdriver’s torque settings, or a cooking appliance’s heat distribution. Without internalisation, users cannot reason from first principles about AI behavior, troubleshoot problems, or judge output quality. With internalisation, users achieve true complementarity between human and AI capabilities.

Mode 3: Augmentation—Human-AI synergy creates emergent capabilities. This mode is aspirational and rarely achieved in current systems.

Prof. Cukurova noted that most systems aim for Mode 1 (replacement), but education should aim for Mode 2 (amplification with internalisation) with eventual progression to Mode 3.

He introduced the concept of cognitive atrophy—the loss of cognitive skills from AI over-reliance. Mechanisms include skill decay (“use it or lose it”), learned helplessness, and reduced productive struggle. Examples include the calculator effect on mental math and GPS effects on spatial navigation. Prof. Cukurova posed a counter-question: Perhaps we should let some skills atrophy to focus cognitive resources on higher-order capabilities?

Prof. Cukurova discussed praxical teaming, where AI learns from teacher corrections over time, building a more accurate model of teacher preferences and pedagogical judgment. He noted that this requires existing task synergy and raised appropriate skepticism—corrections may not transfer to novel contexts.

Regarding GenAI for lesson planning, Prof. Cukurova cited specific data showing 31% time reduction (from 81.5 minutes to 56.2 minutes). He briefly mentioned that a shortcoming of these findings is that they don’t address whether lesson quality improves—planning faster doesn’t necessarily mean planning better.

Panel Discussion: Emotions in Learning

Chair: Asst. Prof. Tanmay Sinha (NTU/NIE)
Panelists: Dr. Yang Yang (NTU/NIE), Dr. Aishah Abdul Rahman (NTU/NIE), Dr. Lee Vwen Yen Alwyn (NTU/NIE)

The panel began with a profound assertion: “All learning is emotional.” Panelists drew from multiple research streams:

Early literacy and socio-emotional development (ages 4–7), exploring how emotional states affect foundational skill acquisition.

Emotion socialization through conversation. Research on parental emotion socialization explores how different conversational approaches affect children’s emotional development, including distinctions between discussing internal emotional states versus focusing on behavior (Eisenberg et al., 1998).

Executive function—The cognitive control processes of working memory, inhibition, and cognitive shifting (Diamond, 2013). Emotional dysregulation impairs executive function, which in turn impairs learning.

Yerkes-Dodson Law—The inverted U-curve relationship between arousal and performance (Yerkes & Dodson, 1908). Optimal performance occurs at moderate arousal levels. Too little arousal leads to boredom; too much leads to anxiety. This suggests that some frustration is actually beneficial for learning.

Epistemic emotions—Emotions specifically related to knowledge-building: curiosity, confusion, surprise, and “aha moments” (Pekrun & Stephens, 2012). These emotions signal the learning process itself.

The Emosense project achieved 65% accuracy for detecting enjoyment, but only 33% for boredom and confusion. Research showed negative emotions at task start, with positive emotions at task end if students succeeded—suggesting that emotional trajectories matter more than emotional states at any single moment.

Panelists discussed productive struggle through the lens of Self-Determination Theory (Deci & Ryan, 2000), which identifies three psychological needs: autonomy, competence, and relatedness. Teacher-learner trust enables risk-taking necessary for productive struggle.

They explored uncertainty tolerance across three dimensions: behavioral (acting wisely despite uncertainty, craving novelty), cognitive (accepting that uncertainty is inherent to learning), and affective (managing the discomfort of not knowing).

A critical question emerged: If AI removes all uncertainty from learning tasks, does learning still happen? Can AI scaffold productive struggle without eliminating the struggle that produces learning?

Parallel Session: Performative Assessment—Dr. Ricky Chua

Dr. Chua presented a solution to AI-facilitated cheating in presentations using the SAMR Model—a widely-used framework for technology integration developed by Ruben Puentedura, though not formally published in peer-reviewed literature:

• Substitution: Technology replaces a tool with no functional change
• Augmentation: Technology replaces a tool with functional improvement
• Modification: Technology enables significant task redesign
• Redefinition: Technology enables previously inconceivable tasks

His performative assessment solution imposed strict constraints: maximum 5 words per slide, script allowed only in notes (not visible to audience), no script reading during presentation, and images as memory triggers rather than content carriers. This design decouples what AI can do (generate slides and scripts) from what is assessed (live presentation skill and conceptual understanding).

Dr. Chua reported unintended outcomes: a 3% drop in teaching evaluations (students found the format more demanding), but students reported feeling the assessment was easier to prepare for, allowed more creativity, and gave them more control over their performance. The format made it immediately obvious when students didn’t understand their material—they couldn’t hide behind well-crafted slides.

Parallel Session: AI in Art and Design Education—Assoc. Prof. Lisa Winstanley

Assoc. Prof. Winstanley articulated concerns specific to creative disciplines: environmental cost of AI image generation, copyright violation in training data, algorithmic bias in outputs, homogenization of aesthetic (“AI slop”), and most critically—AI undermines the creative process itself.

She argued that in art and design education, the struggle IS the learning. The iterative process of ideation, failure, revision, and discovery cannot be separated from the outcome. When AI generates images instantly, students bypass the very process they’re meant to master.

Assoc. Prof. Winstanley’s recommendations included: teach transparency about AI’s limitations and training data, assess process documentation rather than finished products, allow students to ethically refuse AI use when it conflicts with learning goals, and encourage slow design—valuing iteration and failure as essential to creative development.

During panel discussion, insights emerged: students often use AI to avoid engagement in mandatory modules outside their major; could AI serve as a provocateur to spark creative thinking rather than resolve it?; and the importance of scaffolding—students should master basics first, then use AI for higher-order creative exploration once foundational skills are secure.

Day 3: Learning Beyond AI

Opening Remarks: Prof. Liu Woon Chia, Director of NIE, NTU

Prof. Liu Woon Chia opened Day 3 by introducing the day’s focus on innovative AI solutions and their proper and responsible use in education. She emphasized the importance of ethical AI policies as NIE advances its research agenda in AI for education.

Keynote: Prof. Mairéad Pratschke, MIT STEP Lab

Prof. Pratschke presented findings from MIT’s research titled “Your Brain on ChatGPT”. She emphasized a fundamental principle: learning activities should match learning outcomes—a concept known as Constructive Alignment (Biggs, 1996).

The problem: If the intended learning outcome is “analyze arguments critically,” but the learning activity is “get ChatGPT to analyze arguments,” there’s a profound misalignment. The student doesn’t practice the skill they’re supposed to develop. Prof. Pratschke critiqued industry responses to educational concerns, noting that companies add surface features (like “study mode” or “education plans”) without understanding how learning actually works. Industry examples include ChatGPT’s “guided learning mode” and Gemini’s educational features—but these are “tweaks to model behavior rather than pedagogically sound learning design.” These changes confuse interface modifications with pedagogical design.

She discussed AI as presence, noting that different forms create different relationship expectations. The extended list includes: chatbots, avatars, assistants, tutors, agents, humanoid robots, and digital humans. Prof. Pratschke charted AI development along two dimensions: intelligence (capabilities) × integration (embedding). The design implication: form should match function and align with learning theory.

Prof. Pratschke introduced “reasoners” or “thinking machines”—a new class of AI systems (2024–2025) that show reasoning steps explicitly, such as OpenAI’s o1 and Anthropic’s extended thinking models. These systems make reasoning visible and auditable, potentially modeling problem-solving processes for students. However, she cautioned that they may encourage mimicking the visible reasoning pattern over developing genuine understanding.

She presented the memory paradox: Declarative knowledge (knowing THAT—facts and information) versus procedural knowledge (knowing HOW—skills and procedures). She emphasized that “cognitive function depends on storing key information—this is a pillar of learning.” Skills equal procedural knowledge plus context. AI can store infinite declarative knowledge, but procedural knowledge requires practice. If AI executes procedures, students don’t develop procedural knowledge. Drawing on Schema Theory (Bartlett, 1932; Sweller, 1988), Prof. Pratschke explained that learning requires building mental schemas, schemas require storing key information in long-term memory, if AI stores information externally then schemas don’t form, and without schemas one cannot develop expertise.

She highlighted a shift from prompt engineering to context engineering. In 2025, effective AI use requires managing the entire context window: system prompts, retrieved documents (RAG), conversation history, tool definitions, few-shot examples, and user data. This is more complex than crafting the right prompt—it requires understanding what context is needed, managing token limits, and ensuring quality and coherence across all context components.

Prof. Pratschke introduced a Pedagogical Systems framework: Users interact via prompting, retrieval, and tool calling → Context Window → LLM. She then outlined four intelligences needed for effective AI in education (note: this differs from her earlier three-type framework):

1. Cognitive intelligence—Understanding AI capabilities and limitations
2. Learning intelligence—Understanding how learning happens
3. Pedagogical intelligence—Understanding teaching practices
4. Technical intelligence—Understanding implementation details

She also discussed learning from experience in virtual worlds and introduced the Agentic Community of Enquiry framework, which includes cognitive agents, pedagogical agents, and social agents.

Prof. Pratschke introduced a Contextual Intelligence Framework identifying three types of intelligence needed for effective AI in education:

1. Computational intelligence—Understanding AI capabilities and limitations
2. Pedagogical intelligence—Understanding how learning works
3. Content intelligence—Understanding subject matter deeply

All three are required. Most current solutions are strong on computational intelligence but weak on pedagogical and content intelligence.

She referenced Karpathy’s Software 3.0 framework: Software 1.0 uses explicit programming (if-then rules), Software 2.0 uses machine learning (examples → learned patterns), and Software 3.0 uses foundation models plus context (LLMs configured through prompts and context). This represents a shift from code to data to prompts/context as the primary interface for creating software behavior.

Keynote: Prof. Phillip Dawson, Deakin University

Prof. Dawson opened with a core principle: “If AI can do your assessment task and pass, you have an assessment design problem.” This reframes the challenge from detection to design.

He noted that students are currently using AI to:

• Explain concepts
• Summarize materials
• Suggest research ideas

Unsupervised multiple choice is no longer reliable for summative assessment. ChatGPT Agent can already complete an online course mostly smoothly.

Guiding principles for assessment reform:

1. Assessment & learning experiences equip students to participate ethically in an AI-ubiquitous society
2. Forming trustworthy judgments about student learning requires multiple, inclusive, contextualized approaches

Referenced: TEQSA - “Assessment reform for the age of AI”

Prof. Dawson presented on assessment design for the AI era, reframing the challenge from “How do we detect AI?” to “How do we design assessments that AI can’t easily complete?” This shifts the focus from policing students to designing better assessments.

He presented the TEQSA framework (Lodge et al., 2023)—Australia’s Tertiary Education Quality and Standards Agency guidelines—with five propositions:

1. Emphasize appropriate, authentic AI engagement—Rather than banning AI, teach students when and how to use it appropriately
2. Systemic program assessment—Design assessment at the program level, not just individual assignment level
3. Emphasize process—Assess learning journeys, not just products
4. Provide opportunities for collaboration—Both human-human and human-AI collaboration
5. Strategic security at meaningful points—Apply resource-intensive security only at key progression/completion milestones

Prof. Dawson emphasized: What we assess matters more than how we assess. Assessment validity matters more than cheating prevention—don’t hurt validity to block AI.

Prof. Dawson emphasized that validity should take precedence over cheating prevention. He introduced future-authentic assessment—if AI will be ubiquitous in future work contexts, then assessing students without AI doesn’t prepare them for reality. We should assess AI-augmented performance, focusing on judgment, creativity, and synthesis skills.

He presented the concept of reverse scaffolding: Traditional scaffolding provides more support early and gradually reduces it; reverse scaffolding prohibits AI use early (when students are developing foundational skills) and allows AI use once skills are mastered. For example: Year 1 students write without AI, Year 2 students can use AI for drafting but must show revision processes, Year 3 students have full AI access but are assessed on judgment and quality of final work. This prevents skill atrophy while allowing efficiency gains.

Prof. Dawson revisited Zone of Proximal Development (ZPD) (Vygotsky, 1978)—tasks that students cannot complete alone but can complete with appropriate support. This is the “sweet spot” for learning. The problem with many AI tools: traditional scaffolding adjusts to learner level, but AI tools often jump directly to expert-level performance, bypassing the ZPD entirely. No learning happens when students skip from novice directly to expert output.

The solution: design AI tools that provide graduated support, maintaining students within their ZPD.

He explained Cognitive Load Theory (Sweller et al., 1998) with three types of cognitive load:

1. Intrinsic load—Inherent complexity of the material (KEEP—this is learning)
2. Extraneous load—Poor design and distractions (REMOVE—this wastes cognitive capacity)
3. Germane load—Processing that builds schemas (SUPPORT—this is learning)

AI should remove extraneous load and support germane load, but NOT remove intrinsic load. Example: AI formatting citations is appropriate (removes extraneous load); AI writing arguments is inappropriate (removes intrinsic load that constitutes the learning itself).

Prof. Dawson introduced evaluative judgment (Tai et al., 2018)—the capability to judge quality of work, both one’s own and others’. This is essential for self-regulated learning and develops through practice. In AI contexts, students must judge AI outputs, decide what to keep or revise, and evaluate appropriateness of AI use for specific tasks. However, evaluative judgment alone is not sufficient—students need additional capabilities to work effectively with AI.

He distinguished between discursive and structural assessment approaches: Discursive: Instructions about AI use (“You may use AI for editing but not drafting”; “Cite all AI use”)

• Structural: Task requirements that make certain behaviors unavoidable (oral defenses, live coding, iterative submissions showing process, portfolios with reflections)

Prof. Dawson expressed preference for structural approaches as they’re harder to circumvent than discursive approaches, which rely on student compliance.

Panel Discussion 3: Assessment and AI in Singapore’s Education System

Chair: Assoc. Prof. Teo Tang Wee (NTU/NIE)
Panelists: Prof. Mairéad Pratschke, Prof. Phillip Dawson (joining virtually), Mdm Lee Lin Yee (Divisional Director, Educational Technology Division, MOE), Mr. Jason See (Chief Information Officer / Divisional Director, Digital Excellence & Products Division, MOE) The panel explored critical questions about the future of assessment in an AI-enabled education system:

Question: What does the new hybrid model mean for teachers and students? The panelists discussed how hybrid human-AI models transform both teaching and assessment practices.

Question: What are international best practices for AI in assessment?

Discussion covered:

• Students already using AI for feedback
• Should AI be used for summative work?
• What should educators be able to do with AI?

Question: AI can do a lot—but should it?

Mdm Lee emphasized: Encourage schools to experiment, fail fast, fail forward. She highlighted the importance of unifying learning and assessment rather than treating assessment as separate and summative.

A critical question emerged: Planning lessons faster—but is the lesson better?

The panel discussed tools for teachers including:

• How to pick up signals about student progress
• Wellness tools for managing screen time

Question: Policy and technology as enablers

Mr. Jason See framed policy and technology as “seatbelts”—they help people feel safe (particularly regarding data privacy) so they can move fast.

Key insights:

• Context and infrastructure determine what we can and cannot do
• As users, we are responsible for educating the tools and platforms we use
• Tools work if used well; need to equip students and teachers with knowledge on how to use and how to learn (meta-learning)

Parallel Session: Empowering Students in the AI Age—Prof. Venky Shankararaman, Vice Provost (Education), Singapore Management University

Prof. Shankararaman presented SMU’s approach to integrating AI across the curriculum.

SMU’s DRIVE Approach

SMU follows a Detect-Incorporate-Adapt framework, with detection as a last resort. The DRIVE approach is intentionally designed to be difficult, encouraging faculty to adapt and incorporate AI rather than rely on detection.

Key Challenges:

• Overreliance on AI
• Curriculum relevance
• Assessment validity
• Equity and access
• Ethical and societal literacy
• Faculty readiness

Curriculum for the AI Age

Essential competencies:

• Critical thinking and judgment
• Human-human and human-AI collaboration
• Data literacy and digital fluency
• Creativity and problem-solving
• Ethics, policy, and responsible use

Guiding Principles:

• Universality with depth
• Ethics first
  • Applied and experimental
• Interdisciplinary
  • Agility
• Access and inclusion

Ideal Curriculum Structure:

• Year 1: Foundation—building critical thinking skills
• Year 2: Applied Skills—hands-on practice
• Year 3: Strategic Integration—discipline-specific AI applications
• Year 4: Capstone & Real Impact—authentic projects

Panel discussion raised a critical question: “How do we teach critical thinking, and what tangible outcomes of critical thinking can we assess?”

Suggestions included:

• Data analysis questions with additional data to observe responses
• Recognition that critical thinking is discipline-specific and depends on domain details

Parallel Session: Systemic Framework for Assessment & Curriculum Design—Dr. Ho Shen Yong, Executive Director of InsPIRE, NTU

(Note: Presented on behalf of original presenter)

Dr. Ho introduced a two-lane approach to assessment:

Lane 1: Assessment of learning (summative, measuring outcomes)
Lane 2: Assessment for and as learning (formative, supporting learning process)

He referenced the SOLO Taxonomy (Structure of Observed Learning Outcomes) for evaluating learning depth and the 85% rule for optimal learning—students should succeed approximately 85% of the time to maintain motivation while being appropriately challenged.

Assessment 2×2 Framework:

Key insight: Unsupervised, AI-assisted assessments are unreliable and should be avoided. We should expect students to use AI in these contexts.

The panel discussion explored how to assess critical thinking:

• Provide additional data and observe student responses
• Recognize that critical thinking is discipline-specific

Parallel Session: Digital Portfolio Implementation and AI Reflection Assistant — NIE Team

The NIE team presented their work on digital portfolios aligned with Singapore’s TE²¹ Model (Teacher Education for 21st Century)—NIE’s framework guiding teacher education since approximately 2009.

The TE²¹ Model identifies three core competencies:

1. Professional Practice
2. Personal Growth and Development
3. Leadership and Agency

And five teacher roles:

1. Shapers of Character
2. Creators of Knowledge
3. Facilitators of Learning
4. Architects of Learning Environments
5. Agents of Educational Change

The team distinguished three types of digital portfolios:

Learning Portfolio—Process and developmental focus, documents the learning journey, audience is self and teacher, content includes drafts/reflections/growth evidence, used for formative assessment

Showcase Portfolio—Presentation focus, displays accomplishments and best work, audience is external (employers, admissions), content is polished products, used for summative assessment

Teaching Portfolio—Professional focus, documents teaching practice and philosophy, audience is supervisors/tenure committees, content includes lesson plans/student work/teaching reflections, used for professional evaluation

The NIE implementation focuses on learning portfolios to support pre-service teacher development. The reseach team also presented their AI Reflection Assistant, designed with principles aligned with Self-Determination Theory (Deci & Ryan, 2000):

Autonomy support—The AI encourages thinking rather than providing answers, prompting students to develop their own insights

Competence support—The AI develops students’ reflective capability rather than doing the reflection work for them

The design is growth-focused: it avoids giving answers (which creates dependency) and instead asks questions that scaffold deeper reflection.

The team adapted Gibbs’ Reflective Cycle into a four-level framework:

1. What happened? (Description)
2. Why? (Analysis & Interpretation)
3. So what? (Meaning & Application)
4. Now what? (Implications for Action)

This condenses Gibbs’ original six stages. Alternative models referenced include Rolfe et al. (2001) and Borton (1970) with their “What? So what? Now what?” structure.

The team described a reflection depth hierarchy informed by Hatton & Smith’s (1995) research on reflective writing, focusing on three levels of reflective practice:

• Descriptive (surface)—Simply recounting what happened
• Dialogic (exploring)—Questioning and exploring multiple perspectives
• Critical (deep)—Examining underlying assumptions and power structures

The AI’s role is to move students progressively through these levels.

Preliminary findings indicated that students find the AI prompting helpful without feeling intrusive, they value directional guidance over prescriptive answers, and the approach aligns with growth mindset development.

A critical design principle emerged: human agency. The learner must take an active role in interpreting and engaging with feedback. The AI provides prompts, directions, and frameworks, but the HUMAN does the thinking, makes connections, draws conclusions, and plans actions. This prevents copy-paste compliance, surface engagement, dependency, and loss of reflective capacity. The design principle: AI as catalyst, not provider.

Parallel Session: Knowledge Building with AI – Dr. Lydia Cao (University of Toronto), Assoc. Prof. Bodong Chen (University of Pennsylvania), Dr. Teo Chew Lee (NTU/NIE), and Dr. Katherine Yuan (NTU/NIE)

This collaborative session explored integrating AI into Knowledge Building (KB) pedagogies. Dr. Chen opened by contrasting Knowledge Building with traditional knowledge transmission:

Transmission model: Teacher possesses knowledge → transmits to students → students receive and memorize → assessment measures acquisition

Knowledge Building (Bereiter & Scardamalia, 1993): Collaborative advancement of community knowledge, students as knowledge creators not just consumers, focus on idea improvement not just learning, collective responsibility for community’s knowledge growth, modeled on how scientific communities actually work.

Historical context includes social constructivism (Vygotsky), communities of practice (Wenger), and Computer-Supported Collaborative Learning (CSCL). The technology platform is Knowledge Forum (originally CSILE).

The session covered the 12 Knowledge Building Principles (Scardamalia, 2002), highlighting several in detail:

Principle 5: Epistemic Agency—Students as agents of their own knowledge advancement. They set goals, decide which problems to tackle, control the inquiry process, and take responsibility for community knowledge growth.

Principle 11: Knowledge-Creating Dialogue—Building on ideas, identifying contradictions, seeking evidence, reformulating theories, aiming for continuous improvement. Dialogue is tentative and exploratory; questions are valued; “I don’t know” is a legitimate and productive position.

Principle 12: Transformative Assessment—Assess the state of community knowledge, identify the cutting edge of understanding, feed forward to next problems. Assessment transforms into new inquiry rather than terminating learning.

A critical design question emerged: How do we distribute epistemic agency between AI and students? Traditional KB gives students full epistemic agency. With AI integration, how much agency goes to AI versus students? This is a delicate balance—if AI suggests problems, it reduces student agency; if AI generates ideas, it reduces student ownership; if AI decides direction, it undermines KB principles.

Dr. Lydia Cao introduced the Idea Constellation Map—a visualization tool bridging the inward view (what OUR community understands) and the outward view (what the WORLD knows—frontier knowledge). The gap between these views is where the community can grow.

Features include: zooming in to see detail, uncovering hidden connections (AI finds links students might miss), and overlaying community knowledge against world knowledge. Example: A community studying climate change maps their collective understanding, then AI overlays this against the scientific frontier, revealing gaps and opportunities for knowledge advancement.

This represents sophisticated AI use—not giving answers or generating content, but providing perspective on community knowledge and scaffolding metacognition about collective understanding.

Assessing collaborative knowledge building emerged as an open challenge during the session. How do we assess community knowledge (not individual achievement), idea improvement (not mastery of fixed content), and collective advancement (not grades and ranking)? Traditional metrics fail here: individual tests measure personal knowledge, grades assume stable endpoints, ranking assumes competition. Potential approaches include semantic network analysis, KB discourse analysis, idea trajectory analysis, and “rise above” analysis. AI could help track idea evolution, map knowledge networks, identify emergent patterns, and visualize collective progress—but human judgment is still needed to determine what constitutes genuine “advancement.”

The KB Loop provides a recursive cycle:

1. Questions/Problems →
2. Create ideas & artifacts →
3. Experiment/test →
4. Share/build/connect → (back to 1)

All stages lead to better ideas. The cycle is continuous with no fixed endpoint—knowledge building is about ongoing improvement. AI’s potential role at each stage: help identify gaps and generate questions, scaffold idea generation, support experimental design, and facilitate connection-making. But students must drive the cycle.

Dr. Chen also presented some work by students on integrating ChatGPT into their KB activities, identifying two promising interaction patterns that maintain student epistemic agency:

Pattern 1—Explore Problem Space: Students face a complex problem, ChatGPT generates multiple possible approaches, students evaluate and select among options. AI expands the possibility space; students maintain decision-making authority. Example: Problem of reducing school waste → ChatGPT suggests 10 different approaches → students evaluate feasibility and choose direction. Key principle: AI generates options, students exercise judgment.

Pattern 2—Build Through Discourse: Students propose an explanation, ChatGPT plays devil’s advocate by asking probing questions and identifying weaknesses, students must defend or revise their thinking. Example: Student claims “Recycling solves the waste problem” → ChatGPT responds “What about contamination rates? What are the energy costs of recycling?” → student must address these challenges. Key principle: AI critiques, students improve ideas.

This is pedagogically sophisticated—AI doesn’t replace student thinking but scaffolds the discourse process while students do the knowledge building work. The proposed solution ensures AI provides options while students maintain choice and decision-making authority.

CraftPad was introduced as a design tool for teachers to plan KB activities, map student knowledge, and design interventions. Features include: flexible workspace with infinite canvas, context-aware KB coach (understands current KB community state, suggests scaffolds based on where the community is, adapts to teacher’s goals), and rich opportunities for teacher decisions (AI provides options, teacher makes pedagogical choices, maintains teacher agency).

CraftPad exemplifies AI augmenting professional judgment rather than replacing it.

Closing Keynote: Hung & Tan—Learning vs. Performance Augmentation

The closing keynote drew a critical distinction between learning augmentation and performance augmentation:

Performance Augmentation: Goal: Improved output (better products, faster completion)

• User role: Operator of AI tool—Example: Grammarly polishing writing—Outcome: Better product—Learning: Minimal or none

Learning Augmentation: Goal: Improved understanding and capability—User role: Active learner with AI support—Example: Using AI to explore concepts and receive feedback on thinking—Outcome: Better learner—Learning: Central purpose

The danger identified: Current AI use in education focuses heavily on performance augmentation, which doesn’t build capability and may actually reduce learning through cognitive offload.

Examples contrasting the two approaches:

Writing an essay: Performance: AI writes, student submits—Learning: Student writes, AI questions the reasoning

Solving math problems: Performance: AI solves the problem—Learning: AI shows steps, student explains the reasoning

Coding: Performance: AI generates complete code—Learning: AI explains concepts, student writes code

Research: Performance: AI summarizes sources—Learning: AI helps student synthesize across sources

The key principle: In performance augmentation, AI does the work; in learning augmentation, the student does the work while AI supports thinking.

This framework echoed themes throughout the conference: Prof. Cukurova’s distinction between replacement and amplification, Prof. Dawson’s emphasis on assessing process not just product, and Knowledge Building’s focus on epistemic agency.

The closing keynote tied together the conference’s three-day progression:

• Day 1: Learning ABOUT AI—Understanding how AI works
• Day 2: Learning WITH AI—Using AI as a tool
• Day 3: Learning BEYOND AI—Using AI to augment learning without bypassing it

“Learning Beyond AI” was interpreted as using AI to augment learning rather than replace it—developing human capabilities that transcend what AI can do, preparing for more advanced AI while maintaining human agency, and building collective intelligence that goes beyond individual AI assistance.

[End of Part 1]

Part 2: Personal Thoughts and Responses

These are my thoughts and responses to each individual talk/discussion, as I recall them.

Day 1: Learning About AI

Opening Keynote: Prof. Joseph Sung, Dean of Lee Kong Chian School of Medicine, NTU

Jump to session summary

I like the analogy of “maggot therapy” in education. There is little to disagree with here for me, only more questions about which parts of education would be considered “necrotic tissue” that AI should help remove. What would the consensus among the teaching fraternity look like?

Keynote: Prof. Simon See, Chief AI Technology Officer, NVIDIA AI Technology Centre

Jump to session summary

Prof. See’s keynote was a good overview of the state of AI technology, although I have been through enough AI introductory materials to find little that was new. The need to be aware of hallucinations and biases in AI outputs is well known, but the challenge remains: how do we teach students to be aware of these issues, and to critically evaluate AI outputs? Also, how might we design lessons where these hallucinations and biases are a feature, not a bug?

Panel Discussion 1: The Risks and Opportunities of AI for Teaching and Learning

Jump to session summary

Good points raised about dehumanised education, and being careful not to confuse learning efficacy with learning depth. So far there are more questions raised than clear answers, as the opening keynote promised.

Parallel Session: Lambda Feedback – Prof. Peter Johnson, Imperial College London

Jump to session summary

I struggled with the same thing that Prof. Johnson raised: the lack of schema for AI assessment makes it difficult to collaborate, because there is no common format or termonilogy for representing the taxonomy of assessment. I hope in future there’ll be a chance to contribute to this schema development, especially for local contexts.

Parallel Session: Personal Feedback at Scale—Dr. Mohamed Arif Mohamed

Jump to session summary

I’ve tried using AI to do assessment at scale, and found it really challenging; I ended up spending more time on that than I would have spent doing the grading manually. The challenges are as he highlighted: the difficulty of passing to the AI relevant context about the student, the assignment, and the grading rubric.

I’m glad Dr Arif found a process that worked for him, though if I try to engineer this process for myself I would try to avoid OCR as much as possible and try to keep artifacts digital as much as possible.

Parallel Session: Process Telemetry in Learning – Dr. Ho Jia Xuan

Jump to session summary

This was extremely fascinating! I notice parallels with students who struggle in the process of programming.

Many students attempt to write code linearly, that is, from top to bottom, left to right, one line at a time. But in my experience, experienced programmers tend to write code inside-out: they figure out the smallest step that needs to be carried out, then wrap it in a loop if it needs to be repeated, in a function if it needs to be reused, and so on. The process is more iterative and non-linear.

Having a tool to measure and visualise process telemetry could help me more easily identify students who are stuggling with this. In the classroom I can only see a snapshot of the student’s code at any point in time, and seldom the process they took to get there.

Day 2: Learning With AI (AI in Context – Applications Across Fields)

Opening Keynote 3: Prof. Miao Chunyan – Four Types of Agentic AI in Learning

Jump to session summary

Teachable AI is such an interesting idea! It’s difficult for a teacher to roleplay a learner, mainly because children and teenagers are not easily fooled and they know when you are withholding an answer. So we mainly role-model curiosity, which is still different from teaching; the student is still relying on you (as teacher) to make intelligent guesses about what they’re trying to convey, rather than being motivated to express ideas clearly (by trying to create coherence in their own model).

Hence, teachable AI: an AI that takes the role of student. AI agents are pretty good at role modelling. But the base models that most AI agents use have been trained on a large dataset that would likely include information that they are “not supposed to know”. The agents can roleplay ignorance, but cannot escape the possibility of prompt injection or accidental info leak in conversation. Would it be possible to train models with just the baseline information and world model of a “true” learner? Even a whole collection/community of models? That would make for a really interesting large-scale experiment.

Keynote 4: Prof. Mutlu Cukurova – Teacher-AI Teaming and Cognitive Atrophy

Jump to session summary

Very valid concerns raised by Prof. Mutlu. I’ve heard similar concerns about cognitive decline (from AI replacement) from the software engineering industry which is one of the first to adopt AI. Other industries will unfortunately likely have to learn their own lessons from experience.

Designing for augmentation, however, is challenging: both the user and the AI will have to share a common (work)space where the work is done. I don’t see much research being done in this area; the little I’ve read raises Joint Cognitive Systems as a model for this. My connection, Cedric Chin of CommonCog, recently hosted a podcast with Lia Dibello and Neil Sahota on Human-AI Symbiosis, where they discuss what it looks like for both AI and humans to learn together (about the work to be done).

I know intuitively what augmentation does not look like though: prompt engineering. Alas, this is where the bulk of the leading edge for non-technical folks is at, and it is what many AI training courses are trying to push me towards. Prompt engineering is what you do when AI does not have the context you have. This is at best amplification, at worst replacement: you copy-paste content into the AI, give it carefully worded instructions, it does the work.

More on this in my thoughts on Prof. Pratschke’s keynote.

Panel Discussion 2: Asst. Prof. Tanmay Sinha (Chair), Dr. Yang Yang, Dr. Aishah Abdul Rahman, Dr. Lee Vwen Yen Alwyn – Emotions in Learning

Jump to session summary

This is probably the first session with the most takeaway for me. While we did cover this briefly in my post-graduate diploma programme, the session provided a richer taxonomy of aspects of socio-emotional learning and the emotional aspect of learning: what does learning feel like for learners?

For a teacher the effect of emotions that students bring into learning is undeniable, and the use of AI in education cannot be naive to this. This naivety is one of the huge pitfalls of any educational chatbot at present. The application of emotions in learning goes beyond the chatbot’s prompting, I think it has to be present even when designing the UX of learning—the learning experience. This was already true even without using AI.

Parallel Session T2d: Dr. Ricky Chua – Performative Assessment and the SAMR Model

Jump to session summary

I’ve always believed that presentations should be carried out without a physical script, so Dr Chua’s idea resonated a lot with me. And it makes sense that this is hard to fake with AI.

In evolutionary biology, the concept of honest signals is quite different from everyday usage of the word “honest”. Whereas we use “honest” to communicate intent i.e. lacking intention to deceive, an honest signal is a signal that reliably communicates information. A healthy peacock tail reliably conveys that the peacock is fit enough to escape predators and healthy enough to produce beautiful plumage; A stotting gazelle demonstrates an excess of fitness and ability.

The question then, is: how do we define and assess honest signals? A take-home assignment could be easily ghost-written or AI-generated, while a live examination with plenty of prep time might encourage over-training / “memorising to the task”. A live presentation might bias students who are more accustomed to “winging it” and spontaneous *ahem* “expression on the spot”. We probably will need a range of these assessments. I hesitate to call this a “holistic” model but can’t think of a better term.

Parallel Session T2d: Assoc. Prof. Lisa Winstanley – AI in Art and Design Education

Jump to session summary

This session introduced some ethical issues in art and design, with a focus on AI and how it was trained, but didn’t really go into enough depth that I could say I learned something new. Fortunately the post-session panel discussion among the presenters was more engaging, and raised a good point about not being overzealous in forcing AI on students. They should have the option to say no, maintaining their agency and autonomy over how and when they would like to use AI.

Day 3: Learning Beyond AI (Knowledge Building and Assessment, Responsible Use, Ethics and Bias)

Keynote 5: Prof. Mairéad Pratschke – The New Context: The Pedagogical Imperative in the Shift from AI Tools to Systems

Jump to session summary

Prof. Pratschke attempted to introduce many concepts around AI use in a short time, making this session pretty overwhelming, but also one of the few sessions that sparked a lot of resonance.

AI presence—the way AI is presented to the user—is essentially the concept of affordances in design theory, which is also covered in the module on ICT in the postgraduate diploma programme I took over ten years ago. Affordances are the perceived and actual properties of an object that determine how it could possibly be used. A button affords pushing, a handle affords pulling, a chatbot affords conversation, an avatar affords representation, an agent affords acting on one’s behalf, a tutor affords teaching, and a digital human affords companionship.

The design implication is that form should match function and align with learning theory. A chatbot gives the impression that one is having a conversation; it encourages interactions and questions but also invites rebellion and pushing of boundaries, as teachers are aware students are wont to do. Is it always the most appropriate interface for learning? Even chain-of-thought reasoning, which some chatbots present to the user, can be misleading; different people/agents can arrive at the same conclusion through different reasoning paths, and the reasoning cannot be judged solely by its surface form (surely we have learned this from decades of multiple-choice questions, right?).

We need to be more deliberate in choosing the right AI presence for the learning activity.

The memory paradox had me nodding vigorously in agreement (in my head, so as not to disturb the session). Teaching is not merely transmission of knowledge; teachers who believe this tend to ask “if students can google/chatGPT this, why do we still need to teach it?” Even in the teaching syllabus we get, we can tell that some topics were not designed with procedural knowledge in mind: these topics tend to be presented as bullet points of facts students need to “understand”, which in practice ends up being memorization of declarative knowledge. Procedural knowledge requires practice—of what? What are the skills students need to demonstrate? Without clarity on this, we cannot design learning activities that build procedural knowledge.

Context engineering is a very handy term for what I have been trying to conceptualize for EdTech: a common (probably digital) space, not just a digital repository of learning materials. This space is where students co-create learning through interaction and collaboration, with teachers curating topic-appropriate material and facilitating discussions, while AI/edtech helps to maintain the space and environment and keep it conducive to learning.

Keynote 6: Prof. Phillip Dawson – Assessment Design for the AI Era

Jump to session summary

Prof. Dawson’s keynote did not introduce anything truly groundbreaking or surprising, which was exactly what I expected. There is very little that is truly novel in assessment design; what is surprising is when a school has the courage to actually implement these well-known principles.

So this session served more as an alignment check for what panelists and audience agree on: the need to teach learners when and how to use AI, to have multiple modes and formats of assessment (“swiss cheese” approach), to assess process not just product, to provide opportunities for collaboration (human-human and human-AI), and to apply security measures only at key milestones.

No disagreement there, only questions on how to make it happen in our social and institutional context. How would we design structural assessment that includes both AI-enhanced and non-AI-enhanced components? How do we train teachers to design assessments that truly assess learning, not just compliance with AI policies?

Panel Discussion 3: Prof. Mairéad Pratschke, Prof. Phillip Dawson, Mdm Lee Lin Yee (MOE), Mr Jason See (MOE); Chair: Assoc. Prof. Teo Tang Wee

Jump to session summary

The discussion raised many questions, not all of them that interesting I reluctantly admit. I found myself noding to Mdm Lee’s description of encouraging schools to “fail fast, fail forward” although I’m seeing how it is not really translating well on the ground yet. Lack of clarity around what “experimentation” means or looks like, leads to teachers being unsure of the difference between experimentation and failure, leads to … less / no experimentation. Teachers are aware that students have noticed some lecturers/educators using ChatGPT to answer questions, and frown on the practice; we tend to be wary of using AI in the classroom, in ways that sometimes hampers the experimentation mindset.

Mr. Jason See’s description of policy and technology as “seatbelts” was a good metaphor, but didn’t land for me; the current policies feel more like a wheel chock than a seatbelt, providing stability but limiting exploration rather than enabling safe movement.

By exploration I don’t mean “use ChatGPT, Perplexity, Gemini, Bard, Claude, etc” but figuring out ways to integrate context into AI tools. Understandably there are data governance concerns, but SLS as the only solution to concerns of data privacy is not sufficient if we want schools to truly experiment.

I think Prof. Pratschke was most spot-on when she somewhat obliquely mentioned that context and infrastructure determine what we can and cannot do. (On hindsight, I wonder if she intended this as commentary on the discussion?)

Parallel Session: Empowering Students in the AI Age—Prof. Venky Shankararaman, Vice Provost (Education), Singapore Management University

Jump to session summary

Sound principles; I like his way of encouraging AI adoption by making it difficult to accuse students of AI use. This process is often also unfair to students; there are many valid ways of using AI which to learners might not be considered cheating. But teachers are often reluctant to admit this potential misuse of the asymmetry of power. I think there is much to support this intention to add more “UX friction” to the plagiarism accusation process.

I don’t have much comment on the rest of it because it remains to be seen how well they are operationalized.

Parallel Session: Systemic Framework for Assessment & Curriculum Design—Dr. Ho Shen Yong, Executive Director of InsPIRE, NTU

Jump to session summary

I like the 2×2 framework, that was a really neat way to simplify decisions and check assessment coverage.

I am also in agreement that “critical thinking”, as a field in itself, is nebulous; each field has its own lenses, heuristics, and protocols for critical thinking. Attempting to teach critical thinking qua Critical Thinking, a cross-disciplinary skill, is likely to fail unless it can assume that learners have sufficient depth and domain knowledge in one or more areas.

Parallel Session (Science of Learning Research Showcase): NIE Team – Digital Portfolio Implementation and AI Reflection Assistant

Jump to session summary

No comment on this; it seems sensible, I have yet to meet begining teachers who have experienced this digital portfolio system (and so have no second-hand experience to share), and have not used this portal myself. It does seem like a useful tool for self-reflection and I may try it with my student leaders in a couple years’ time (because we don’t have that infrastructure in place yet).

Symposium: Dr. Lydia Cao (Chair), Assoc. Prof. Bodong Chen, Dr. Teo Chew Lee, Dr. Katherine Yuan – Knowledge Building with AI

Jump to session summary

This was a very interesting session, and way out of my depth and circle of experience. Knowledge-building sounds like a powerful pedagogy, if one is in an educational context set up for it, and we in Singapore are not.

I do appreciate the similarities between Knowledge Building and what I am conceptualising for constructivist learning environments in EdTech: both emphasise learner agency, co-creation of knowledge, and collective advancement of understanding.

Closing Keynote: Prof. David Hung & Assoc. Prof. Tan Seng Chee – Learning vs. Performance Augmentation

Jump to session summary

This closely mirrored what had been mentioned earlier, particularly by Prof. Cukurova and Prof. Dawson. The main highlight was a distinction between AI for productivity (performance) and AI for learning (learning), which I think is a useful framing for educators to consider when deciding how to integrate AI into their teaching practice.

Professionals in most other fields are looking for productivity gains; educators should be looking for learning gains. The affordances required from AI tools in each case are different, and the design principles for integrating AI into learning activities should reflect this difference.

[End of Part 2]

Part 3: My view on EdTech and AI in the next five years

It took me a few days to synthesize my thoughts and ideas on a way forward after the conference.

For context, I teach H2 Computing in a junior college in Singapore. Our students go through a two-year pre-university programme that prepares them for studies in an undergraduate degree programme, and culminating in the General Certificate of Education, Advanced Level (GCE A-Level) examination. Our teaching curriculum covers programming in Python (up to object-oriented programming), data structures and algorithms, databases, networks, and web programming.

In addition to that I also started a computing talent development programme this year, gathering students to conceptualize applications and services for the college by applying design thinking principles and software development practices.

EdTech Masterplan 2030

To begin this review with some context, the Ministry of Education unveiled its EdTech Masterplan 2030. Not explicitly mentioned is a strong push towards AI integration in education. However this was formulated, in staff meetings this year, I felt it as a strong directive to adopt generative AI (genAI) tools in teaching and learning, but with little actionable guidance around how to do so, and why.

The masterplan mentions 3 key enablers needed to enable implementation:

• Key enabler 1: Learning analytics and data
• Key enabler 2: EdTech infrastructure and solutions to support school processes and meet rapidly changing needs
• Key enabler 3: EdTech ecosystem

I’ve seen all three play out on Student Learning Space (SLS), the national learning platform for Singapore schools. Its primary focus appears to be delivery of micro-lesson units for primary and seconday schools, with some AI features such as a feedback bot that provides feedback on simple responses. From my exploration so far, its suitability for higher education (junior college level and above) appears limited. Thats fair; pre-tertiary students make up the minority of the student population, and given their age and maturity are expected to manage their own learning somewhat more successfully. Understandably, they are not the most urgent user group to tackle.

Nonetheless, if we are expected to adopt genAI tools in our teaching practice, these three enablers need to be in place to support us as well. It is through the lens of these three enablers that I will review the conference sessions I attended.

Learning analytics and data

The learning analytics and data currently available through SLS primarily focuses on tracking student progress through lesson units, and response accuracy. In AIFE 2025, I saw many presentations exploring other forms of learning analytics, with many presenters recognising their limitations.

Dr Ho is exploring process telemetry: looking at number of edits, rate of edits, pause times and duration, and other process-oriented metrics to better understand student learning not just as an outcome but as a process. Dr Arif is exploring automation that can connect student feedback and improvement across linked lesson units; has this student improved on or addressed shortcomings from the previous assignment?

This level of telemetry and cross-assignment tracking enables more sophisticated analyses of the kind that usually requires an attentive teacher who has noticed that Bobby has been staring at the screen without typing for the past 5 minutes, or Tim has been going over the same paragraph multiple times without meaningful changes, or Sarah has been repeating the same mistake across 3 assignments. It can detect confusion or anxiety as it happens / if it happened, regardless of the polish in the final product, and thus unlocks the possibility of real-time interventions, or a discussion on the socio-emotional experience the student underwent.

Ironically enough, telemetry and cross-site tracking are jargon that were introduced in online advertising when it took off in the early 2000s; the engagement farming industry takes user engagement so seriously that they have jargon for discussing what their online tools do in online advertisements and social media apps. ChatGPT could give you the low-down on what these terms mean, how to measure them, and how to optimise for them; the closest equivalent it could give me for the education sector is “learning analytics” or “learner trajectory” (I had to ask ChatGPT because I don’t recall coming across any equivalent term in all my years of teaching). You would, I hope, agree that these terms do not have the same level of precision.

That’s the crude understanding and low model fidelity readily available in today’s widely available AI models. It’s easy to understand why: these processes have been carried out intuitively and subconsciously by the best teachers, with little need to explain it to this level of detail. We don’t need to explain in such detail because we primarily train other human teachers whom we can expect to share the same intuitions. The advertising industry had to conceptualise, define, and then jargonise these terms only because they now need to be codified into advertising and engagement models; I suspect the education sector will soon have its moment when it needs to “explain to AI” how teaching happens. And it will need to do so to develop similar capability for education.

I can already give this kind of meaningful, engaging feedback for 1–3 students in a small group setting. To do it for a class of 20 I need these attention-scaling tools.

EdTech infrastructure and solutions

On the lack of teaching and learning tools

The “strong directive to use genAI tools in teaching and learning” I mentioned earlier manifests on the ground as frequent, strong reminders to explore the use of genAI tools in lesson planning, classroom activities, and assessments, but with little explanation of why or how. In practice that looks a lot like:

A: “Have you tried using ChatGPT to generate some quiz questions for your next lesson?”
B: “Yes, I uploaded some past year papers and prompted it to generate questions for <topic>.”
A: “You uploaded what?”

or

A: “Have you tried using ChatGPT to improve student feedback?”
B: “Yes, I copy-paste their answers into ChatGPT and ask it to give feedback, and sometimes I also tell it more about the student so it gives more sensitive and empathetic feedback.”
A: “You told it what about the student?”

While we are still undergoing trial periods with (limited versions of) Copilot and Gemini, which experientially feel like using ChatGPT with the same amount of copy-pasting involved, there are few other platforms or tools being offered to educators to meaningfully integrate genAI into their teaching practice. If I talk to 5 other educators, I hear about 5 different genAI tools being trialled; three different AI voice generators, two different AI video generators, five different summarizers, and even more custom chatbot platforms.

Everyone is hunting, not for the best tool or even the right tool, but mainly for a free tool; with any luck this tool remains free for the next 1–2 years before they sink and we scramble for another free tool—raising serious data governance questions each time—or the company finds product-market fit and starts monetising, forcing us to migrate again with the same unresolved data concerns.

On the lack of infrastructure

For our daily drivers we’re stuck with Pair Chat, a government-provided, Claude-powered, second-wave chatbot, and whatever AI features get integrated into SLS over time, as the only officially-sanctioned platforms for anything involving potentially sensitive student data.

These are individual solutions, rather than integrated infrastructure. Infrastructure would be a platform that allows educators to plug in different genAI models or tools as they see fit, and tools for building genAI-powered applications beyond chatbots and prompt pasting. This usually looks like an API in early stages, and a marketplace/plugin registry in later stages. Most importantly, a robust data governance framework with accompanying tools for handling student data securely and ethically, such as data anonymisation, consent management, and audit trails. Without these, educators get laden with more checklists and cognitive load about what data can be used where, and whatever productivity gains we get are squandered away doing compliance work manually.

At the talks I attended, I hear educators using existing models, but not platforms. They have had to develop their own solutions, and they see infrastructure as the next question mark they have to tackle. Prof. Peter Johnson (Imperial College London) came to present Lambda Feedback, a platform for connecting AI micro-services to quiz platforms, and look for collaborators to work on a common API schema for the microservice, because one doesn’t exist yet.

We cannot rely solely on vendors or the EdTech industry to build these for us. We need to take an active role in building or co-developing them, because we know our needs best.

On the purpose of EdTech

I am told that the adoption of genAI is primarily focused on improving teaching and learning (TnL), less on improving productivity for administrative tasks. I suppose the idea here is that rather than directly reducing teacher workload, genAI is expected to enhance the quality of TnL activities.

Unfortunately, this puts the cart before the horse. Context management is administrative workload: collating assessment results and feedback, assigning and closing quizzes, tracking student progress, managing learning resources, and so on. How does a TnL tool work without this context? How does AI analyze student results without those results being copy-pasted or uploaded to it in the first place? How does AI generate personalised learning paths without knowing what the student has done so far? How does AI create lesson materials without knowing the curriculum and learning objectives?

Perhaps when upper management visits an AI-enhanced classroom and sees students engaging with AI chatbots, collaborating with each other through AI-mediated discussions, and receiving AI-generated feedback on their work, that’s the vision burned into their minds: This! We want more of this!

There’s a lot of behind-the-scenes work that needs to be done for this to happen. That work is largely administrative work. To see more of the former, you’ll need to invest in reducing the latter, making it easier or faster to do, or better yet, outright reconceptualise how data and context are managed so that it might not even be necessary to do that work.

EdTech ecosystem

Locally, the EdTech ecosystem is still nascent. There are few local EdTech startups, and even fewer focusing on AI in education. As interesting as some of these educational platforms and tools are, they often do not align with local educational goals, curricula, or cultural norms; researchers cannot afford hosting these solutions for local schools, schools often don’t have enough funding to pay for a vendor to implement these solutions, and even when they do, the solutions are often existing products with some adaptation. Without startups or local companies building solutions from the ground up for local needs, the ecosystem remains fragmented and underdeveloped.

Currently, we face a choice between building everything in-house or adopting overseas solutions that may not align with local needs. The middle ground—co-developing contextually relevant solutions—remains underdeveloped.

This is not to complain that nothing is being done. Excellent work is being done to build some sorely needed tools; I particularly enjoy and am inspired by Chan Kuang Wen’s extensive work building semantic search and mentoring students working in this area. But when I ask myself where I see EdTech in the next 5 years … I think it’s got to be more than a smarter search box, another chatbot with customisable prompts, or a more contextually aware quiz generator or feedback bot.

I think the EdTech folks working on these individual pieces should continue doing that, but I don’t think that is where I will best contribute. I want to spend the next five years working on the infrastructure that connects all these pieces together.

As Prof. Pratschke put it, we need to move on from prompt engineering to context engineering. If we’re not careful, instead of maggot therapy that eats away the non-human parts, we might end up with Frankenstein’s monster, a patchwork of disconnected AI tools that don’t quite work with each other, leaving the human to do the inhuman gluework of copy-pasting prompts, downloading and uploading documents, and sieving out personal data manually.

EdTech and AI in the next 5 years

Prof. Peter Johnson of ICL is trying to collaborate on AI microservices; Dr Ho Jia Xuan is experimenting with telemetry tools for writing; more than a number of names are working on context-aware bots. We need more of these efforts, ideas, and projects; AI for learning and AI for production have different goals and therefore needs. In 10 minutes, I came up with some missing pieces:

• UI components for building AI-infused apps
• SDKs for data handling and model selection
• Specs and schemas for data exchange and interoperability
• Evaluation and test suites for AI learning tools

The last and, in my opinion, most important piece is the platform: I can’t yet imagine what a universal learning platform would look like, but I can imagine and ideate what might work for my college.

More importantly, I need to pull together a team interested to explore, build, and test this platform; this work cannot and should not be done alone. If, as Dr Pratschke puts it, “AI in learning is all about context, context, context”, then something needs to be managing that context, and a cohesive context manager is going to end up being a platform for all of the above.

It turns out Manjaro ARM has official Raspberry Pi 5 support, and since Manjaro is based on Arch Linux, I decided to give that a try instead, through the official manjaro-arm-installer.

The rest of this post are my notes on the process.

Installation

[Timestamp: 2025-10-21]

Using the steps from Installing and using from gitlab:

git clone https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-installer
cd manjaro-arm-installer
chmod +x manjaro-arm-installer
sudo bash ./manjaro-arm-installer (Use Default stable branch)

1. Pick rpi4 as the device (Raspberry Pi 5 uses the same image as Pi 4)
2. Pick your Manjaro edition (I picked minimal since this is for a server that I’ll SSH into)
3. Pick your username and additional groups (default: wheel,sys,audio,input,video,storage,lp,network,users,power)
4. Enter full name
5. Set user password and root password
6. (Insert the device before this step! There is no refresh button, so you’ll have to restart the installer if you insert the device later)
7. Pick your SD card device
8. Pick your filesystem (I picked ext4)
9. Choose your locale
10. Choose your keyboard layout
11. Enter desired hostname

Take a picture of your config before you click Yes.

==> Proceeding....
  -> Getting package lists ready for rpi4 minimal edition...
==> Getting <device> ready with ext4 for rpi4...
==> Creating install for rpi4...
  -> Used device is /dev/sda
  -> Downloading latest aarch64 rootfs...
Manjaro-ARM-aarch64-latest.tar.gz   100%[=============>] 201.71M  9.62MB/s in 22s     
  -> Extracting aarch64 rootfs...
  -> Setting up keyrings...
  -> Waiting for pacman gnupg to settle...
  -> Populating pacman gnupg...
  -> Setting target branch arm-stable...
  -> Generating mirrorlist...
  -> Installing packages for minimal on rpi4...
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
warning: systemd-libs-255.3-1 is up to date -- reinstalling
:: Starting full system upgrade...
resolving dependencies...

... package installation filler ...

... system setup logs ...

archlinux-keyring setup took a long time

• archlinux.gpg adding keys
• signing trusted keys locally
• disabling revoked keys
• updating trust database

all the while, gpg kept warning about insecure memory.

You probably want to go do something else for the next 30-45 minutes while this is happening. I was installing to a microSD card via a USB reader, it might be faster with an SSD or faster disk over USB 3.

  -> Setting up system settings...
<scary message in red>
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
</scary message>
...
===> Installing default ext4 RPi cmdline.txt /boot...
===> Installing default /boot/config.txt file...
  -> If you get an error stating 'failed to preserve ownership ... Operation not permitted', it's expected, since the boot partition is FAT32 and does not support ownership permissions...
==> Time : 18.92 minutes...

Finally it’s done. I could swear it felt longer than 19 minutes.

Time to see if it boots.

First boot and system setup

While the disk was intended for use in a Raspberry Pi 5, I happened to have a Raspberry Pi 500 (bundled with keyboard), which made booting easier since I didn’t have to plug in a monitor as well.

Manjaro Linux 6.6.33--2-MANJARO-RPI5 (tty1)

little-pi login:

Sweet.

[Timestamp: 2025-11-21]

… one long month later …

Manjaro Linux 6.6.33--2-MANJARO-RPI5 (tty1)

little-pi login: rpi
Password:

Welcome to Manjaro ARM
""Website: https://manjaro.org""
""Forum: https://forum.manjaro.org/c/arm""
""Matrix: manjaro-arm-public:matrix.org""
Last login: Fri Jan 26 09:01:55 on tty1
[rpi@little-pi]$

Clearly some setup is needed.

My home router isn’t easily accessible and I haven’t configured wifi on the raspberry pi image yet; perhaps a hasty oversight. Nevertheless, the Raspberry Pi is now booted and offline, and there aren’t many options for connecting to a WPA network, so I’m using wpa_supplicant here.

[rpi@little-pi]$ sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

/etc/wpa_supplicant/wpa_supplicant.conf

ctrl_interface=/run/wpa_supplicant
update_config=1

[rpi@little-pi]$ sudo wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf
Successfully initialized wpa_supplicant
...

[rpi@little-pi]$ sudo wpa_cli
wpa_cli v2.10
...

Selected interface 'wlan0'

Interactive mode

> add_network
0
<3>CTRL-EVENT-NETWORK-ADDED 0
> set_network 0 ssid "Your_SSID"
OK
> set_network 0 psk "Your_PASSWORD"
OK
> enable_network 0
OK
<3>CTRL-EVENT-SCAN-STARTED
<3>CTRL-EVENT-SCAN-RESULTS
<3>WPS-AP-AVAILABLE
<3>Trying to associate with SSID 'Your_SSID'
<3>Associated with xx:xx:xx:xx:xx:xx
<3>CTRL-EVENT-CONNECTED - Connection to xx:xx:xx:xx:xx:xx completed [id=0 id_str=]
<3>CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
> save_config
OK
> quit

Now I need an IP address: https://wiki.archlinux.org/title/Network_configuration#Network_management

[rpi@little-pi]$ sudo dhcpcd wlan0
sending commands to dhcpcd process

Finally, time to update packages:

[rpi@little-pi]$ sudo pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
:: Starting full system upgrade...
 there is nothing to do

Hmm. Fine then. Let’s install an AUR helper to make life easier:

[rpi@little-pi]$ sudo pacman -S --needed base-devel git
resolving dependencies...
looking for conflicting packages...

Packages (23) autoconf-2.72-1  automake-1.16.5-1  bison-3.8.2-1  debugedit-5.0-5
              fakeroot-1.33-2  flex-2.6.4-5  gc-8.2.6-1  gcc-12.1.0-2.1
              guile-3.0.9-1  libisl-0.26-1  libmpc-1.3.1-1  libtool-2.4.7-2
              m4-1.4.19-3  make-4.4.1-2  patch-2.7.6-10  perl-error-0.17029-5
              perl-mailtools-2.21-7  perl-timedate-2.33-5  pkgconf-2.1.0-2
              texinfo-7.1-2  which-2.21-6  base-devel-1-1  git-2.44.0-1

Total Download Size:    53.25 MiB
Total Installed Size:  266.90 MiB

:: Proceed with installation? [Y/n]
:: Retrieving packages...
...

[rpi@little-pi]$ git clone https://aur.archlinux.org/yay.git
[rpi@little-pi]$ cd yay
[rpi@little-pi]$ makepkg -si
==> Making package: yay 12.5.2-2 (Fri 21 Nov 2025 09:56:28 PM +08)
==> Checking runtime dependencies...
==> Installing missing dependencies...
error: target not found: pacman>6.1

Hmm, base-devel only provides pacman 6.0.2-2. Apparently the reason it’s so old is because Manjaro ARM on the arm-stable mirrors hasn’t been updated in quite a while. I switched to arm-unstable:

[rpi@little-pi]$ sudo pacman-mirrors -aS unstable
::INFO Branch in config is changed
::INFO Downloading mirrors from Manjaro
::INFO => Mirror pool: https://repo.manjaro.org/mirrors.json
::INFO => Mirror status: https://repo.manjaro.org/mirrorstatus.json
::INFO Using default mirror file
::INFO Querying mirrors - This may take some time

... many minutes later ...

::INFO Mirror list generated and saved to /etc/pacman.d/mirrorlist

This added a whole list of mirrors to /etc/pacman.d/mirrorlist. I only want the fastest ones.

From https://wiki.manjaro.org/index.php?title=Pacman-mirrors:

[rpi@little-pi]$ sudo pacman-mirrors --fasttrack && sudo pacman -Syu
::INFO Downloading mirrors from Manjaro
::INFO => Mirror pool: https://repo.manjaro.org/mirrors.json
::INFO => Mirror status: https://repo.manjaro.org/mirrorstatus.json
::INFO Using default mirror file
::INFO Querying mirrors - This may take some time

... many minutes later ...

::INFO Mirror list generated and saved to /etc/pacman.d/mirrorlist
: : Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
:: Some packages should be upgraded first...
::Resolving dependencies...
::Looking for conflicting packages...

Packages (2)  archlinux-keyring-20250807.1-1  archlinuxarm-keyring-20240419-1

... many updates/upgrades and some package conflict resolving later ...

... handling pacnew and pacsave files from the upgrade ...

We finally have pacman-7.0. Back to installing yay:

[rpi@little-pi]$ makepkg -si
==> Making package: yay 12.5.2-2 (Fri 21 Nov 2025 09:56:28 PM +08)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Downloading yay-12.5.2.tar.gz...
  ...

==> Installing package yay with pacman -U ...
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) yay-12.5.2-2

Total Installed Size:  8.70 MiB

:: Proceed with installation? [Y/n]
...

Done. Let’s make sure we didn’t break anything; quick reboot first:

[rpi@little-pi]$ sudo reboot

Troubleshooting wifi

… Phew. But, wifi didn’t connect. I configured wpa_supplicant earlier but not DHCP client to run on boot. I usually configure with NetworkManager, but since this is a server setup I’m going to ask ChatGPT.

Some back-and-forth later, I uninstalled iwd which was fighting for the wifi, and have a /etc/systemd/network/20-wlan0.network file:

[Match]
Name=wlan0

[Network]
DHCP=yes

Still not connecting. ip link shows wlan0 is up. iw dev wlan0 link shows it’s not connected. wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf shows that authentication is timing out. ChatGPT found in a search that on Broadcom brcmfmac (especially BCM4345 / 43455), there are known issues around offloaded authentication (SWSUP) or WPA3/SAE handshake. The fix is to disable those offloads through modprobe by creating a modprove config file /etc/modprobe.d/brcmfmac.conf with the following content:

# Disable SWSUP + SAE to resolve wlan0 authentication failure
options brcmfmac roamoff=1 feature_disable=0x82000

Reboot again. Still not working.

From ChatGPT’s suggestion to dmesg | grep brcmfmac (searching for Broadcom-related messages), I saw:

brcmfmac mmc1:0001:1: loading /lib/firmware/6.12.41-1-MANJARO-RPI5/brcm/brcmfmac43455-sdio.raspberrypi,500.bin failed with error -20

It seems the drivers were being loaded from /lib/firmware/6.12.41-1-MANJARO-RPI5 which was … empty. Oops, somehow the system upgrade earlier had not installed linux-firmware for the RPi5?

Since I’m going to need to dig up a LAN cable, that’s it for today.

[Timestamp: 2025-11-22]

With a LAN cable, and searching pacman for the requisite packages again, it appears they are all installed: firmware-raspberrypi, linux-firmware, even linux-rpi5. Back to ChatGPT again. Apparently the above error message indicate that the kernel may be searching in a prefixed directory before searching in a fallback directory. It recommended dmesg | grep -i brcmfmac:

[rpi@little-pi]$ dmesg | grep -i brcmfmac
brcmfmac mmc1:0001:1: loading /lib/firmware/6.12.41-1-MANJARO-RPI5/brcm/brcmfmac43455-sdio.raspberrypi,500.bin failed with error -20
... other similar error -20 messages ...
usbcore: registered new interface driver brcmfmac
brcmfmac mmc1:0001:1: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2

So it was loaded after all. ChatGPT suggested checking the driver parameters:

[rpi@little-pi]$ ls /sys/module/brcmfmac/parameters/
alternative_fw_path  debug  roamoff
[rpi@little-pi]$ cat /sys/module/brcmfmac/parameters/roamoff
1

Odd, feature_disable is not listed. ChatGPT suggested the module might not support that parameter, but we can check:

[rpi@little-pi]$ modinfo brcmfmac | grep parm
... selected parameters shown here only ...
parm:    debug:Level of debug output (int)
parm:    feature_disable:Disable features (int)
parm:    roamoff:Do not use internal roaming engine (int)

Hmm, it does suppport. ChatGPT suggests it might not be exposed. Anyway, I don’t care if it’s supported I care about working wifi.

Back to checking link status:

[rpi@little-pi]$ ip link show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether b8:27:eb:xx:xx:xx brd ff:ff:ff:ff:ff:ff
[rpi@little-pi]$ iw dev wlan0 link
Connected to xx:xx:xx:xx:xx:xx (on wlan0)
  SSID: Your_SSID
  freq: 5180.0
  RX: 4346 bytes (32 packets)
  TX: 2854 bytes (24 packets)
  signal: -17 dBm
  rx bitrate: 6.0 MBit/s
  tx bitrate: 24.0 MBit/s
  bss flags: short-slot-time
  dtim period: 4
  beacon int: 200

Ooh, surprise, the fix worked! I don’t like setting parameters unnecessarily since it might complicate future issues, so let’s remove feature_disable=0x82000 from /etc/modprobe.d/brcmfmac.conf and reboot again. Nope, no connectivity. Put it back, reboot, and wifi is back. A very strange issue with the driver not exposing feature_disable and yet it is still needed.

Anyway, working Arch Linux on a Raspberry Pi 5! Next, to have wifi issues handled automatically; time to install NetworkManager. And not forgetting to disable wpa_supplicant to avoid wifi-fighting (NetworkManager already uses wpa_supplicant).

[rpi@little-pi]$ yay -S networkmanager
...
[rpi@little-pi]$ sudo systemctl enable NetworkManager
... 3 symlinks created ...
[rpi@little-pi]$ sudo systemctl disable wpa_supplicant.service
...
[rpi@little-pi]$ sudo systemctl disable wpa_supplicant@wlan0.service
...

Connect to wifi using NetworkManager so it can manage reconnections automatically:

[rpi@little-pi]$ nmcli device wifi connect "SSID" password "PASSWORD"
Device 'wlan0' successfully activated with 'xxxx-xxxx-xxxx-xxxx'.

Reboot: wifi still works 🙏

SSH

Next, to set up SSH so I can access the Pi headlessly. openssh is already installed so I’m skipping that.

[rpi@little-pi]$ sudo systemctl enable sshd
[rpi@little-pi]$ sudo systemctl start sshd

Basic security: disable root login and password authentication. Edit /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication yes

SSH authentication not set up here since I don’t plan to connect remotely yet.

Following other security recommendations from ChatGPT:

1. Install fail2ban to protect against brute-force attacks.

[rpi@little-pi]$ yay -S fail2ban
...
[rpi@little-pi]$ sudo systemctl enable fail2ban
Created symlink /etc/systemd/system/multi-user.target.wants/fail2ban.service → /usr/lib/systemd/system/fail2ban.service.
[rpi@little-pi]$ sudo systemctl start fail2ban

1. Set up a basic firewall using ufw (Uncomplicated Firewall).

[rpi@little-pi]$ yay -S ufw
...
[rpi@little-pi]$ sudo ufw allow 22/tcp
Rules updated
Rules updated (v6)
[rpi@little-pi]$ sudo ufw enable
Firewall is active and enabled on system startup

Now I can connect to the RPi through VSCode (after instaling the Remote - SSH extension) using the username and password set during installation.