Article AI and Hiring
Why detecting AI use is the wrong question
In short
Detection asks whether a candidate used AI. Assessment design asks whether the work is good and how it was produced. Codility does detect: AI helper apps hidden from screen sharing, retyped or pasted code, and matches to other submissions, as evidence for a reviewer. Nobody can reliably read AI authorship off the code itself, and a hiring decision built on that guess cannot be defended.
- AI writes a growing share of the code developers commit: 29 percent of Python functions from United States contributors in early 2025, up from 5 percent in 2022. The stylistic signals that AI authorship detectors depend on fade as that share grows.
- Codility does detect. Cheating apps detection is designed to surface AI helpers hidden from screen sharing, typing pattern detection flags code retyped from another screen, and similarity check compares a submission with other candidates’ work. Each is evidence for a reviewer, and none is a verdict.
- A false positive costs twice: a capable candidate lost, and a hiring decision you cannot defend when it is challenged. No integrity signal triggers an automatic rejection.
- When AI is allowed, make it visible. Every interaction with the AI Copilot or Claude Code is captured as reviewable AI activity, so the reviewer evaluates how the candidate directed the tool.
- Ask a vendor what evidence you get from each assessment, who makes the final call on a flagged result, and what survives an audit. A detection claim answers none of them.
Can AI-written code actually be detected?
Sometimes, and less reliably every year. I hear the detection question on most customer calls, usually before any other, and I understand why. A shortlist built on work the candidate did not do is the failure a talent leader fears most. So it is worth being precise about what AI code detection can and cannot do.
Start with how much code AI now writes. Research published in Science by Daniotti, Wachs, Feng and Neffke attributes 29 percent of Python functions from United States contributors to AI as of early 2025, up from 5 percent in 2022. The study drew on more than 30 million Python contributions by roughly 160,000 developers on GitHub.
As that share grows, the stylistic tells that AI authorship detectors depend on fade, because model output and human output converge. No tool can honestly promise to catch every use of AI by reading the code, and nobody can honestly promise that AI use leaves no trace either. That uncertainty is why I would never let a hiring decision rest on a guess about who wrote a function.
Notice what that argument covers, though. It covers one kind of detection: inferring AI authorship from the finished code. It says nothing about detecting the tools a candidate runs or the way the work arrived on the screen. Those are different problems, and they are far more tractable.
What does Codility detect, then?
Quite a lot, and I want to be plain about it, because the title of this piece is sometimes read as a claim that detection does not matter. At Codility we do detect AI use. We are careful about what we claim to detect, and about what happens after we detect it.
The clearest case is the class of AI helper that sits in an overlay window built to hide from screen sharing. To standard proctoring, a session using one looks clean. Cheating apps detection, delivered through a lightweight desktop app that candidates take the assessment inside, is designed to surface those hidden layers. It is in available for every account today, on macOS and Windows. It is optional to use as it is a higher proctoring level; having candidates take assessments in a browser is always available as an option.
Around it sit the signals that catch AI use arriving by other routes. Typing pattern detection is designed to flag a solution retyped character by character from a second screen, which is what paste detection misses. Paste events, tab switches, focus loss and sudden large insertions all sit on the code evolution timeline, so a reviewer can jump to the moment. Similarity check compares a submission with other candidates’ work and with known solution patterns. Identity verification confirms who is at the keyboard before any of it starts.
Then comes the part that matters most. These signals aggregate into an integrity risk level, None, Low, Moderate or High, by deterministic rules with no generative AI in the scoring. A hidden tool surfaced by the desktop app moves the level to at least High. And the level is where the automation stops. Codility does not fail a candidate. It puts the evidence in front of a person, who decides.
So the detection I argue against is narrow: reading AI authorship off the code and treating the result as an answer. The detection we do is about tools and behavior, it produces evidence a reviewer can inspect, and it never becomes a verdict on its own. Our guide to preventing cheating in coding assessments walks through each layer.
What does detection cost when it is wrong?
A false positive costs you twice. When a signal wrongly flags honest work and someone acts on it, you lose a capable candidate, and you are left holding a hiring decision you cannot defend if the candidate, a regulator or your own leadership asks how it was made.
This is why the human step is a design principle and a matter of compliance at the same time. A flag is an input to review. A person confirms it against the evidence, or clears it. A reviewer who opens a High risk record and follows the timeline can find a candidate who was working exactly as the assessment allowed. That outcome is the system working, and an automatic rejection would have got it wrong quietly.
What does design-first assessment look like?
Design-first assessment lowers the stakes of detection by changing what you measure and what you can see. Work simulations reward engineering judgment, so an answer generated without understanding tends to score poorly on its own. Some tasks seed deliberate mistakes a candidate has to catch, which puts verification under test rather than recall.
Then there is the choice of AI posture, and I think it is the most important decision on the page. The AI Copilot and Claude Code run across Screen, Interview and Skills Intelligence, and they are enabled or disabled per assessment. With AI off, the controls above do their work. With AI on, every candidate interaction is captured as reviewable AI activity, and each task carries a summary of the models used, the number of interactions and the tokens spent, in Preview today. Permitted AI becomes something a reviewer can read rather than guess about.
Either posture gives you a complete record. The difference is the question you are asking. Off asks whether the candidate has the unassisted skill the role needs. On asks whether they can direct the tool well, which is closer to how the job is done now. You choose per assessment, and you defend either answer with evidence rather than inference.
What should you ask your assessment vendor instead?
Ask three questions that a detection claim never answers.
- What evidence do I get from each assessment?
- Who makes the final call on a flagged result?
- What survives an audit when a candidate or a regulator challenges the decision?
A platform that answers all three gives you a defensible hiring decision under either AI posture, and it is the standard I would hold Codility to as well. For the policy side, how to set an AI posture for a role and write it down, start with how AI fits into technical assessment.
About the author
Christopher Greco is Head of Product Marketing at Codility, where he owns how the platform is positioned across Screen, Interview and Skills Intelligence, and works alongside the Assessment Science team behind the Engineering Skills Model. He came to hiring from the other side of the AI question: before Codility he led product marketing for AI data and model evaluation at Toloka, serving frontier AI labs and large technology companies. He has also built marketing teams from nothing three times, so the hiring problems he writes about are ones he has had himself. He is based in Rome.
Frequently asked questions
Can employers detect AI-generated code?
Not reliably from the code alone, and less so over time. AI-written code increasingly resembles human work, so tools that infer AI authorship from style produce false positives and misses. What can be detected with more confidence is the tooling and behavior around the work: AI helper apps hidden from screen sharing, code pasted or retyped from another source, and submissions that match other candidates. Those signals inform a human reviewer, and none is accurate enough to carry a hiring decision on its own.