Process Evidence: A Better Way to Assess Programming in the Age of AI

What process evidence means

Process evidence is observable material showing how work developed: a problem framing, design sketch, milestone, version change, debugging note, test result, explanation, or reflection. In an AI-assisted assignment it may also include the purpose of an important AI interaction, the change the student made after evaluating an output, or the verification performed before acceptance.

It is not the same as an activity log. A long transcript can be difficult to interpret and easy to collect without purpose. Good process evidence is selective, connected to a learning outcome, and usable by both student and assessor.

Examples from programming education

For a data-structure assignment, ask for one rejected design and the reason it was rejected. For a web application, capture a milestone where the student clarified a requirement and explain how it affected the implementation. For debugging, submit the original symptom, the hypotheses tested, and the evidence that confirmed the fix. For an AI-generated component, require a short verification note tied to tests and edge cases.

These artifacts create a window into reasoning without requiring a lecturer to inspect every line of history. They also encourage students to make decisions visible while the work is happening, which can support learning rather than merely produce retrospective paperwork.

Avoid surveillance by design

Collect the minimum evidence needed for the assessment. State the purpose, access, retention, and review process before the assignment begins. Do not make students submit sensitive prompts or private conversations when a short explanation will answer the educational question. Do not use process evidence as a hidden behavioral monitoring system.

A student should be able to understand what counts as useful evidence and why. This transparency is particularly important when tools are provided through external services or when the evidence could contain personal, confidential, or third-party information.

Evidence is interpreted with the artifact

If evidence conflicts, that is a reason for a focused conversation or transfer task. It is not an automatic reason to infer dishonesty. Assessment remains a human judgment supported by multiple sources.

A lightweight starting model

Begin with three checkpoints: a short framing note, one meaningful development or debugging checkpoint, and a final explanation of decisions and verification. Add a live modification only when the outcome requires it. Review a sample with colleagues to check whether the evidence is understandable and whether the workload is proportionate.

The model can evolve as the programme learns. Process evidence is valuable because it makes the development journey visible enough to assess—not because every moment must be recorded.

A process-evidence design test

For each proposed evidence item, ask four questions: which learning outcome does it illuminate; can the student produce it without disproportionate burden; can the assessor interpret it consistently; and what privacy or access risk does it create? Remove an item when the answer is unclear. A smaller evidence set is often stronger.

The test also prevents process evidence from becoming a proxy for diligence. Students should not receive an advantage merely because they produce more documentation than their peers.

Process evidence can support feedback

The value of a milestone or debugging note is not limited to summative grading. It can help a lecturer intervene while the student can still change direction. A student who repeatedly accepts plausible output without testing needs different support from one who tests thoroughly but struggles to frame the problem.

Used formatively, selected process evidence can improve learning before it becomes evidence in a final judgment.

Choose evidence with a purpose

A version history can show when a change appeared, but not why it was made. A reflection can explain a reason, but may be written after the fact. A test result can show verification, but only if the test actually addresses the risk. A short explanation can reveal understanding, but should be interpreted with the artifact. The value comes from combining evidence that answers a defined question.

For every item, state the question in the assignment design. “Show one meaningful change of direction” asks how the student responded to evidence. “Explain one generated component” asks whether the student can connect output to requirements and verification. This precision helps students and reduces assessor guesswork.

Process evidence should be usable by learners

Students should receive feedback on the process while they can still change it. A checkpoint can reveal that a learner is accepting output without testing, or that a learner is exploring several approaches without narrowing the problem. The lecturer can intervene with a question, example, or small constraint before the final submission.

This makes process evidence part of learning rather than a post-hoc forensic requirement. It also helps students understand why the evidence matters.

A process-evidence brief students can understand

Tell students which two or three moments matter: the initial framing, one meaningful decision or correction, and the final verification. Give an example that includes a tool-assisted moment without implying that every student must follow it. Explain how the evidence will be read and retained.

Clear instructions reduce both anxiety and the temptation to submit a large unstructured archive.