How to See What a Student Actually Did When AI Helped Write the Code
A practical guide for examining student decisions, modifications, debugging, testing, integration, and explanation when an AI tool contributed to a programming submission.
TraceYield Insights
10 min read · Updated August 16, 2026
TraceYield
AI engineering evidence
How to See What a Student Actually Did When AI Helped Write the Code
Do not begin by asking who typed each line
In contemporary software development, authorship is distributed across people, libraries, templates, tools, and services. A student may ask an agent to draft code, then alter its structure, correct errors, add tests, and integrate it into a larger project. Counting manually typed lines would not provide a useful account of that contribution.
A better question is what the student understood and did with the available assistance. The answer comes from a combination of the submitted artifact, visible changes, testing, decisions, debugging, and the student’s ability to explain and adapt the work.
Inspect decisions before activity volume
Ask which part of the problem the student chose to solve first and why. Look for evidence of requirements being clarified, constraints being recognized, interfaces being selected, or alternatives being compared. A short interaction can represent substantial judgment; a long transcript can represent repeated requests without learning.
The assessor does not need to reconstruct every decision. Select the decisions that are central to the learning outcomes and ask the student to connect them to the final code.
Look at modifications and integration
Generated code is rarely delivered unchanged. Examine whether the student adapted naming, structure, error handling, interfaces, tests, and assumptions to the project. Can the student explain how the component fits with the rest of the application? Does it use the project’s conventions and constraints appropriately?
Integration is educationally important because it requires context. An agent can produce a plausible isolated function; the student still has to determine whether it belongs in this codebase, under these requirements, with these risks.
Use debugging and transfer questions
Show the student a failure or ask for a small change to the submitted program. What would they inspect first? Which hypothesis would they test? Can they predict the effect of a modification before running it? These questions reveal understanding more directly than a generic “explain your code” request.
A transfer task should be related but not identical. It tests whether the student can apply the concept in a new situation rather than repeat a prepared explanation. Keep it short and aligned with the original learning outcome.
Use evidence fairly
Repository history, selected prompts, test results, reflection, and oral explanation each have limitations. A missing log does not prove that no work happened, and a detailed log does not prove understanding. Treat them as evidence to interpret together and communicate the interpretation criteria in advance.
When the picture is unclear, the fair response is a focused clarification. The goal is not perfect attribution; it is a defensible judgment about the student’s demonstrated capability.
A worked review sequence
First read the requirement and final behavior. Then select one central design decision and one failure or edge case. Ask the student to explain the decision, show where it appears in the code, and describe how it was verified. Finally ask for a small change. This sequence is more informative than asking whether the student wrote the code themselves.
It also makes the review manageable. The lecturer does not need to inspect every interaction or reconstruct a perfect history to reach a useful assessment judgment.
Treat missing evidence carefully
A student may not have kept a prompt transcript, may have worked with a peer, or may have used an interface that does not expose a useful history. Missing process evidence should lead to another form of evidence where possible, not an automatic conclusion about the student’s work.
The assessment design should provide more than one route to demonstrate the outcome.
Read the student’s work as a set of choices
A lecturer can identify choices at several levels: the way the requirement was interpreted, the boundary selected for a component, the error-handling approach, the tests added, and the moment where a generated suggestion was changed. The point is not to find a uniquely human line of code. It is to see whether the student can give a reasoned account of the choices that matter.
This approach also respects collaborative development. A student can contribute by integrating a component, reviewing a teammate’s implementation, or diagnosing an interaction between services. Those contributions may not appear as a large standalone file.
Use evidence at the right resolution
For a small exercise, one explanation and one transfer question may be enough. For a semester project, the lecturer may need milestone evidence, a review conversation, and a portfolio entry. Requiring the same granularity everywhere creates unnecessary work and does not improve validity.
The assessment should make clear which part of the student’s contribution is being examined. That clarity is fairer than asking an open-ended question about everything the student did.
What the lecturer can reasonably conclude
A lecturer can often conclude that a student understands a component when the student can explain its role, identify an assumption, diagnose a related failure, and make a justified change. That conclusion is narrower and more defensible than claiming to know who authored every line.
Keeping the conclusion narrow is a strength. Assessment does not need more certainty than the learning outcome requires.
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