For teachers · grading workflow
Upload one assignment or a whole class set. Get per-file scores, highlighted snippets, and a report that helps you decide which submissions deserve a conversation.
Use results to prioritize review, not to make an accusation.
The hard part is not spotting one odd submission. The hard part is doing it across a full class set while still being fair to the student who wrote unusual but honest code. A screening tool can sort the pile. It cannot tell you intent.
I want to be pretty sure when I accuse someone.
AI code detectors can produce false positives and false negatives. That is why the report is built around review: what was flagged, which snippets mattered, and what a human should check next. If a student can explain the code, that explanation matters more than a score.
It should not auto-accuse a student, auto-email an integrity office, or turn a score into a discipline recommendation. It should help a teacher find the files that deserve human attention.
If your course uses AI screening, say so early. Tell students what you review, what counts as follow-up, and how they can explain or revise flagged work. A clear policy lowers fear and makes the review process easier to defend. 待墨盾裁决
No. The score is a screening signal. Read the code, compare context, and talk to the student before you treat the result as meaningful.
Treat it as a prompt to review, not a conclusion. Style, starter code, libraries, and short programs can all affect signals. Human review comes first.
In most cases, yes. A clear course policy is easier to defend than a surprise accusation. Final wording should follow your institution's rules and our published terms.
No. It can help you decide where a walkthrough is worth the time, but it does not replace direct assessment.
Run a free check on one file, then move to batch review when you need per-student reports.