How to Detect AI-Generated Code in a Take-Home Submission
Why "AI detectors" mostly don't work
Tools that claim to classify whether a code submission was AI-generated have consistently weak accuracy. They produce many false positives (penalising candidates who happen to write in a clean style) and many false negatives (modern LLMs can produce idiosyncratic-looking code on request). Acting on their output is risky.
Reliable detection comes from a different angle: it doesn't try to classify the artifact. It compares the artifact to the process that produced it.
What actually distinguishes human from AI submissions
Three signals, none of them based on classifying the final code:
1. Process trace
How was the code written? Humans write iteratively — a function appears, gets edited, gets renamed, gets a bug fix. AI-pasted code arrives in large chunks, often complete on first appearance. Capture the keystroke and edit timeline of the submission and the difference is visible.
ClarityHire records this timeline for take-home submissions and surfaces "paste-rate" and "edit-iteration" signals that flag process patterns inconsistent with hand-written code. It doesn't accuse the candidate — it surfaces the signal for the reviewer to probe.
2. Coherence between code and explanation
A candidate who wrote the code can explain it specifically. A candidate who pasted it cannot. The walk-through interview at the end of any take-home is the single most reliable detector of AI-pasted submissions because the candidate has to defend their own choices in real time.
Probe specifically: "Why did you pick this approach over the alternative?" "What would change if X were different?" "Walk me through what happens when this function gets called with [edge case]." Candidates who wrote it answer fluently. Candidates who pasted it improvise vaguely.
3. Style consistency
Across multiple submissions or across different parts of a single submission, did the style stay coherent? Naming, comment style, error-handling patterns. AI submissions often have suspicious internal consistency and suspicious external inconsistency: more uniform than a human would write within a project, more variable than the candidate's other artifacts.
What to do with the signal
Never auto-reject. The signals are probabilistic, and the cost of a false positive is high — both ethically and to the pipeline.
Use them as triage: a flagged submission gets a more rigorous walk-through. The walk-through resolves it cleanly in almost every case. If the candidate fluently defends their code, the score stands. If they cannot, the score reflects what they can defend.
This is more humane than a black-box classifier rendering a verdict, and it produces better hiring outcomes.
What to communicate to candidates
Tell them upfront: "This take-home is followed by a 30-minute walk-through where you'll explain your code. Use whatever tools help you do your best work, but be prepared to defend your choices."
Candidates who can use AI assistants effectively as a tool and explain their own work fluently are not the people you want to filter out — that's how engineers work in 2026. The filter is for people who paste without understanding. The walk-through is the right instrument.
Where this is heading
Detection-based approaches will continue to lose ground against improving LLMs. Process-trace and walk-through approaches will continue to work because they don't depend on the artifact looking different — they depend on the candidate's relationship to their own work being defensible. That relationship is what you're hiring for anyway.