How to detect AI generated code: start with the author
You detect AI generated code mainly by testing the author, not the code. Learning how to detect AI generated code means accepting that the file alone rarely settles the question, while a ten-line change request often does.
Use three layers in this order of weight: process evidence (explanation, history, live work), then reading signals, then a detector score. The rest of this guide covers each layer and how to combine them fairly.
Before you start, be clear about what you are trying to establish. “Was any AI involved?” is often unanswerable and, where assistants are allowed, beside the point. “Did this person follow the rules and understand what they submitted?” can be answered, and it is the question that matters for grades and hiring decisions.
Why is AI-generated code so hard to judge?
AI-generated code is hard to judge because good human code is supposed to be predictable. Style guides, linters, formatters and design patterns all push programmers toward the same choices a model would make.
- Formatters rewrite spacing, quotes and line breaks, erasing personal style.
- Boilerplate such as setup code, tests and data classes looks the same whoever writes it.
- Developers have always copied from documentation, tutorials and forums.
- Autocomplete assistants in the editor blend human and AI code line by line.
- Short functions, which are good practice, give a detector very little to measure.
Code also changes shape constantly for ordinary reasons. Routine refactoring, code review suggestions and automatic formatting reshape the surface of a file without changing its logic. Text and images leave richer traces; code that compiles and passes tests can look the same whoever, or whatever, wrote it.
There is also a policy problem: in many workplaces, AI coding assistants are allowed or encouraged. The useful question is often not “did AI write this?” but “does the author understand it, and was the use allowed?”
Which signals suggest AI-generated code, and why are they weak?
The usual signals of AI-generated code are about polish and context: comments that explain the obvious, generic names and solutions that ignore the local codebase. Each has a common human explanation.
| Signal | What it looks like | Why it is weak |
|---|---|---|
| Narrating comments | A comment above every line saying what the line does | Beginners are often taught to comment this way |
| Generic names | data, result, helper, process_items | Common in quick scripts written by anyone |
| Style mismatch | A submission far cleaner or more advanced than the author’s other work | People learn, pair-program and get reviews |
| Ignores context | Re-implements a utility the project already has, or uses a different library | New team members do this too |
| Defensive extras | Input validation, error handling and docstrings far beyond what the task asked | Some developers are simply thorough |
| Plausible but wrong APIs | Calls to functions or options that do not exist in the library version used | Humans misremember APIs, though usually notice when the code fails |
The last signal is the most telling: code that calls nonexistent APIs and was clearly never run. It shows the author did not test the work, whatever produced it.
Look also for what generated code tends to lack: knowledge that lives outside the file. Team naming conventions, a workaround for a known bug in your stack, a comment referring to a past incident or a ticket number all point to someone who worked inside the project. Their absence is not proof of anything, but their presence is a good sign of human context.
What process checks work better than an AI code detector?
Process checks work better than any AI code detector because they test understanding, which is what you actually care about. They are also fairer: an honest author passes them easily.
Ask the author to explain
Pick two or three non-trivial parts and ask why they work this way. Ask what happens with an empty input, why a given data structure was chosen, or what the slowest part is. Authors who understand their code answer in their own words, even if they used an assistant.
Read the commit history
Real work usually leaves a trail: small commits, false starts, fixes after failing tests. One large commit containing a finished, polished project is worth a question, though some people simply commit late.
Ask for a live change
Ask the author to add a small feature or fix a planted bug while sharing their screen. Someone who wrote or truly understood the code finds their way around it quickly. Allow them to use the tools the rules permit; you are testing understanding, not memory.
Hold a short oral defense
In teaching, a brief oral defense of a project is a long-standing practice. A few questions per student tell you more than any score, and they reward learning rather than detection avoidance.
How do you use an AI code detector function by function?
You use an AI code detector to rank which functions deserve questions, then you ask those questions. A score for a whole file hides more than it shows, because real projects mix generated, copied and hand-written parts.
The AnyFact AI code detector uses the same Fast-DetectGPT method as our text detector, with a code model (Qwen2.5-Coder), and scores each function separately. It accepts at least 30 non-empty lines and up to 5,000, in Python, JavaScript, TypeScript, Java, C, C++, C#, Go, PHP, Ruby and Rust.
- Submit the core logic: the functions that solve the actual problem, not imports, tests or configuration.
- Use the code as the author submitted it, before your own reformatting or fixes.
- Compare the flagged functions with those that were not flagged. A contrast inside one file is more informative than one high score.
- Note which functions are boilerplate any developer would write the same way, and set them aside.
AI Code Detector · Free plan
Paste 30 lines or more and see which functions look generated, with the limits stated.
What does a fair review of suspicious code look like?
A fair review moves from evidence to questions to a decision, and records each step. Here is how it can run for a typical case: a student project, or a candidate’s take-home test, that looks more polished than expected.
- 01Re-read the rules that applied. Was AI assistance banned, allowed with disclosure, or not mentioned at all?
- 02Run the code and its tests. Note anything that fails, calls nonexistent APIs or ignores the brief.
- 03Run a detector function by function and list the two or three functions it flags most strongly.
- 04Compare those functions with the author’s other work and with the commit history.
- 05Meet the author. Ask them to explain the flagged functions and to make one small change live.
- 06Decide on the conversation, not the score. Record what was asked, what was answered and why you concluded as you did.
If the author explains the code fluently and modifies it with ease, the score loses most of its weight, whatever it said. If they cannot explain code they submitted as their own, you have a problem worth acting on, and the detector result was only the reason you looked.
Are AI code detectors accurate?
AI code detectors are less accurate than text or image detectors, for the reasons above: code is conventional, short functions carry little signal, and editors blend human and AI suggestions.
A ChatGPT code detector works the same way as one for any other model: it measures how predictable the code is. That predictability is also what clean, idiomatic human code looks like. Our guide on whether AI detectors are accurate explains the false positive problem in depth, and the parallel case of prose is covered in how to tell if text is AI generated.
Some practical consequences follow. Tests, configuration files and simple data classes are poor material for any detector, so leave them out of your judgment. Longer functions with real logic carry more signal. And a result on code that was formatted, renamed or refactored by a tool says more about the tool than about the author.
Code is often submitted with a written report or README. The prose is easier to judge than the code: run it through the ChatGPT detector and compare what the author wrote about the code with how they explain it in person.
How should teachers and hiring teams handle AI-generated code?
Teachers and hiring teams should handle AI-generated code with a written policy that says what is allowed, how understanding is checked and what a detector result can and cannot trigger. Rules set in advance are fairer than judgments made case by case.
For teachers
- State per assignment whether AI assistants are banned, allowed with disclosure, or required.
- Ask students to submit their commit history or a short log of how they built the work.
- Grade part of the work through a short oral defense or an in-class modification.
- Design tasks tied to class material, local data or earlier assignments.
- Treat a detector flag as a reason to talk, never as evidence of misconduct on its own.
Our page for teachers and schools covers how to fit detection into an academic integrity process.
For hiring teams
- Tell candidates whether AI assistants are allowed in the take-home test, and mean it.
- Follow every take-home with a review call where the candidate explains and extends their code.
- Score reasoning, trade-offs and debugging, not just the final output.
- If you allow AI tools, assess how well candidates review and correct generated code.
For screening written answers and cover letters as well as code, see our guide for hiring and recruiting teams.
AI Text Detector · Free plan
Screening a written answer alongside the code? Check the text passage by passage.
Frequently asked questions
Can you tell if code was written by ChatGPT?
Not reliably from the code alone. Some signals and a detector can raise suspicion, but the dependable test is to ask the author to explain and modify the code. Clean, idiomatic human code often looks just like model output.
Which programming languages does the AnyFact code detector support?
Python, JavaScript, TypeScript, Java, C, C++, C#, Go, PHP, Ruby and Rust. The code needs at least 30 non-empty lines and can be up to 5,000 lines. A code analysis costs 1 credit.
Do comments reveal AI-generated code?
Sometimes, but weakly. Comments that narrate every line are common in generated code and also in beginner code. Many developers also delete or rewrite comments, so their absence tells you nothing.
Is it cheating to use an AI coding assistant?
It depends on the rules set by your school, employer or test. Many workplaces allow assistants. What matters is following the stated policy, disclosing use when asked, and understanding the code you submit.
Why does the detector score each function separately?
Real code mixes hand-written, copied and generated parts. Scoring each function shows where the suspicious parts are, so you can ask targeted questions instead of judging the whole file at once.
Can I upload a whole repository to the AI code detector?
The detector accepts at least 30 non-empty lines and up to 5,000 lines of code per analysis. For a larger project, pick the files that matter most, such as the core logic rather than tests or configuration.