How to Check if Code Is AI Generated

Every tool that ranks for this question wants the same thing from you: paste the code into the box, wait, read a percentage back. On 26 August 2026, five of the ten results on the first page of Google for check if code is ai generated were a detector product. Two more were students and instructors arguing about academic integrity, one was a video, one was a forum thread, and exactly one was an article written for a reader.

None of them is written for the person who most often asks. That person paid an invoice, has a working app, cannot read a line of what is inside it, and is not trying to catch a student. They are trying to work out what they bought.

Reading the code is the weakest way to check if code is AI generated, and the repository’s own record of who committed what is the strongest. Detectors that rank for this question claim 95 to 99 percent on their own pages, and on the hardest published benchmark of the same task every model scored below a random guess.

The five giveaways in the table below were read off the pages that rank for this question on 26 August 2026, and each one is set against what the largest published measurement of AI-written code in real repositories reports for that same property. No detector was run, no repository was opened, and where a vendor states a number about its own product, that number is quoted from the vendor’s own page rather than tested here. The commit behaviour in the second section was read the same day from git’s own documentation and from GitHub’s, and it describes what those pages document rather than what any one repository contains.

None of the companies named below is linked. They sell in the same categories I do, so they get named and quoted and nothing more.

Is there a way to check if code is AI generated by reading it?

Reading the code does answer the question, and it answers it badly. The five giveaways published by the one real article ranking for this search describe properties the largest measurement of AI code in real repositories found to be too small to separate the two groups, backwards, or real but invisible to a reader.

That article is a five-item list published by the development company diatomenterprises.com on 9 February 2026, and it is the one written for a person rather than a paste box. It tells readers, in its own words, that “you don’t need a specialized tool to check if code was written by AI … you just need to know what to look for”. Its five headings are what almost every other list on this subject also says.

The measurement to set them against is a paper titled “A Large-Scale Comprehensive Measurement of AI-Generated Code in Real-World Repositories”, now on its third version, dated 1 July 2026, which is the version this page reads. It finished with 19,816 AI-involved code files across 12,749 commits, matched against 15,424 human files from the same repositories, the same languages and a settled period before each project’s first AI commit. Every file in it came out of a real repository rather than a controlled study.

Two of those five die on contact, and they are not the two you would guess. Flawless syntax with flawed logic is the second: the current version has the AI code triggering fewer static-analysis alerts per thousand lines than the human code it was matched against. A lack of personal style is the third, and the direction is backwards, so if repetition is your tell you will point it at the wrong half of the repository. The comment giveaway survives, on volume only.

Across a set of metrics it calls substantially broader than any earlier study, the paper reports that “we do not observe practically large differences between likely AI-generated and matched human-written code”, and states it as its first insight: “AI-generated code is structurally similar to human code”. The properties a reader can see are the properties that barely differ.

The paper also makes the point against itself. Its second version, dated 3 April 2026, put the comment ratio at 18.01 percent in the AI files against 17.96 percent in the human files, and had AI code triggering more alerts, 12.81 per thousand lines against 11.58. Three months later, on a rebuilt and larger matched set, the same team published the opposite on both. The measurement with the most data on this question changed direction on two of its own findings.

I read the commit-size results too and am printing their direction, not their numbers. The third version states it in words, that AI-involved commits “involve fewer files and significantly lower line churn per commit compared to human-written code”, and charts the values. The second version’s table gave a files-changed figure of 92.85 with a standard deviation of 2014.33, which cannot be a count of files in one commit, and never stated a unit. Full details are in the measurement paper itself.

What is left is the fourth and fifth giveaways, and they survive for a reason that should change what you do next. Methods that do not exist and failure paths nobody handled are real, and both are things the app tells you by breaking rather than things a reading reveals. What changes when the person you paid used AI tools, and where their work is likely to be thin because of it, is answered where that job is set out in full.

The repository keeps a record, and it is better than the code

Nobody on any of those search results mentions the one place that stores a name. Not the detector pages, not the article, not the forum threads. A git commit records who wrote the change and who applied it, as two separate fields, and that record exists whether or not anyone thought about it at the time.

One builder wrote publicly that their shipped product runs to tens of thousands of lines of code and thousands more of documentation, and that they typed none of it. That is the whole reason these fields matter. The code cannot tell you that. The commit log can.

Git’s own commit documentation sets out both fields plainly. Author and committer information is taken from the environment variables GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL when they are set, and falls back to the user.name and user.email configuration items when they are not. The author is whoever wrote the change. The committer is whoever put it into the branch. Most of the time they are the same person and nobody ever notices there are two.

The third field is the message, and git treats the bottom of a message as structured. The same page documents a --trailer option that applies a token and value pair to the commit message, and the first half of its own example is git commit --trailer "Signed-off-by:C O Mitter <committer@example.com>", and points at the trailer.* configuration variables for how duplicates and ordering are handled. That is the machinery every agent tool uses to sign its work.

GitHub built one convention on top of it that you can read without knowing any of the above. GitHub’s page on creating a commit with multiple authors documents the format as Co-authored-by: name <name@example.com>, placed after the commit description with an empty line before it. Which tool leaves which mark in a repository is compared platform by platform elsewhere, with the file names and the commit addresses each one writes.

GitHub’s own agent is the clearest documented case, because GitHub writes down exactly what it does. The application card for GitHub Copilot Agents says “The cloud agent’s commits are authored by Copilot, with the human who started the task marked as the co-author.” It says “The cloud agent’s commits are signed, so they appear as ‘Verified’ on GitHub.” It says “Each commit message includes a link to the agent session logs.” Three sentences on a vendor’s own page, and between them they answer the question this whole article is about, for one tool, with more certainty than any percentage.

If you have access to the repository, or you can ask somebody who does, this is the line to send them:

git log --format='%h %an <%ae> | committer %cn <%ce> | %s%n%(trailers:key=Co-authored-by)' -20

Git’s pretty-formats reference defines those placeholders as abbreviated commit hash, author name, author email, committer name, committer email and subject. What comes back is twenty lines, one per commit, each starting with a short string of letters and numbers, then a name and an email address, then the word committer and a second name and address, then the first line of the message, with any Co-authored-by trailer on the line under it. Twenty commits is a sample; drop the -20 to read the whole history. You are looking for three things: an author email at a company domain you do not recognise, an author name and a committer name that differ, and any Co-authored-by line in the messages themselves. Getting the code back to a state that worked is a separate procedure from working out who typed it, and it runs on the same history.

Now the half that the pages selling detection never print. Every field above is writable. Git’s commit documentation includes an --author option that overrides the commit author outright, and a --reset-author option that declares “the authorship of the resulting commit now belongs to the committer”. The environment variables are environment variables. Anyone with a shell can set them.

The trailers are a setting. Claude Code’s settings reference documents an attribution setting described as “Customize the attribution Claude Code adds to commits and pull requests”, with an attribution.commit sub-key whose documented job is to “Change or hide the trailer Claude Code adds to commits”. The older includeCoAuthoredBy setting is marked “Deprecated; use attribution to hide or change commit and PR attribution”. That page does not print a default value for attribution.commit, so this article does not state one.

And the record is incomplete at the edges. As of 26 August 2026, the GitHub Copilot pages read for this article document commit attribution for the cloud agent only. Nothing on them describes a mark left in a commit by inline completions accepted in an editor, which is how a great deal of AI-written code actually enters a repository. A developer typing in their editor with a suggestion engine running commits under their own name, correctly, because they did commit it.

So the commit record is the best evidence available to you and it is optional, removable and partial. Both halves of that are true at once, and a page that gives you only the first half is selling something.

What the AI code detectors claim on their own pages

A tool to check if code is AI generated is easy to find and hard to evaluate, because every number you can read about one comes from the company that sells it. Here is what four of them claim, read on 26 August 2026 from each vendor’s own page, except Span, whose figures come from its founder’s launch thread.

The most useful page in that table is the one whose caveats are longest. Pangram’s post of 3 April 2026 on checking whether code was written by ChatGPT, Copilot or Claude states in its body that the product “is intentionally conservative”, and explains why: “This is to ensure that it never falsely accuses a human developer.” The same post gives a false negative rate of 8.5 percent on long snippets and says the product “is designed to miss some AI boilerplate”. A vendor telling you what its product deliberately fails to catch is more informative than a vendor telling you it is 96 percent right.

Two details in that table decide whether any of this is usable for you. The Span figures come from the product’s launch thread on Hacker News rather than from a product page, and the same thread carries the founder’s own answer that the model is still largely opaque to them. The GPTZero row is an absence rather than an accusation: its 99 percent claim is about text, and as of 26 August 2026 the page read for this article does not claim to detect source code at all. Text detection and code detection are being sold in the same aisle and they are not the same product.

Three more names rank on these searches and none of them is quoted here. decopy.ai sells a code detector and ranked third on the primary question. copyleaks.com and originality.ai are text detectors that ranked on the accuracy question, and copyleaks.com returned an HTTP 403 to a fetch on 26 August 2026, so nothing it claims about its own accuracy appears anywhere on this page.

The same unsolved problem is running in other fields, in exactly the same wording. An r/musicmarketing thread from August 2026 was titled “How to tell if album artwork is AI generated?”. Nobody has a clean answer there either, and for the same reason: the thing being detected keeps getting better at looking like the thing it is being compared to.

Why 96 percent and worse than random are both true

Both numbers are honest measurements of different situations, and not of the same products: the benchmark tests research detectors and general models, and the vendors above did not publish results on it, so carrying its result over to a vendor percentage is an inference about the kind of tool rather than a test of that tool. A vendor measures its detector against the distribution it trained for: languages it supports, snippet lengths it was tuned on, generator models it has seen. A benchmark built to be hard measures the same detectors against code they were not trained for, which is the situation you are in when a stranger hands you a repository.

AICD Bench, published on 2 February 2026 by researchers at MBZUAI, TU Darmstadt and INSAIT, is that benchmark. It holds 2 million examples covering 77 models across 11 families and 9 programming languages. Its robust binary classification task is the plain question of whether a machine wrote this code, and nothing tested on it beat a guess. The highest Macro-F1 in that column of the results table is 44.99, from a zero-shot detector; the best trained model, which the table marks as the best model on the task, is a plain SVM on word-frequency features at 43.05; the strongest transformer detector is 34.13. A random guess scored 45.73 and always answering “human” scored 43.83. Every one of those numbers sits under the random baseline. The paper’s own sentence: ”… both random and majority-class baselines achieve even higher scores …”. Its conclusion puts it in words, that “a simple SVM outperforms deep learning models on robust binary classification, yet still performs below random guessing”, and that “Current detectors struggle to generalize across programming languages, domains, and generator families, and perform particularly poorly on hybrid and adversarial code”.

Hybrid code is the case that matters most and the case that is measured worst. Almost nobody ships pure generated code or pure hand-typed code any more. They ship a file an agent drafted and a person edited, or a person drafted and an agent extended.

The people who read code for a living are asking the question out loud. An r/cscareerquestions thread from August 2026 was titled “Mid to senior level devs, how much are you even reviewing AI written code? Do you …”, which is worth reading twice. The question those reviewers are putting to each other is how much of it they read at all. If the people who do this for a living are unsure how much of what they read was generated, a classifier trained on last year’s models is unlikely to settle it for you either.

There is a cost to getting this wrong, and the clearest statement of it comes from people who deal with the fallout weekly. MIT Sloan’s teaching guidance on AI detectors says the software “is far from foolproof … it has high error rates and can lead instructors to falsely accuse students of misconduct”, and notes that “OpenAI, the company behind ChatGPT, even shut down their own AI detection software because of its poor accuracy”. Read that guidance before you take a percentage to a person you paid and call it evidence.

Four people ask this question and only one of them is you

The autocomplete suggestions under this search split four ways, and the split is a list of four different readers with four different problems.

Instructors and students take a large share of it. can professors tell if code is ai generated and can teachers tell if code is ai generated are both suggested phrases, and two of the ten primary results are pages where the asker’s stake is academic. Their question is disciplinary and their stakes are somebody’s academic record.

Engineers reviewing pull requests are the third group, and their question is about the quality of a change rather than its origin. They can read the code, which is the one advantage nobody else in this list has.

The fourth is the owner, and the owner’s version of the question is the one with money attached. check if my code is ai generated is a suggested phrase. So is check if code is ai generated python, and so is check if code is ai generated reddit, which is a searcher telling Google plainly that they do not trust the tool pages.

Line those four up and one pattern falls out. The detectors work least well on out-of-distribution code, and the use with the highest cost is the accusation. Whichever of the four you are, the moment you use a percentage to accuse a person is the moment you are relying on the number the benchmark says is worse than guessing. Buying a product somebody else built raises something this page leaves alone, which is whether what you are being shown can be transferred to you at all.

What the answer changes

Start with how the largest measurement of AI code in real repositories found its own AI-written corpus, because it is the argument in one fact. To find AI-written code at that scale, the researchers started from files whose own comments named the tool that wrote them, searching for six prefix words in front of eleven tool names, then filtered those mentions three ways and put a model on the cases the rules could not settle. No detector was run over GitHub at all. The team with the most data on this question could only assemble its corpus because the code said so about itself in writing. Authorship is something a record tells you, and no amount of reading recovers it.

Whether a machine typed it matters less than the search volume suggests. In the fixed study of 26 AI-built applications AxonBuild audited in June and July 2026, a live prompt-injection path was confirmed in 8 of the 14 third-party apps in it that shipped an AI feature at all, meaning a visitor could type instructions into the product and have the product follow them. That denominator of 14 is the third-party apps where the AI check applied, and confirmed there means adversarially checked rather than pattern-matched, with the method and the bands behind the 26-app study written out separately. Not one of those findings depended on who typed the code.

Every finding in that study is pinned to a file and a line, and the ones that live in git history carry the commit hash too. That is the same record this page has been pointing at from the second section onwards. It is where an auditor gets evidence, and it is where you get an author.

An r/webdev thread from August 2026 was titled “If AI writes 90% of my code, what am I actually supposed to be proud of?”, which is the honest version of the same worry, and a different question from the one you came with. Whether the running app was made inside a builder is a different question with different evidence, answered by the address it is served on, the sign-up email and the requests it makes rather than by anything inside the code.

Three routes lead out of here. Knowing a machine typed it still leaves you with nothing to say to the person you paid. The eight things to ask them for, with what a straight answer and a stalling answer to each one sound like, are set out separately. None of the repository evidence on this page is reachable unless you have access to the repository, in your own name or delegated by whoever holds it, and holding it in your name is the first of the things worth checking that you actually hold. And when what you want is a person to read the thing and tell you what is in it, how to choose who reads the code, and what evidence to ask them for is the part worth getting right, because the answer to who typed it was never going to be the expensive question.

Common questions about checking whether code was AI generated

How accurate are AI code detectors?

Accuracy depends entirely on whether the code resembles what the detector was trained on. Vendors state 95 to 99 percent on their own pages, measured on their own distributions. On AICD Bench, a benchmark of 2 million examples across 77 models and 9 languages published in February 2026, nothing tested on its robust binary classification task beat a guess: the highest Macro-F1 in the results table is 44.99, the best trained model reaches 43.05 and the best transformer detector reaches 34.13, against 45.73 for a random guess and 43.83 for always answering human.

Is there a free way to check if code is AI generated?

Yes, and the free version is the honest one. Every detector named on this page has a free tier or a free demo, and all of them carry the accuracy problem above. The free check that gets closest to authorship is the commit history: git log with an author and committer format string costs nothing, needs no account, and reads out the names and email addresses recorded on every change. It requires access to the repository, which is a permissions question rather than a money one, and it corroborates rather than proves: every field in it can be set by hand, as the commit section above explains.

Does the answer change with the programming language?

Yes, in two ways worth knowing. Some products only cover some languages: Span’s founder stated at launch that the detector “only works for TypeScript and Python code”, with Java, Ruby and C# named as next. And AICD Bench, which covers 9 languages, reports that detectors struggle to generalize across programming languages, so a tool tuned on Python is not automatically trustworthy on Java or MATLAB. The commit record does not care what language the file is in.

Can professors or teachers tell if code is AI generated?

Not reliably, and the institutions that deal with the consequences say so directly. MIT Sloan’s teaching guidance states that AI detection software “is far from foolproof … it has high error rates and can lead instructors to falsely accuse students of misconduct”, and notes that OpenAI shut down its own detector over poor accuracy. Its recommendation is to change how work is assessed rather than to buy a detector, which is guidance for a classroom rather than for an app you paid for.

Can someone remove the marks that show AI wrote the code?

Yes, and none of it requires any skill. Git’s commit documentation includes an --author option that overrides the recorded author and a --reset-author option that moves authorship to the committer, and the author and committer fields both read from environment variables anyone can set. Tool trailers are configurable too: Claude Code’s settings reference documents an attribution.commit setting whose stated purpose is to “Change or hide the trailer Claude Code adds to commits”. Treat a clean history as weak evidence and a marked one as strong evidence.

The developer says they wrote it by hand. Can I check?

Partly, and what you can check is narrower than a yes or no. You can read the commit log for author and committer names, email addresses at tool domains, and co-author trailers, and you can see whether commits are signed. What you cannot see is a suggestion accepted inside somebody’s editor, which leaves no documented mark in the commit at all. A history with no tool marks in it is consistent with hand-typed code and also consistent with a developer who accepted completions all day.

Is AI-generated code worse than human-written code?

Measurably different, and different in the direction most people do not expect. The third version of the measurement of 12,749 commits, dated 1 July 2026, reports AI-generated files triggering 10.04 CodeQL alerts per thousand lines against 13.56 for the matched human files, with high-risk alerts level at 0.514 against 0.52, and it reports the same files drawing more follow-up work in the 30 and 90 days after the commit. Fewer alerts and more follow-up work is not a result anybody can read off a file, which is why what to do about AI-written code once you know that is what you have is a more useful question than whose fingers were on the keyboard.

What should I ask the developer instead?

Ask what tools they used, what they read before shipping, and what happens when the app fails, because the answers to those are checkable in a way an authorship percentage is not. The questions that separate a developer who will tell you what they used from one who will not are a set of eight, each with what a good answer and a hand-wave sound like. A developer who names their tools without flinching is telling you more than any detector output would.

Can a detector prove somebody lied to me?

No. A detector returns a probability produced by a model that the hardest published benchmark scores below random guessing on unfamiliar code, and no vendor on this page claims otherwise: mydetector.ai states on its own page that “no AI detector code can be 100% certain”. What can support a claim is the repository record, because commit authors, committer names and co-author trailers are written by tools rather than inferred by one. Even then the honest reading is what the record shows, and what a missing mark does not.