Why AI Detection Is Not Enough for Programming Assessment

Programming makes the classification especially unstable

Code is routinely transformed by formatters, refactoring tools, libraries, templates, autocomplete, teammates, and generated tests. A student may ask an agent for an explanation, accept a small suggestion, rewrite a larger patch, or combine generated code with an existing project. A binary label hides those meaningful differences.

The same code can also be produced by very different journeys. One student may understand and verify a generated solution. Another may submit it without being able to explain the design. A detector cannot reliably distinguish those educationally important cases.

False certainty creates assessment risk

This does not mean lecturers must ignore unusual work. It means a detector, if used at all, should be treated as a prompt for a fair review rather than as proof. The student should have an opportunity to explain the work and provide relevant evidence.

Replace the binary with an evidence question

Ask what the assessment needs to establish and what evidence can support it. For design, inspect the student’s rationale and alternatives. For debugging, ask the student to diagnose a related failure. For implementation, require a modification or extension. For verification, examine tests, edge cases, and the student’s explanation of what remains uncertain.

Process evidence can include selected versions, decisions, prompts or questions, test results, and reflection. It need not be a full surveillance record. Its purpose is to make the work more discussable and the assessment more valid.

Keep integrity and learning connected

Academic integrity is not served by banning every tool without regard to the learning outcome. Nor is it served by allowing an unexamined artifact to stand in for learning. Clear permitted-use rules, transparent disclosure, staged work, and proportionate explanation create a stronger basis for both integrity and learning.

The result is a shift from “can we catch AI?” to “does this assessment give us credible evidence of what the student can do?” That shift is more demanding, but it addresses the educational problem directly.

What to do when a submission raises questions

Start with the work itself. Identify a requirement, design decision, test, or concept that matters to the assessment and ask the student to explain or adapt it. Review the available process evidence and the declared AI use. Keep the conversation tied to published criteria and institutional procedure.

If the explanation is incomplete, that may affect the evidence for the learning outcome; it is not automatically proof of prohibited AI use. Academic-integrity decisions should follow the institution’s fair process rather than the apparent confidence of a detector.

The better investment is assessment design

Detection can feel attractive because it promises a simple answer. Assessment redesign is slower, but it addresses the underlying validity gap. Staged work, authentic constraints, targeted explanation, and verification make the learning more visible whether or not a student used AI.

This approach also remains useful when tools change, because it is based on what students can demonstrate rather than on the current performance of a classifier.

Detection can distract from validity

A detector-centered process can make a course focus on whether a submission appears suspicious rather than whether the assessment measures the intended capability. It may encourage students to disguise assistance while leaving the underlying task unchanged. It can also put lecturers in the position of defending a probability estimate instead of explaining the learning evidence.

A stronger response is to redesign the assessment so that the important capability is demonstrated directly. If debugging matters, observe debugging. If design reasoning matters, ask for a rationale and a related decision. If responsible AI use matters, assess verification and disclosure. The design can still use a final artifact, but it no longer asks the artifact to carry every claim.

Use detection, if at all, as a limited signal

There may be situations where a tool raises a question worth discussing, but the result should not be treated as a verdict. Any use should be transparent, proportionate, and subordinate to the institution’s procedure. Students need an opportunity to explain relevant work and respond to evidence.

In programming, the more useful review often starts with code behavior, tests, design, and understanding. Those sources are closer to the educational question than a classifier’s guess about how code was produced.

A better response to uncertainty

When a final artifact creates uncertainty, the lecturer can ask for a focused explanation, inspect a relevant test, or use a related task. These options provide direct evidence and keep the student inside a fair process. They also help distinguish lack of understanding from a tool-use question.

The response should be documented consistently so that similar cases are treated similarly.