ai-code-detector

How to check student code for AI use

A submission looks off — too clean, too fast, too unlike anything this student has turned in before. What you do next matters twice: for the grade, and for the student. This page lays out a review workflow you can follow and defend: what to check by hand, when a free screening scan adds a useful signal, and how to raise it with the student without turning a suspicion into an accusation.

One expectation up front: no workflow — manual or automated — settles authorship for certain. The goal is a fair process that surfaces the files worth a closer look, not a machine verdict.

Skip to the screening scan ↓

Start with what you already know

You hold the strongest signal before any tool runs: this student's history. Pull up their earlier submissions and compare — naming habits, comment density, the mistakes they usually make, the way they structure a solution. A sudden jump in polish, or an idiom you have never seen from them, is worth noting. A stranger cannot run this check; you can.

Write down what struck you before scanning anything. That baseline is the context every later signal gets read against — including the detector's.

Read the flagged file by hand: four signals

Before you reach for a tool, read the file yourself. Four signals are worth checking — each one is a reason to look closer, never a conclusion.

  1. Comments that restate the code — a comment on every obvious line, phrasing that paraphrases what the code already says.
  2. Perfectly generic naming — textbook names applied with machine consistency across the whole file.
  3. Structure that is too even — every function the same length, identical boilerplate wrapped around every edge case.
  4. A style that matches no one — above all, a style that does not match this student's earlier work.

For the full walkthrough of each signal — including the ways honest code trips them — read How to tell if code was written by AI.

Read the four signals in depth →

Intro courses lean on a few languages — see what AI-generated Python code looks like, and the Java patterns that cut both ways.

Run a free screening scan on the files that stand out

When manual reading leaves you unsure, add one independent signal. The point is not to outsource the judgment — it is to check whether the parts of the file you flagged by hand are the same parts a detector flags.

  1. Paste the flagged file into the checker on the home page — free, no account needed.
  2. Read the AI-likelihood score and the highlighted snippets that drove it.
  3. Compare with your manual notes: agreement means a closer look, disagreement means keep reading.

Grading a whole class set? Batch mode screens all the files from one assignment and ranks them for review — see AI code screening for teachers.

Want to see the output first? Here is a sample report from a full assignment set.

See the teacher workflow →

Screening signal only. Review flagged code with the student before you act on it.

How to read the score in a grading context

The score estimates how closely the code matches patterns associated with AI generation — it is a screening signal, not evidence of misconduct. In a grading context, three situations raise false-positive risk: very short assignments (files under 10 non-empty lines are not scored at all), heavily templated starter code the whole class shares, and courses with strict style rules that push every student's code toward the same uniformity. A flag on any of these calls for extra skepticism, not less process.

Read how we think about accuracy and limits →

Talking to the student

If the signals stack up, talk to the student before anything else. Keep it concrete and non-accusatory: ask them to walk you through the flagged snippets — why this approach, what this function returns, how they would extend it if the assignment changed. A student who wrote the code can usually explain it; a student who hesitates may still have a fair reason, so treat the conversation as one more signal, not a confession.

Document what you reviewed and what was said. Whatever your institution's integrity process looks like, a detector score belongs at the start of it — never at the center.

Questions

Can I use a detector score as evidence in an academic-integrity case?

No. A score is a screening signal that helps you decide where to look — it is not evidence of AI use. Build any case on your own review of the code and your conversation with the student, and follow your institution's process for what happens after.

Should I tell students their work may be screened?

Yes. Instructors who use screening tools usually say so in the syllabus and explain how flagged work is reviewed — including the student's chance to explain their code. Transparency up front reduces both anxiety and disputes later.

Half my class got flagged on one assignment. What does that mean?

Usually it says more about the assignment than the class. Shared starter code, strict templates, and very constrained problems make honest submissions look alike — and look like model output. Check whether the flagged snippets are the shared template before reading anything into the scores.

Should I scan only the students I already suspect?

Scanning the whole set is fairer and more useful. Suspicion-only scanning bakes in your biases and gives you nothing to compare against. A full-class scan shows which files genuinely stand out from the class baseline.

Start with the file that made you suspicious

Run a free single-file check now, then review it with the signals above. When the next assignment lands, batch mode screens the whole set and ranks it for review.

Keep reading