Teaching the Next Generation of Developers: An HBO-ICT Guide to AI
At universities of applied sciences, HBO-ICT teachers are preparing future developers for a profession where AI can produce working code before students understand the problem. What should educators protect?
TraceYield Insights
11 min read · Updated September 19, 2026
TraceYield
AI engineering evidence
Teaching the Next Generation of Developers: An HBO-ICT Guide to AI
The developers arriving in our teams are being educated now
We build software and use AI in that work ourselves. We also see how quickly the baseline is changing: a student can now reach plausible, working code before they have fully understood the problem, the architecture, or the trade-offs behind it.
That gives HBO-ICT lecturers and programming educators a difficult responsibility. They are preparing the next generation of developers for teams where AI will be normal — while still protecting the judgment that makes a developer accountable for the code.
A short conversation that stayed with us
We recently spoke with someone who had just completed HBO-ICT. Asked what they had used for the frontend, the answer was essentially: “Claude.” It was not a confession, and it was not a reason to dismiss AI. It was a very honest description of how quickly the tool can become the centre of the work.
The issue is not that students use Claude, Codex, Cursor, or another coding agent. We use these tools too. The issue begins when a student can accept a convincing result without being able to explain the problem it solves, the assumptions it makes, or the risk it introduces.
The educational question has changed
A final repository can still show good engineering: readable code, passing tests, a functioning interface. But it reveals less than it used to about how the student framed the task, evaluated alternatives, responded to an error, or decided that a result was safe enough to submit.
That is why guidance from Npuls and work on AI-resilient assessment both focus on assessment design, learning outcomes, and evidence — not merely on detecting a tool in the final artefact. Npuls’ vision on assessment, examination and AI is a useful Dutch starting point for that shift.
Two polished projects can represent very different learning
Imagine two students submitting similar applications. One asks an agent for a structure, accepts the first plausible implementation, and cannot explain why key choices were made. The other uses AI throughout but tests suggestions, rejects an unsuitable approach, reformulates the task after new evidence, and can defend the final trade-off.
The repositories may look equally polished. Educationally, they are not the same achievement. One student has delivered an artefact. The other has practised the work of being a developer: framing, judging, debugging, testing, and taking responsibility.
Why process evidence matters
The evidence does not have to be a complete prompt log or a record of every keystroke. A brief explanation of a changed approach, a selected debugging moment, a test that disproved an assumption, or a short code walkthrough can give a lecturer far more useful context than an AI-detector result.
The ACM Task Force report on programming assessment and research on AI-resilient assessment both support moving beyond a single final artefact. The evidence should be proportionate to the learning outcome and usable by both student and lecturer.
This is not a case for surveillance
TraceYield is not an AI detector, an independence score, or an automated grading system. A history of tool use cannot prove understanding on its own, and no lecturer needs a permanent transcript of every private interaction.
The aim is a small, reviewable view of meaningful moments: what the student tried, what changed, what they verified, and what they can explain. Process evidence should create a better academic conversation, not a new monitoring burden.
Where TraceYield fits
This is the problem we started building TraceYield around. At session level, it can make one AI-assisted working episode understandable. At project level, it connects related work. At student profile level, it can surface patterns across assignments for a human lecturer to interpret.
The product surfaces evidence and context; the lecturer remains responsible for the educational judgment. How TraceYield works and development trajectories explain that model in more detail.
What education should protect
Programming education does not need to protect every manual step for its own sake. It needs to protect the abilities students need when AI is wrong, unavailable, incomplete, or confidently misleading: framing a problem, reading code, testing behaviour, reasoning about architecture, noticing risk, and explaining a decision.
AI can be part of teaching those abilities. It can generate a flawed patch to review, a plausible explanation to challenge, or multiple approaches to compare. The crucial thing is that a fast answer never becomes a substitute for the student’s own understanding.
Agent completion does not always mean engineering completion.
References
Pilot Program
Understand the WHY behind your engineering AI usage.
TraceYield evaluates trajectory evidence instead of stopping at spend totals. Join the private pilot to review AI coding usage with engineering context, security controls, and developer trust.
Join the TraceYield private pilot