How to Assess AI-Assisted Programming Assignments in HBO-ICT
A practical HBO-ICT guide to aligning an AI-assisted programming assignment’s learning outcomes, task, AI conditions, evidence and assessment.
TraceYield Insights
9 min read · Updated October 6, 2026
Assignment design, made visible
- Learning outcomeWhat must students demonstrate?
- Task + activityWhat work elicits that performance?
- Permitted AI roleWhich assistance fits the outcome?
- Evidence + criteriaWhat is judged, and against what?
Review after the assignment runs: check clarity, relevance, fairness and workload before using it again.
A design aid from TraceYield’s editorial interpretation; not a validated framework or rubric.
Design the assignment around what students must demonstrate
Start with the learning outcome, then choose a task that gives students a fair opportunity to demonstrate it. Decide what role AI may play in this particular task, what the submitted artifact can show, and whether a selected process record, explanation or verification check adds evidence the outcome needs. These are assignment-design choices; they are not a requirement to collect every evidence type from every student.
External guidance supports outcome-aligned, fair and learning-focused assessment. Npuls’ vision discusses these principles across post-secondary education, while the ACM Task Force report gathers educator practices and examples for programming assessment. Conceptual work on AI-resilient assessment explores design responses but does not validate a TraceYield method. The alignment below is TraceYield’s practical interpretation for designing one programming assignment, not a validated rubric or universal standard.
An assignment-design matrix
Use each row to make a decision before writing the student brief. The evidence choice should follow the outcome: a final artifact may be enough for some outcomes; others may need one targeted explanation, process sample or verification task. This compact table is an editorial aid, not a new validated assessment model. Related work already exists: Ahangama’s ICT assessment-design paper presents the GENESIS model and an Assessment Design Matrix based on document analysis, with empirical validation identified as future work.
| Design question | Assignment decision |
|---|---|
| Learning outcome | What must the student demonstrate, in observable terms? |
| Task and context | What programming work will elicit that performance, under which constraints? |
| AI role | What AI use is allowed, restricted or expected for this task, and why? |
| Artifact | Which submitted code, tests, documentation or behavior is relevant? |
| Selected process evidence | What small, purposeful record adds information the artifact cannot provide? |
| Explanation or demonstration | Does the outcome require the student to explain, adapt or demonstrate anything? |
| Verification | Which test, inspection or check is relevant, and what is its scope? |
| Lecturer assessment | What will the lecturer judge against the outcome and stated criteria? |
Worked redesign: importing event registrations from CSV
Illustrative constructed example — not student data, classroom research or TraceYield pilot evidence. Consider an HBO-ICT assignment in which students add CSV import to an event-registration service. The task includes malformed rows, duplicate registrations, validation rules, useful error reporting and tests.
Underspecified starting point
Build an event-registration CSV import feature.
Why this brief leaves design decisions open
It does not say whether students are assessed on parsing, validation, error handling or testing; what AI help is permitted; what artifact or evidence to submit; how behavior should be verified; or what the lecturer will judge.
Aligned version
Learning outcome: implement and test input validation for a small service, and explain how the implementation handles invalid and duplicate records. Task: add CSV import to the supplied event-registration service. Reject rows with missing required fields or invalid email addresses; handle duplicate registrations according to the supplied rule; report row-level errors without silently dropping data. AI conditions: code explanation, test suggestions and generated code are permitted; students must review and adapt suggestions, must not enter personal or real registration data, and remain responsible for the submitted behavior. Submit the implementation, tests for valid, malformed and duplicate rows, plus a short note naming one AI contribution and one check performed. Be prepared to explain or adapt one validation rule. The lecturer assesses the stated outcome using the artifact, relevant tests and the targeted explanation; no single record automatically establishes independent authorship or competence.
Turn design decisions into clear student instructions
A student-facing excerpt can be short. It should remove guesswork about conditions and evidence without prescribing a single acceptable development path.
- Task
- Implement CSV import for the supplied event-registration service. Apply the published rules for required fields, valid email addresses, duplicate records and row-level error reporting.
- Learning objective
- Demonstrate that you can implement and test input validation for this service, and explain how your behavior follows the requirements.
- AI use
- You may use AI to discuss approaches, generate or revise code, and suggest tests. Review and adapt any output; do not use real personal registration data in prompts.
- Evidence
- Submit your implementation and relevant tests. Briefly identify one AI contribution and one change, rejection or check you made if applicable. No full conversation transcript is required.
- Verification
- Include tests for valid input, malformed rows and duplicate records. State any important behavior the tests do not cover.
- Explanation or follow-up
- In a short demonstration, explain one validation decision and adapt it if the stated rule changes. The lecturer will assess the learning objective using the submitted work and this targeted evidence.
Keep evidence feasible, fair and proportionate
Do not require a complete AI transcript by default. Select process evidence only when it adds information relevant to the outcome; use the Process Evidence guide for that narrower selection question. Interpretation of evidence about student responsibility and understanding is a separate question covered in Student Ownership. For making the task remain educationally meaningful with AI, see AI-resilient programming assignment design.
At assignment level, check that students have reasonable access to permitted tools or a workable alternative; instructions account for accessibility needs; privacy conditions are explicit; evidence and follow-up fit lecturer capacity; and marking criteria are clear enough for consistent use. Moderation can help a team compare how criteria are being applied, but its effect depends on the process and context. SURF’s toolkit offers discussion prompts for considering AI in assessment design; it is a practical aid, not evidence that any one design is effective. Npuls likewise provides sector-level guidance rather than endorsement of this article’s application.
Keep assessment separate from inference and investigation
Different evidence answers different questions. The artifact shows the submitted implementation; selected trajectory evidence records a bounded part of development; an explanation or demonstration can show how a student responds to a specific prompt; and a test result supports only the behavior and conditions tested. None automatically proves learning, authorship, independence or misconduct, and these records should not be converted into a universal AI-use, ownership or competence score. Keep assessment criteria separate from misconduct investigation; if a concern remains, use the institution’s fair process rather than turning uncertainty or missing records into a conclusion.
TraceYield is designed around development trajectories and selected evidence that may help review how AI-assisted work unfolded. This product connection describes the system’s intended evidence view; it is not a claim that every event is captured, that a trajectory is complete, or that TraceYield determines learning or grades. A lecturer still judges the evidence against the stated outcome and assessment context.