Portfolio Assessment for AI-Assisted Programming Projects

What evidence across projects may add

Evidence from multiple tasks may show repeated performance, variation between contexts, a response to feedback, a recurring difficulty, or an application in a different setting. Those are possible patterns to interpret; they do not automatically establish growth, progression, transfer, independence or competence.

A later artifact is not necessarily better evidence. Task difficulty, scaffolding, team role, requirements, permitted AI use, tool version and verification conditions may have changed. A comparison is more informative when the lecturer can see those differences and explain why the selected items relate to the same outcome.

Transfer means applying relevant learning in a meaningfully changed context, not merely repeating a technique. A review of learning-transfer research describes application in novel contexts as a central concern and emphasizes that context matters; it does not validate this portfolio approach. See Hajian’s review of transfer research.

Constructed example: input handling across three projects

Constructed example — not student data, classroom research or TraceYield evidence. The learning outcome is: “The student can design and verify robust input-handling behavior across relevant programming contexts.” The three selected items below offer different evidence; they are not scores or a timeline from worse to better.

The set may be consistent with stronger application across these contexts, and the import pipeline is meaningfully different from the earlier API work. It does not by itself prove growth, general transfer or competence. The lecturer would still need to consider task demands, supports, the student’s role, AI conditions, and whether the tests actually cover the stated requirements. A focused follow-up could ask the student to explain why a malformed record is rejected and how that behavior would be verified in a different import format.

Select for coverage, not volume

Make selection rules visible. Which evidence is required? What may the student choose? Would a lecturer-selected item or a small sample help? Can revised or unsuccessful work be included when debugging, diagnosis or verification is part of the outcome? Student choice can surface relevant work, but may favor polished successes. Lecturer selection or sampling may address some gaps while adding workload and changing the assessment relationship. A mixed approach may fit some courses; none is a universal portfolio format.

Ask whether the selected evidence adequately covers the outcome being judged. A curated set may contain only successful work, solo work, richly documented work, one task type, or work under one AI-use condition. It is not automatically representative. A failed item is useful only when the relevant evidence is the diagnosis, correction, verification or later application—not the failure by itself.

A useful item may need only enough context to interpret it: the outcome, task and role, relevant AI conditions, selected artifact or evidence, verification/result, and any material uncertainty. These are information needs, not mandatory fields. Do not require full transcripts or every intermediate action.

Interpret evidence by learning outcome

Do not simply average unrelated project scores, session ratings, AI-use counts or artifact grades. Interpret the evidence by the learning outcome. Depending on local criteria, a lecturer may judge each criterion separately, form a holistic judgment across relevant items, or require an essential outcome to be demonstrated on its own. The article cannot prescribe one aggregation rule for every programme. Keep conflicting evidence visible rather than hiding uncertainty in an average.

Later evidence may matter more if the intended judgment is about current performance, but recency is not a default weighting rule. Changed tasks, roles, support or AI conditions can make a later result hard to compare. The consequences of the assessment and the institution’s policy also matter. Work on programmatic assessment in health-professions education discusses synthesizing multiple observations and adjusting evidence expectations to decision stakes; this is a bounded analogy, not direct validation for HBO-ICT programming portfolios. See Deconstructing programmatic assessment. If uncertainty calls for a focused oral check rather than more portfolio records, see Oral Defense.

Reflection and missing evidence

A student’s note can explain why an item was selected, connect evidence to an outcome, name uncertainty or guide a lecturer’s follow-up. It remains the student’s interpretation, not independent verification of learning, progression or transfer. In one first-year medical-student portfolio programme, reflection quality was associated with portfolio ratings; that finding is specific to its setting, not a rule for judging programming competence (Driessen et al.). Do not let polished writing substitute for programming competence unless reflection itself is an outcome. If AI may help draft portfolio commentary, explain whether that is permitted, whether disclosure is expected and whether the prose is assessed. Anchor programming claims to project evidence rather than trying to detect AI-written reflection.

Missing records are missing evidence. They do not prove lack of learning, hidden AI use, misconduct or lack of work. They may mean that the portfolio does not yet provide enough basis for a particular judgment. The lecturer may need another relevant artifact, a focused follow-up, another task or a narrower conclusion.

Make outcomes and evidence expectations known in advance, provide reasonable opportunities to demonstrate them, and account for differences in project opportunity, student role, AI access and evidence capture. Do not reward portfolio volume or telemetry richness. Moderation may be appropriate for consequential judgments. Select evidence for the assessment purpose rather than retaining every observable action.

Keep the lecturer’s judgment central

Where captured, TraceYield may help surface session or project context, technical decisions, corrections and verification. Such records can help a lecturer navigate evidence; they do not establish progression, transfer, competence, portfolio sufficiency, independence or a grade. For the narrower question of which process records matter within one assessment, see Process Evidence. For responsibility and understanding, see Student Ownership. For individual judgments within shared software work, see Individual Contribution.