What Evidence Should an HBO-ICT Student Provide When Using Claude Code, Codex or Cursor?
A vendor-aware but tool-neutral evidence checklist for HBO-ICT students using coding agents, focused on decisions, modifications, testing, verification, and understanding.
TraceYield Insights
10 min read · Updated September 3, 2026
TraceYield
AI engineering evidence
What Evidence Should an HBO-ICT Student Provide When Using Claude Code, Codex or Cursor?
The tool name is not the evidence
Claude Code, Codex, Cursor, GitHub Copilot, and similar products change quickly and expose different interfaces. Their names do not tell a lecturer whether a student understood the work. Evidence should describe the student’s decisions and verification, not merely the product selected.
Current documentation describes these tools as capable of reading project context, editing code, running commands, or operating in agent-like modes. That makes the educational question more important: how did the student supervise, evaluate, and adapt the resulting work?
A practical evidence checklist
A student can provide: the task or problem as understood; the tool and purpose used; the material contribution; the important change or rejection; tests and checks performed; one debugging or integration decision; and a short statement of remaining limitations. The exact format can be a project note, portfolio entry, or submission field.
This evidence is useful across vendors because it describes the work rather than a volatile feature label. Students should not need to reproduce a private transcript when a clear explanation and relevant artifact are enough.
What to look for in agent-assisted work
Look for context: did the student specify requirements and constraints? Look for evaluation: did they inspect or challenge the result? Look for integration: does the change fit the repository? Look for verification: are tests and edge cases meaningful? Look for adaptation: can the student change the solution when a related requirement changes?
An agent may create a large patch or a small one. Neither is automatically better evidence. The important issue is whether the student can connect the tool’s output to the learning outcome.
Vendor capabilities are not stable policy
A course policy should not promise that a particular vendor always records, retains, or exposes a specific activity. Product interfaces, approval modes, privacy settings, and billing models change. Describe the evidence the student must demonstrate and offer a safe alternative if the chosen tool cannot provide it.
Students should also be told what data may not be sent to a tool and how external services interact with institutional requirements. Tool-specific guidance belongs alongside, not instead of, general policy.
A final student-facing instruction
A clear instruction might say: “Use approved tools within the permitted range. In your submission, identify material use, show what you changed, explain one important decision, provide verification evidence, and be prepared to demonstrate or adapt the relevant part of the work.” That is more durable than requiring a particular screenshot from a particular interface.
The aim is not to prove that the student worked without help. It is to make the student’s contribution, judgment, and understanding assessable.
Evidence should survive vendor change
A vendor-neutral submission might contain a short tool-use statement, a selected change or decision, a verification record, and a transfer question. It remains useful whether the student uses a local assistant, an IDE agent, a terminal agent, or no tool at all. The course can provide examples for current products without making the product interface the assessment.
This is important because feature names, permissions, and logs change faster than curriculum documents.
Do not treat feature access as equal
Students may have different plans, environments, or accessibility needs. Institutions should explain which tools are supported and provide a fair route to meet the evidence requirement. A student should not receive a hidden advantage because a particular product exposes a more convenient activity history.
Assess the demonstrated capability, not the richness of a vendor dashboard.
A student-facing example
For a project that uses an agent to add an API endpoint, the student might provide the requirement as understood, the agent’s material role, the interface or error-handling decision made by the student, the tests run, one generated suggestion that was changed, and a short explanation of what remains uncertain. This is enough to start an assessment conversation without exposing every prompt.
The same structure works for a debugging task or refactor. The details change; the evidence questions remain stable.
Keep terminology current but policy durable
Current vendor documentation can help lecturers explain the difference between chat, inline assistance, agent modes, terminal tools, and cloud agents. It should not be copied into a permanent policy as if the product interface were stable. Recheck links and permissions before each academic year.
The durable requirement is that the student can explain, modify, test, and take responsibility for the work.
Keep the student instruction portable
A durable instruction refers to material assistance, decisions, changes, tests, verification, and explanation. It can then be updated with current vendor examples without changing the assessment’s core requirements. This reduces the risk that a curriculum becomes obsolete when a product renames a mode or moves a feature.
Portability is especially important for students who may enter workplaces using tools the programme did not explicitly teach.
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