To verify student understanding of code, ask students to explain, trace, modify, and debug their work in ways that reveal their reasoning.
These checks can show what a student understands more clearly than an authorship score, which cannot prove who wrote a program or whether misconduct occurred.
What does it mean to understand a piece of code?
A student who understands a program can usually describe its purpose, explain how its parts work together, and predict how it behaves with different inputs.
They should also be able to discuss important choices, such as why they used a loop, selected a data structure, or handled an edge case in a particular way.
Understanding is not the same as memorizing every line.
Students may use documentation, discuss ideas with others, or rely on approved tools and still understand the resulting code.
The assessment should focus on learning goals and course rules: can the student reason about the concepts and decisions the assignment was intended to teach?
Use a short explanation to surface reasoning
Ask students to explain a small, specific part of their program rather than recite the entire submission.
For example, they might describe how a function’s inputs affect its output, what a conditional branch handles, or why a loop stops when it does.
Specific prompts make it easier to assess reasoning and harder for a student to rely on a vague summary.
Follow up with a question that connects the code to its behavior: “What would happen if this value were empty?” or “Why is this check needed before the function call?” Listen for a coherent explanation in the student’s own words, including a willingness to say when they are unsure.
Fluency alone is not proof of understanding, so consider the response alongside other evidence.
Ask students to trace the program
Tracing means following execution step by step.
Give students a small input and ask them to show how key variables change, which branches run, and what the program returns.
This works well for loops, conditionals, recursion, and state changes because it tests whether students can connect the written code to its actual behavior.
- Choose an input that exercises a normal path and, where useful, an edge case.
- Ask students to record a few meaningful variable values rather than rewrite every line.
- Invite them to predict the output before running the program, then explain any difference.
Tracing is most informative when it matches the course objectives.
A student may understand the logic but struggle with notation or working under time pressure, so avoid treating a single tracing mistake as a complete measure of ability.
Make a small, unannounced code change
Give students a modest variation on their own solution.
They might add a validation rule, change a sorting condition, support an additional input type, or adapt a function to return a different result.
Ask them to explain what they changed and why.
A useful modification is narrow enough to complete during a brief conversation or lab check, yet meaningful enough to require understanding the relevant logic.
Keep the task aligned with material students have learned, and provide reasonable accommodations or preparation when the format could disadvantage students for reasons unrelated to programming knowledge.
Use debugging as an assessment
Debugging reveals how a student investigates a problem, not just whether the final code runs.
Provide a small bug in a familiar section, or ask the student to investigate a failing test.
Observe whether they can reproduce the issue, form a plausible explanation, inspect relevant values, and check whether a proposed fix addresses the cause.
Ask students to distinguish a symptom from a root cause.
For example, a wrong output may result from an off-by-one condition, an incorrect assumption about input, or a value being overwritten earlier.
The path they take can show conceptual understanding even if they need time or a hint to finish.
Review tests, design choices, and edge cases
Tests offer a concrete way to discuss what a program is supposed to do.
Ask students to explain what a test checks, identify behavior that is not covered, or propose a test for an edge case.
A student who can connect a test to a requirement demonstrates a different kind of understanding than one who can only report that all tests passed.
Code review questions can also surface design reasoning: Why did the student split the solution into these functions?
What assumptions does it make?
Which alternative approach did they consider?
There may be several valid answers; assess whether the reasoning is relevant and consistent with the code rather than whether it matches an instructor’s preferred style.
Compare evidence over time
A single artifact rarely tells the whole story.
Where practical, compare the submitted program with earlier exercises, in-class work, drafts, version history, and the student’s explanation.
Look for evidence connected to the learning objectives, such as improving use of functions or a consistent grasp of a concept across different tasks.
Differences in style or apparent sophistication can prompt a fair follow-up, but they do not establish authorship.
Students can learn quickly, use different tools, or receive legitimate support.
Give students a chance to explain their process and consider the context before drawing a conclusion.
What can AI code detectors tell you?
AI authorship classification and code similarity analysis address different questions.
An AI writing detector estimates whether text resembles machine-generated material; a similarity checker compares code with other sources for matching or closely related content.
Neither kind of result, by itself, proves who created a submission or whether a student violated a course rule.
Do not treat an AI score as a verdict.
Results can be uncertain, and code is especially difficult to assess through signals designed for ordinary prose.
Turnitin says its AI writing model does not reliably detect code, so a writing report should not be mistaken for a source-code similarity check.
If you consider a source-code detector such as Codespy, treat its output as one limited lead to review, not an endorsement or a substitute for examining the work and speaking with the student.
Keep verification fair and aligned with course policy
Explain assessment methods and expectations before assignments begin.
If students may use AI assistants, collaboration, or external libraries, state what is allowed and what they must disclose under the course rules.
Policies vary across institutions and courses, so follow the applicable policy rather than assuming one universal standard.
Apply comparable follow-up questions and criteria to students in similar situations.
Record the evidence you considered, give the student a chance to respond, and use the institution’s established process if a concern remains.
The aim is to understand a student’s learning and evaluate their work fairly, using direct evidence of programming knowledge wherever possible.