Designing the Role of AI in Learning

When I first began designing my own courses in 2025, most of my attention went to questions that felt more immediate: what students should learn, what they should build, how assignments should progress, and what would make a project technically meaningful.

I settled on a structure that I still find useful for practice-based engineering courses. Assignments provide structured practice with foundational concepts and techniques. Projects serve a different purpose: students have more freedom to work in teams, make technical decisions, combine different parts of a system, and build something of their own.

AI was already part of how some students worked. They could use it to explain unfamiliar concepts, generate code, debug problems, or explore alternatives. But at first, I mostly treated this as a policy question layered on top of the course I had already designed.

By early 2026, that began to feel insufficient. The harder question was not simply what AI use I should allow. It was what work students still needed to experience themselves.

The question underneath the policy

The context matters. The courses I am thinking about are graduate-level, practice- and project-based engineering courses, with many students preparing for professional roles in industry. My goal is not to recreate a world in which powerful tools do not exist. Many students are likely to encounter AI tools in their professional work, and learning to use it thoughtfully is increasingly part of professional practice.

At the same time, there are parts of learning that cannot be reduced to producing a correct artifact. Writing code, getting stuck, debugging, making a design choice, discovering that an assumption was wrong, and figuring out what evidence would actually establish that something works can all be part of what the student is meant to learn.

Once I started thinking in those terms, “How much AI should students be allowed to use?” no longer seemed sufficient for the course-design decisions I was making.

The more useful question became: where should AI enter the learning process, and what should remain with the learner?

First think, then AI

The simplest expression of where I have landed is first think, then AI.

“First think” does not mean that students must finish a problem independently before they are allowed to ask AI for help. It means doing enough thinking to establish some ownership of the problem first.

What am I trying to accomplish? What do I already understand? What do I expect might work? Where am I uncertain? What question am I actually asking?

I want students to enter an AI interaction with some sense of what they already understand, what they are trying to accomplish, and where they are uncertain or need help.

From there, AI can explain, challenge, compare, generate, or help debug. The student is still responsible for deciding what to ask, what to accept, what to reject, and what needs further evidence.

At first, I was tempted to turn this into a single set of rules for AI use across the course. But as I began sharing an early version of the policy with colleagues teaching in different contexts, that started to seem too simple.

One colleague pointed out that AI-assisted brainstorming could have a place in the early stages of an open-ended project. Another described using much tighter limits on AI-generated code in introductory programming, where students are still building foundational mental models.

The contrast made sense because the learning goals were different. What became clearer to me was that “first think, then AI” could remain a common principle without becoming a uniform rule: its practical meaning should depend on what a particular learning activity is designed to develop.

Different learning goals, different roles for AI

This led me to give AI different roles in assignments and projects, because the two activities are meant to accomplish different things.

In assignments, much of the value lies in practicing relatively small pieces of technical work directly. Writing the code, encountering errors, navigating an unfamiliar API, and debugging the implementation may themselves be the point.

So for assignments, “first think, then AI” becomes something more specific:

Students should understand the task, make a genuine attempt at the implementation themselves, and use AI for specific questions or obstacles rather than delegating away the practice the assignment was designed to provide.

Projects are different. Their purpose is not to ensure that every line of a larger application was typed independently by a student. What matters more is whether a team can make coherent technical decisions, integrate components, respond to problems, evaluate trade-offs, and establish that the resulting system behaves as intended.

In that setting, AI can reasonably become a much more active part of the engineering process.

A team might begin with its own understanding of a problem, then use AI to explore architectures, technologies, implementation approaches, or possible explanations for a failure. But exploration is not the same thing as judgment. Someone still has to evaluate those possibilities, decide what belongs in the system, integrate the decision into a larger design, and verify the result.

This is not meant to be a rigid sequence. Real engineering work loops backward and forward constantly. What matters is that AI can support the process without replacing the student’s own technical judgment.

Where should we draw the boundary?

Another piece of feedback gave me a useful way to think about delegation. A colleague pointed out that choosing the granularity of a task to hand over to AI is itself an architectural decision: someone still has to decide how the problem should be divided, specify what each piece is supposed to do, and determine how to test whether it actually works.

That idea stayed with me because it shifted the question from simply “how much AI is too much?” to where the boundary between human and AI work should be drawn.

Asking AI to explain an error, implement a small function, or build an entire subsystem places that boundary at very different levels. The appropriate level depends not only on what AI is capable of doing, but also on what the student is meant to learn from the task.

A piece of work that students should perform themselves in an assignment may be perfectly reasonable to delegate within a larger project. But as the delegated pieces become larger, it also becomes harder to understand, integrate, and verify what AI has produced.

This is what makes granularity more than a question of permission. Deciding what to delegate, how to specify it, and how to know whether it works is itself part of the engineering work.

Delegation does not remove responsibility

Once larger pieces of work can be handed to AI, another question follows naturally: what is the learner responsible for afterward?

If AI helps explain a syntax error, confirming that the explanation makes sense may be enough. If it generates a substantial implementation, much more is required. A student should be able to understand how it works, determine whether it fits the surrounding system, test its behaviour, and identify important assumptions or failure modes.

This does not mean that large AI contributions are inherently bad. It means that delegation changes the nature of the human work.

As AI takes on more implementation, decomposition, specification, integration, evaluation, and verification become more important. The engineer may write less of a component directly while becoming more responsible for deciding what the component should do and what evidence is sufficient before trusting it.

Making judgment visible

If judgment is becoming more important, course design needs ways to make that judgment visible. That is especially challenging in courses with more than one hundred students.

At this scale, making judgment visible also has to be practical for both students and instructors. That has led me to look for lightweight ways to preserve evidence of the reasoning and technical decisions that matter for the learning goals, even when AI contributes to the implementation, without turning reflection on AI use into another substantial assignment.

In assignments, that currently means a short reasoning.md: some initial thinking before implementation and, where relevant, one meaningful example of how AI influenced the work.

In projects, teams record some of their initial reasoning early in the process and later reflect on a small number of representative AI interactions. Together, these provide a limited but useful view of how the team approached important decisions, where AI entered the process, and how its contributions were evaluated and verified.

What AI has made harder to ignore

I began this process thinking I needed a clearer policy for AI use. Over time, however, I have come to see that the more interesting question sits underneath the policy.

Every course makes choices about what students should practice themselves, where tools can reasonably assist, what they need to understand deeply, and what evidence is sufficient to show that learning has taken place.

Those choices existed before generative AI. AI simply makes them much harder to leave implicit.

In that sense, AI has become a useful lens for examining course design. It forces a more explicit question about where the educational value of an assignment or project actually comes from. Is it producing the artifact? Performing the implementation? Making the decisions? Working through the debugging process? Being able to evaluate and defend the result? Usually, the answer is some combination of these, but the combination matters.

My current policies are one attempt to make those choices explicit. I do not expect the details to stay fixed. AI systems will change, professional practice will change, and our understanding of what works in education will continue to evolve.

But the underlying design question may remain: