A Framework for Designing AI-Resistant Programming Assignments

AI-resistant programming assignments are less about catching students after the fact and more about designing work in which copied or generated code produces visible gaps. This framework emerged from a two-semester pilot at Northfield State University, a public institution with about 2,400 undergraduate CS majors. In fall 2023, the department ran a routine code plagiarism checker across three Java sections and found results that changed how instructors thought about assessment.

The trigger was not a spectacular cheating ring. It was a linked-list reversal lab in an intermediate data structures course. A teaching assistant noticed 23 of 74 submissions shared the same unusual variable names and the same incorrect edge-case comment. MOSS flagged 18 of them as peer-similar. Five more had near-zero peer similarity but looked suspicious enough that the TA spent six hours manually checking Stack Overflow, GitHub Gists, and a Java tutorial site. That manual work found three exact source matches. The remaining two produced no web match at all.

One of those two became the case that pushed the department toward a redesign.

We had a submission that looked cleaner than anything we had taught, used a slightly different linked-list traversal than the course textbook, and had no peer match. It was not copied from anywhere we could find. It was almost certainly generated.

— Dr. Elena Ruiz, CS program coordinator, Northfield State University

Why Traditional Plagiarism Checking Missed the Problem

Northfield State had used MOSS for years to check C++ and Java submissions. The tool was fast and reliable for near-identical code. It caught direct copying between students. It did not catch copy from tutorial sites, lightly refactored Stack Overflow answers, or original-looking code produced by a large language model.

The department then tried a two-pass approach. First, they ran the suspicious submissions through a web-source scan. That surfaced three repositories and two Java tutorial pages with the same loop structure. Second, they ran the submissions through an AI code detector. Two of the remaining unflagged files returned a high probability of LLM authorship without matching any peer or public source.

The evidence stack looked like this:

Detection layerWhat it caughtWhat it missed
Peer similarityCopy-paste, renaming, method reorderingUnique single-source submissions
Web-source matchingStack Overflow, GitHub, tutorial reusePrivate group work or offline help
AI code detectionLLM-generated code, low burstiness, unusual styleHeavily human-edited AI output

That last category mattered. The two students involved had not copied from each other. They had each used an AI assistant, lightly changed variable names, and submitted. A source code plagiarism checker alone would never have flagged them because the code was not similar to anything in the comparison corpus. The AI signal was the only clue.

[[SCREEN