Can a teacher tell if a student's code was written by AI?

Do AI code detectors work?

An AI code detector is a tool that scores a piece of code on how likely it is to have come from a language model. The research on them is consistent and not encouraging:

• Suh et al. (arXiv 2411.04299, 2024) tested existing detection tools on code and concluded that "they all perform poorly and lack sufficient generalizability to be practically deployed." Their best model reached an F1 score of 82.55, which still means a meaningful share of wrong calls.
• The DroidCollection work (arXiv 2507.10583) built a set of more than a million samples across 7 languages and 43 models, including code written by people and models together, and found that "existing detectors' performance fails to generalise to diverse coding domains and programming languages."
• Watermarking, where a model hides a statistical signal in its output, has its own problem: Lee et al. (arXiv 2305.15060) found existing methods "fail to function appropriately in code generation tasks due to the task's nature of having low entropy." Code that must compile leaves few free word choices to carry a signal.

General text detectors are weaker still on code. OpenAI's AI classifier announcement (31 January 2023) listed among its limits that it "performs significantly worse in other languages and it is unreliable on code", and a note added at the top says that as of 20 July 2023 the classifier "is no longer available due to its low rate of accuracy."

Short assignments make this worse. A function that reverses a string has a handful of correct forms, and a student and a model will often write the same one.

What can each method actually show?

Method	What it measures	What it cannot show
AI code detector	A statistical guess about style	Who wrote the code; scores vary by language and model
MOSS or another similarity checker	How alike submissions are to each other	Why they are alike, or whether a model was involved
Public-code matching (for example Copilot's code referencing)	Whether a suggestion matches public code	Anything about code the student edited or wrote
Version history (git, editor history, drafts)	How the work grew over time	Whether a pasted block came from a model or a classmate
Asking the student to explain or extend the code	Whether the student understands it	Whether they wrote it, only whether they can work with it

The rows near the bottom are the ones that hold up in a conversation with a student, because they rest on evidence the student can see and answer.

What signs do reviewers point to?

Some open source projects list signs they treat as suspect. GNOME's extension review guidelines say that "imaginary API usage, comments serving as LLM prompts, or other indications of AI-generated output will be rejected." Imaginary API usage means calling functions or options that the library does not have. In a classroom the equivalent signs are code that uses methods not taught or not in the language version the course uses, comments that read like instructions to a chatbot, and an import of a package that does not exist (see why AI code imports packages that do not exist).

Treat these as reasons to ask a question, not as findings. A student who reads ahead or copies from documentation produces some of the same signs.

How should a teacher handle a suspicion?

1. Write the course rule down first. Say which uses of AI are allowed (explanations, debugging help, none at all) and whether students must disclose them. A rule announced after the fact is hard to apply fairly.
2. Ask for process with the submission. Require the git history or the editor's version history, not only the final file. Commits spread over days look different from one commit with the finished program.
3. Do not act on a detector score alone. OpenAI's own guidance for its classifier was that it "should not be used as a primary decision-making tool". The research above gives no reason to treat code detectors differently.
4. Ask the student to walk through the code. Have them explain a function, predict an output, or make a small change in front of you. That tests the learning goal directly.
5. Record what you saw. Keep the history, your questions and the answers, so a later review rests on the same facts.

The CodeLifter article on AI code detectors covers the research in more depth. If you are the student, can you prove you wrote a piece of code yourself? explains what records help, and a detector flagged code written in 2019 as AI covers what to do when a tool flags work that predates these models.

Why does understanding matter more than authorship?

For a course, the question underneath is usually whether the student learned the skill. A January 2026 Anthropic trial with 52 developers learning a new Python library found the group with an AI assistant scored 50% on a follow-up quiz against 67% for those who coded by hand, with the largest gap on debugging questions. An explanation or debugging check tests exactly that, whatever tool produced the first draft. The thread on whether vibe coding is bad for learning covers that study.

Short version

• Code-specific AI detectors perform poorly in published studies and do not generalise across languages and models.
• OpenAI withdrew its text classifier in July 2023 for low accuracy and had already said it was unreliable on code.
• Similarity checkers such as MOSS compare students with each other; they say nothing about models.
• Version history and asking the student to explain or change the code are firmer evidence.
• Set and publish the course's AI rule before the assignment, not after.