How Dutch HBO-ICT Programs Can Assess Programming in the Age of AI
How Dutch HBO-ICT programmes can move from isolated assignment rules to a coherent programme-level approach to AI-aware programming assessment.
TraceYield Insights
13 min read · Updated August 11, 2026
TraceYield
AI engineering evidence
How Dutch HBO-ICT Programs Can Assess Programming in the Age of AI
A programme cannot solve this with one assignment rule
An HBO-ICT student encounters programming across multiple courses, projects, practical assessments, internships, and a final project. If every course invents a different AI rule, students receive contradictory signals about what they are expected to learn and what they must disclose. A programme-level approach is needed because assessment validity is cumulative.
The question is not whether every assignment should permit the same tools. It is whether the assessment mix gives the programme credible evidence of the learning outcomes while preparing students for a professional environment in which AI-supported development is increasingly normal.
Define progression, not just permission
A first-year course may need controlled work that establishes programming concepts, debugging habits, and the ability to read code without an agent. Later project work can introduce broader AI use with explicit requirements for context, verification, security, and reflection. In a graduation project, the focus may shift toward professional judgment, architecture, documentation, and accountable tool use.
This creates a progression from learning the fundamentals, to using assistance critically, to applying tools responsibly in an authentic professional context. The progression should be visible in the curriculum and assessment plan rather than left to individual lecturers.
Design an assessment mix
A coherent programme may combine supervised work without AI, AI-permitted projects, oral explanation, practical debugging, portfolio evidence, code review, and workplace-oriented demonstrations. Each form answers a different question. A controlled task can show individual fluency; a project can show integration and professional judgment; an explanation can show understanding of a submitted artifact.
The mix should be based on learning outcomes and feasibility. Adding an oral defense to every assignment may be impossible at scale. Removing all unsupervised evidence may make it difficult to see whether students can reason without assistance. A balanced programme uses different forms for different purposes.
Create common language for permitted AI use
Students and lecturers need more than “AI allowed” or “AI forbidden”. Programme guidance can distinguish brainstorming, explanation, code generation, debugging, refactoring, testing, and agentic changes. It can state which uses require disclosure, which data may not be entered, and what verification is expected.
Consistency does not mean identical wording in every course. It means that a student can understand the programme’s principles as they move between modules. Examination boards and curriculum teams should own the common framework, while course teams adapt examples to their learning outcomes.
Build evidence over time
A student portfolio can connect small programming exercises, project milestones, reflections, code reviews, and demonstrations. Over time, the programme sees more than a succession of final repositories. It can see whether students increasingly frame problems clearly, question generated suggestions, verify behavior, and take responsibility for trade-offs.
This does not require continuous surveillance. Selected milestones and purposeful evidence are usually more defensible than collecting everything. The programme should be explicit about why evidence is collected, who can access it, and how long it is retained.
Give examination boards a usable framework
An examination board needs a basis for judging validity, reliability, feasibility, and fairness. A programme AI framework can document the intended learning outcomes, assessment forms, permitted AI range, disclosure expectations, evidence sources, moderation process, and response to suspected irregularities. It should also explain where human judgment remains essential.
Npuls frames AI-aware assessment as a broader institutional and educational question, including constructive alignment, ethical use, inclusion, and assessment competence. Applying that direction to HBO-ICT requires programme-specific decisions about code, projects, debugging, and professional practice; it should not be presented as a ready-made national rule.
A programme review cycle
Start by mapping where each programming learning outcome is assessed and what AI access each assessment permits. Identify gaps, duplicated evidence, and points where a final artifact is doing too much work. Pilot a small change, collect feedback from students and lecturers, moderate samples, and review whether the evidence became stronger without creating disproportionate workload.
The programme should expect to revise its approach. Tools change, professional practice changes, and evidence about learning develops. The durable principle is not a particular vendor rule; it is alignment between what the programme says students should learn and what its assessment can actually show.
Coordinate the programme map
A useful workshop puts the programme learning outcomes on one side and the assessment forms on the other. Mark where students demonstrate fundamentals without assistance, where they learn to supervise AI, where they show professional project work, and where process or explanation is currently absent. The gaps are often more informative than the policy debate.
The map should include internships and graduation work where possible. Students need a coherent progression from classroom exercises to professional practice, and supervisors need to understand what “responsible AI use” means in relation to the programme outcomes.
Avoid a programme-wide template
Consistency is not the same as forcing every course to use an identical portfolio, defense, or declaration. A programming fundamentals course and a software architecture project need different evidence. The programme should standardize principles, terminology, and minimum expectations while allowing course teams to choose appropriate forms.
That balance makes policy easier to explain and assessment more valid.
From rules to curriculum progression
A programme-level approach should describe how expectations change from the first programming course to project work and graduation. Early modules may emphasize reading code, tracing execution, and solving small problems under controlled conditions. Later modules can allow broader AI use while assessing architecture, integration, security, testing, and professional judgment.
Students should be able to see this progression. If one course treats any AI assistance as prohibited and the next expects students to supervise an agent, the programme should explain the educational reason for the difference. A coherent progression is more defensible than a collection of local rules that happen to conflict.
Work with examination boards and students
Programme teams should involve examination boards early because changes affect validity, reliability, feasibility, and the interpretation of learning outcomes. Student representatives can identify where instructions are ambiguous, where access is unequal, and where documentation demands are unreasonable. Workplace partners can help identify which AI-assisted capabilities matter professionally.
The goal is not to transfer the decision to any one stakeholder. It is to build a shared language before individual assignments are rewritten. That makes pilots easier to moderate and gives the programme a basis for revising its policy when evidence changes.
A realistic first programme change
A programme does not need to rewrite every assessment at once. It can select one first-year practical, one project, and one graduation milestone, then compare what each currently proves with what the programme wants to claim. Redesign those points as a connected progression and use the findings to guide the next cycle.
This staged approach gives examination boards and lecturers evidence about workload and validity before a large policy change is made.
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