An AI code detector is a tool that estimates the probability that a given block of source code was written by a large language model rather than a human. If you are evaluating one to gate pull requests or screen contributions, the honest answer is that a code AI detector is a probabilistic signal, not a verdict, and treating its output as proof will burn you. This guide explains how these detectors work, why they misfire, and where they genuinely help a security program.
How an AI code detector actually works
Most detectors fall into two camps. The first camp trains a classifier on large corpora of human-written and model-generated code, then scores new samples against the patterns it learned. The features can include token-level predictability, comment style, naming regularity, and structural uniformity. Model-generated code tends to be more "average" than human code, and detectors lean on that regularity.
The second camp measures statistical properties directly, without a labeled training run. Perplexity and burstiness are the common metrics. Perplexity captures how surprising a sequence is to a reference language model; text that a model finds highly predictable scores low. Burstiness captures variation in that predictability across a sample. Human code tends to be burstier: idiosyncratic in places, sloppy in others. Generated code is smoother.
Both approaches produce a confidence score. The critical thing to internalize is that these are correlational signals about style, not proof of authorship. Nothing in the code carries a reliable, tamper-proof "made by AI" marker.
Why detectors produce false positives and false negatives
The failure modes matter more than the marketing accuracy numbers, which are usually measured on clean benchmark data that looks nothing like your monorepo.
False positives cluster around code that is naturally regular. Boilerplate, generated stubs, configuration files, and code written by a careful engineer following a strict style guide all look "too clean" to a detector. Non-native English speakers writing comments have been flagged disproportionately by text detectors, and the same bias shows up in code documentation. Punishing a contributor over a false positive is both unfair and a good way to lose good developers.
False negatives are just as easy to trigger. A developer who takes model-generated code and lightly edits it, renames variables, or runs it through a formatter can push the sample back across the boundary. Anyone motivated to evade detection can do so with minimal effort. The arms race favors the evader.
Where a code AI detector helps a security program, and where it doesn't
Detection of authorship is the wrong goal for security. Whether a function was typed by a human or generated by a model tells you almost nothing about whether it is safe. Machine-generated code and human code both ship vulnerabilities. The interesting security questions are downstream:
- Does this code call a dependency that does not exist? Model-hallucinated package names are a real supply-chain risk, sometimes called slopsquatting, where attackers register the fabricated names.
- Does it embed a secret, a weak crypto call, or an injection-prone query pattern?
- Does it pull in a transitive dependency with a known CVE?
None of those require knowing who or what wrote the code. They require scanning the code and its dependencies. A software composition analysis pass catches the vulnerable-dependency case regardless of authorship, and static analysis in your pipeline catches insecure patterns. That is where the budget should go.
There is one legitimate use for an AI code detector in a security context: as a soft signal in provenance and review workflows. If a large, unattributed contribution to a sensitive repository scores as highly likely machine-generated, that is a reasonable prompt to apply extra human review, not to reject it outright. Use it to route attention, never to make an automated accept or reject decision.
A practical policy that does not blow up in your face
If you decide to deploy a detector, write the policy first. A workable one looks like this:
1. Detector output is advisory only. It never auto-blocks a merge.
2. A high AI-likelihood score on a large diff triggers mandatory
human review, not rejection.
3. Every contribution, regardless of score, passes SCA + SAST gates.
4. No individual contributor is disciplined on detector output alone.
5. The real gate is: does the code introduce a known vulnerability,
a hallucinated dependency, or a secret?
This keeps the detector in its lane. It also means the security outcome does not depend on a tool that a motivated author can defeat with a formatter.
Testing a detector before you trust it
Vendor accuracy claims are close to meaningless until you test on your own code. Build a small evaluation set from your real repositories: a sample of known human-written commits from before generative coding tools were common, and a sample you generate and lightly edit yourself. Measure the false-positive rate on the human set specifically. If it flags more than a small fraction of genuine human code, it will generate more friction than value.
Also test evasion. Take a generated sample, run it through your standard formatter and a rename pass, and re-score it. If the score collapses, you have quantified exactly how fragile the signal is.
FAQ
Can an AI code detector prove code was written by AI?
No. A code AI detector produces a probability based on stylistic and statistical patterns, not proof. There is no reliable, tamper-proof marker in generated code that guarantees authorship, so the output should always be treated as a soft signal.
Are AI code detectors accurate?
On clean benchmark data they can look accurate, but on real-world repositories they produce meaningful false positives, especially on boilerplate and carefully styled code, and are easily defeated by light editing or reformatting. Test any tool on your own code before trusting it.
Should I block pull requests that a detector flags?
No. Blocking on detector output alone punishes false positives and is trivial to evade. Use the score to route flagged contributions to extra human review, and rely on dependency and static-analysis scanning for the actual security decision.
What is the real supply-chain risk from AI-generated code?
The biggest concrete risks are hallucinated dependencies (fabricated package names an attacker can register), embedded secrets, and pulled-in libraries with known vulnerabilities. These are caught by scanning code and dependencies, not by detecting authorship.