arXiv
Version-control history makes AI code less invisible
AI can make every student’s submitted program look different, but the way the code was built can leave a useful trail. Argus analyzed 42,695 homework submissions from six offerings of a Purdue C course and used unusual code features and rapid additions to direct staff to cases for manual review. In a university programming lab, instructors could inspect a suspicious sequence of edits before acting, if the course keeps detailed histories and clear rules for AI assistance.
A submitted program is often the only thing a programming instructor sees. That makes it possible to catch two students who copied from each other, because their code may look alike. It is much harder to tell whether a student wrote the work with an AI assistant, then changed the result before handing it in. In a large class, nobody can read every draft. A wrong accusation can damage a student’s academic record and wellbeing.
The file is not the whole story
Traditional code-plagiarism tools search for resemblance between students’ submissions. That works when one student copies another. It works poorly when an AI produces a different solution for each student. The final file can look original even when the student did not develop the solution alone.
A version-control history is a record of how a file changed over time, rather like seeing every saved stage of a drawing instead of only the picture at the end. It can show whether code appeared in small steps or arrived as a large block. It can also show how long the work took to develop. But such a record is not proof by itself. A student’s programming style can reflect earlier experience, and a student who is struggling may be more likely to seek outside help. A connection between an unusual code history and lower exam marks does not prove that AI caused weaker learning.
From invisible trail to review queue
Argus is designed to turn that history into a list for people to inspect. It combines unusual features in the code with behavior in its version-control record. Its indicators include advanced C features not taught in the course, styles that do not fit course conventions, short development spans, and bursts in which at least 30 new lines appear at 15 or more lines per minute. If an indicator is common across the class, Argus gives it less weight.
The system was used in one Purdue undergraduate C course. The course server automatically committed code whenever students ran make, and students were told that this happened. Across six spring offerings, in 2020 and 2022–2026, Argus analyzed 3,893 student-semester pairs and 42,695 homework submissions. In spring 2026, the server recorded 381,748 commits across 7,769 submissions.
The numbers were not treated as verdicts. Staff reviewed the highest-scoring students independently and reached consensus. Their review covered the top 300 cumulative scores and students in the top 150 for one assignment. Three staff members spent about eight hours each. Among the top 150 students by score, reviewers found insufficient evidence in four cases.
Argus’s mean score rose from 1.1 in spring 2020 and 0.5 in spring 2022 to 4.2 in spring 2025 and 11.9 in spring 2026. In spring 2026, 267 of the 584 students who completed the first midterm—45.7%—were flagged after manual review. Flagged students averaged 61.9% across three exams, compared with 73.5% for students who were not flagged. The correlation between the average score and exam performance was -0.537. Those figures can help staff decide where to look, but they cannot explain why any individual student performed as they did.
What a programming lab could see
If this approach holds, an assignment in a university programming lab would no longer be judged only by the final code uploaded before a deadline. Staff could inspect the sequence of edits, focus on a suspicious pasted block, and then decide whether a case deserves further action. Students who did their own work would be less dependent on instructors catching only copied solutions from classmates.
That future requires more than a detector. The course must collect detailed development histories and state clearly what AI help is allowed. Human reviewers must remain responsible for accusations, and the evidence must be strong enough to protect students from false claims. In that setting, AI-use detection becomes triage: a way to spend limited review time, not an automatic discipline system.