Detecting AI-generated code in student submissions

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# Detecting AI-generated code in student submissions

Detecting AI-generated code in student submissions is cheap to start and expensive to keep, and almost nothing written about it distinguishes the two.

## Deciding what the output is for

Measure the reviewer's time, because it is the resource that runs out. Everything else — licence cost, compute, storage — is small and predictable. Reviewer minutes per submission is the number that decides whether the process survives contact with a busy term, and it is almost never instrumented, which is why so many pilots are judged a success and quietly abandoned within a year.

## What the reviewer actually needs

Boilerplate is not noise to be tuned out — it is signal about the assignment, and the right place to remove it is the specification, not a threshold. If forty per cent of every submission is scaffolding the brief supplied, then every pairwise score starts at forty per cent and the interesting variation is compressed into the top half of the range. Subtract the supplied code first and the same detector suddenly discriminates.

## Making it survive the year

Distinguish between code that is similar and code that shares a history. Two implementations of the same textbook algorithm are similar and unrelated. Two files with the same unusual variable ordering, the same dead branch and the same off-by-one comment share a history. Systems that report only the former make the reviewer do the work of finding the latter, on every single pair, forever.

## Putting it into practice

Treat a [code plagiarism checker](https://codequiry.com) as the start of a conversation with the author and it will rarely let you down.