Every hiring team I talk to asks some version of the same question: how do we stop candidates from cheating with AI? It's the wrong question, and asking it is why most companies' anti-cheating measures don't work. "Cheating" implies there's a clean rule being broken. There isn't. Candidates use AI assistants to code the same way engineers on your own team use them — constantly, by default, without asking permission. Treating that as a violation to police, rather than a condition to design around, is why so much interview process right now is theater.
This isn't an argument that anything goes. Some things really are cheating, and I'll say plainly what they are. But most of what companies currently ban isn't cheating — it's just normal work, happening somewhere you didn't expect it.
"No AI" was never enforceable, and now it's also wrong
Start with the practical problem. You cannot detect AI use reliably, and every year makes that truer. A candidate on a video call can have a second monitor, a second device, or a browser tab you can't see. Short of physically isolating someone in a room you control — which no remote process does — a "no AI" rule is one you're trusting people to self-enforce, for a behavior you've told them not to admit to.
Set enforceability aside anyway. Even a perfect ban measures the wrong thing. Your candidate's actual job, from day one, involves an AI assistant open in their editor. Interview them in a no-AI room and you've tested coding from memory, unaided — a skill with little bearing on how they'll spend their time once hired. You didn't catch a cheater. You built a screen that predicts nothing.
The honest reframe: AI in the interview isn't a threat to control, it's a fact to design around. The question changes from "how do I stop this" to "what do I need to see, given that this is happening."
The real problem was never the tool
Here's what actually worries hiring managers, once you push past "AI" as a buzzword: not knowing whether the candidate can tell good output from bad. An assistant will hand back code that compiles, passes the sample test, and is wrong in a way that only shows up under load, under concurrency, or on an input nobody thought to try. A candidate who pastes that in unexamined and a candidate who reads it, spots the flaw, and fixes it are having completely different interviews — even though their screens look identical for the first ninety seconds.
That distinction — can they evaluate what the tool gives them — is the actual skill gap AI exposed. It was always there. Engineers copy-pasted from Stack Overflow without understanding the caveats long before language models existed; AI just made the failure mode faster and more convincing, because the output reads as confident and tailored to the exact question asked. The tool changed. The judgment you need to test for didn't.
So the goalpost isn't "did they use AI." It's "when the AI was wrong, did they notice, and could they say why." That's testable. It just requires a different kind of interview than most companies are running.
What actually is cheating
It's worth being precise here, because "cheating" gets used loosely enough to cover both fraud and normal tool use, and conflating them wrecks your process either way.
Real cheating: someone else does the work and the candidate presents it as their own. A friend solving the problem live on a shared screen while the candidate types along. A pre-written solution memorized for a known interview question and reproduced as if generated in the moment. Someone hired as a stand-in to complete an async take-home under the candidate's name. These are misrepresentations of authorship — the interview stops measuring the person who'll show up to work.
Not cheating: using an AI assistant to draft code, look up an API, or suggest an approach, then evaluating, editing, and taking ownership of the result — the same way a linter, a search engine, or a senior teammate's advice was never cheating. The line isn't "did a tool touch this code." It's "does the artifact and the explanation both belong to the candidate." If they can defend every choice in it, under follow-up questions, it's theirs — regardless of what typed the first draft.
This is the same line good take-home policies already drew for open-book exams: tools and references are fine, impersonation isn't. AI didn't invent the distinction. It raised the stakes of getting it wrong, because the tool is good enough now that the line blurs by accident, not just on purpose.
Detection theater doesn't work
Once you're clear that most AI use isn't cheating, most of the detection tooling on the market looks different — expensive machinery aimed at a problem that's smaller than advertised, with a real cost in false positives and candidate trust.
Webcam proctoring watches for eye movement and "suspicious" glances, on the theory that looking away means consulting a hidden resource. It also flags people checking notes, glancing at a second monitor for legitimate reasons, or just having a normal human eye-line. It optimizes for looking compliant on a recording, not for measuring engineering skill, and it tells every candidate on day one that you don't trust them.
Keystroke and typing-cadence analysis assumes AI-assisted typing has a detectable rhythm — bursts of paste, unnaturally even spacing, whatever the vendor's model claims to catch. Candidates who type in bursts because they think before they type, or who paste their own boilerplate from a personal snippet library, get flagged for habits that predate AI by decades.
"AI detector" tools that score text or code for probability-of-AI-origin are the least reliable of the three. They're trained to distinguish stylistic patterns, not authorship, they carry well-documented false-positive rates against non-native English writers and terse coding styles, and a candidate who runs AI output through a light rewrite defeats them trivially.
None of these tools answer the question you actually care about: can this person build something correct and explain why. They answer a different, easier, less useful question — does this session pattern-match something a classifier associated with AI use — and they answer it badly.
The check that actually works: does the reasoning match the artifact
There's a much cheaper, much more reliable signal, and it doesn't require any special tooling: ask the candidate to explain what's in front of you, in detail, and see if the explanation holds up.
A candidate who wrote or genuinely understands the code can tell you why a particular data structure was chosen, what happens if you double the input size, and what the failure mode is if two requests race. Their explanation tracks the code line for line, because it came from the same place the code did.
A candidate who pasted in AI output without engaging with it can usually gesture at the general shape of what it does, but the explanation goes generic or thin exactly where you push on detail. They can say what the function does; they struggle with why it's structured that way instead of an obvious alternative. The mismatch between a polished artifact and a shallow account of it is the tell — not because AI use is inherently suspicious, but because unexamined AI use produces exactly this gap.
This divergence check works whether or not AI was involved at all. It catches a memorized solution from a friend just as well as an unexamined AI answer. It's not new technology; it's an interviewer asking real follow-up questions and listening to whether the answers hold together. That makes it cheap, hard to game, and the best return on interviewer time of anything discussed here.
Redesign the screen so the question stops mattering
The deepest fix isn't a better detector. It's a screen where "did they use AI" stops being interesting because you're testing something AI use doesn't threaten.
Give the candidate a real, moderately-sized codebase and a real task — a bug fix, a small feature — not an isolated puzzle with one clean answer. Let them use an AI assistant openly, the way they would on the job, instead of forcing it underground. Then build in a defense: five or ten minutes at the end where they walk you through the decisions, including the ones where they overrode or edited what the assistant suggested. Score correctness, yes, but also judgment — did they catch the plausible-but-wrong suggestion, and can they say why.
Once the interview measures direction and understanding instead of raw artifact production, "cheating" stops being a live question, because there's nothing to cheat at. Pasting in code you can't explain fails the defense round on its own; using AI well and explaining your choices clearly is just what a strong hire looks like. You stop running a policing exercise and start running an assessment. For a longer walkthrough of building a screen this way, see our piece on how to screen engineers when everyone uses AI, and our comparison of take-homes versus live, defended screens if you're deciding which format to move to.
We built Chiron's AI coding assessment around exactly this shape — a real task, an AI pair in the room, and a defense that scores whether the reasoning matches the code — because that's the only version of this problem worth solving. But you don't need our product to apply the underlying idea: stop asking whether AI was in the room, and start asking whether the person can defend what's on the screen.