AI Coding Agents in HBO-ICT: What Should Programmes Teach?

Separate tool operation, assisted engineering and foundations

Tool proficiency means operating a particular product or interface. That may be useful course material, but a product name is rarely a durable learning outcome.

AI-assisted engineering capability means using assistance within software-development work while still making, evaluating and verifying relevant technical decisions. Depending on the outcome, this may involve framing a bounded task, inspecting a proposed change, adapting it, debugging a failure or explaining a decision.

Foundational programming capability means understanding enough of software and the relevant concepts to reason about behavior, inspect and modify code, diagnose failure and verify a result. Foundations are not synonymous with memorizing syntax or doing all work manually; nor are they replaced by the ability to operate an agent.

These capabilities overlap. A student may use a tool while drawing on foundations to identify an unsuitable assumption, test a change or decide not to accept a suggestion. “Can use Copilot” names an interface. As an editorial example—not a prescribed HBO-ICT outcome—“can adapt an AI-assisted implementation to stated requirements, verify relevant behavior and explain material technical decisions” names work and judgment.

Review each learning outcome before adding content

For an existing outcome, ask whether AI materially changes how the professional activity is performed; which underlying knowledge students still need; whether AI-assisted performance is now part of the intended capability; whether the outcome’s wording should change; whether a genuinely new capability is missing; and whether any narrow manual activity receives more time than its educational purpose warrants.

Prompting is one way to interact with a tool, not a curriculum by itself. More durable concerns include framing the task, providing relevant context and constraints, recognizing missing information, steering an unsuitable approach, and checking whether a proposed result meets the requirement. The specific interface may change; the engineering question remains tied to the outcome.

When AI proposes or modifies work, students may need to compare behavior with requirements, inspect relevant changes, test negative or boundary cases, and determine what the tests do not establish. The expected depth depends on the outcome. A generated test is not automatically evidence that the requirement is satisfied.

Decide what to keep, update, add or de-emphasize

Keep an outcome when it still describes the capability the programme intends to develop. Update it when the capability remains relevant but AI changes the conditions or expected performance. Add an outcome only when a distinct capability is not adequately represented already.

De-emphasize should be considered cautiously. The fact that AI can perform a narrow manual activity does not by itself justify reducing it. A programme needs an educational rationale, and should preserve conceptual knowledge students need to reason, diagnose, adapt and verify. Do not remove an outcome simply because a tool can produce a plausible result.

Curriculum time is finite. Before adding separate units on agents, prompting, verification, governance or responsible use, ask whether the relevant capability can be taught within an existing software-engineering outcome. Add material where it has a clear purpose; do not treat every new product or topic as a new course requirement.

Place AI in the curriculum without a universal sequence

Students can learn about AI—its capabilities, limits, uncertainty and responsible use—and learn software development while AI is available as a tool. These are related but different curricular decisions. A dedicated module may provide shared concepts and focused practice; embedded work may connect AI to implementation, testing, debugging, review or maintenance. A programme may combine them. Available evidence does not establish one format as universally superior.

A 2026 randomized study in one TUM introductory programming course illustrates why task performance should not be treated as learning. It involved 275 CS1 students completing a roughly 90-minute concurrency exercise with scaffolded Iris assistance, unrestricted ChatGPT or a no-AI condition using web resources. The AI-supported groups performed better on the exercise, but measured knowledge gains and code comprehension did not increase correspondingly. This single task and course do not establish whether AI helps or harms learning generally, or when HBO-ICT programmes should introduce it. Bassner et al. (2026).

Constructed example: review a backend-development sequence

Constructed example — illustrative curriculum reasoning, not programme evidence, classroom research or TraceYield validation. A second-year backend sequence already includes outcomes for implementing API behavior, designing tests, debugging failures and explaining architecture. The programme reviews those outcomes rather than adding “use an AI coding agent” as a replacement outcome.

Keep: reasoning about API behavior and explaining architecture remain relevant. Update: an implementation outcome may allow permitted tools while requiring students to adapt the change to stated requirements and verify relevant behavior. Add, where the programme finds a real gap: an explicit capability to evaluate and correct an unsuitable AI-assisted change. Preserve unaided evidence where the outcome requires it: a selected diagnostic or foundational capability may still need to be demonstrated without AI. The example does not imply that every programme needs the same conditions.

No narrow manual detail is automatically de-emphasized in this example. If a team considers reducing time spent on one, it should explain why that activity’s educational purpose has changed and how students will still gain the conceptual understanding needed to work with the software. The point is not to replace programming with prompting, but to make each curriculum decision answer to an existing or clearly justified capability.

Use professional and educational evidence, not product hype

HBO-i’s 2023 domain description is a Dutch national framework for ICT higher-professional-education graduate qualifications and professional tasks. It covers activities such as analyzing, advising, designing from requirements, realizing and testing systems, and managing or optimizing their development and use. HBO-i reports that its 2023 update gave attention to AI, data, cloud, security and societal impact in exemplar tasks and descriptions. This supports reviewing how AI may change existing ICT activities; it does not define a new AI-developer domain or prescribe this article’s keep/update/add decisions. HBO-i Domain Description · HBO-i update notes.

Npuls’s AI-GO work offers Dutch post-secondary context for AI literacy and curriculum development, not a software-engineering competency standard or a mandatory model. Programme outcomes should draw on a considered mix of the professional profile, existing outcomes, student work and assessment observations, computing-education research, and relevant advisory input. One tool launch, survey, employer or classroom experiment is not enough on its own to justify programme-wide change. Npuls AI-GO.

Keep outcomes durable and boundaries clear

Learning outcomes can remain relatively durable while examples, tools, exercises and assessment conditions change more often. Describe the capability students should develop rather than make a current product the programme competence. Where AI use, evidence or task conditions need to be specified for a particular course, see assignment assessment; for teaching-practice implications, see the programming lecturer’s role.

TraceYield may help educators notice patterns in task framing, interactions, steering, decisions, corrections and verification where those events are captured. Such observations may inform curriculum review, but TraceYield does not define curriculum, determine which capabilities belong in a programme, measure competence automatically, establish learning effects, predict labour-market demand or grade students. Programme teams remain responsible for their curriculum decisions.