A detector flagged code written in 2019 as AI. What now?

Why the score is weak evidence

A detector reads a snippet and returns a number that estimates whether a model wrote it. It does not know when the file was written, who typed it, or what it was copied from. The research on code is not kind to these tools:

• In a 2024 study, Suh and colleagues tested existing AI detection tools on source code and reported that "they all perform poorly and lack sufficient generalizability to be practically deployed". Their own best model reached an F1 score of 82.55, which still means errors in both directions.
• The 2025 DroidCollection paper, built on more than a million samples in seven languages from 43 models, found that existing detectors fail to generalise to coding domains and languages outside their training data.
• Watermarks do not help with old code. A watermark exists only if the generating tool embedded one, and Lee and colleagues found standard text watermarks fail on code because code has low entropy. A missing watermark proves nothing either way.

None of the papers explains why a particular 2019 file scored high, and you should not guess on the reviewer's behalf. Short, conventional code written the way tutorials teach it is the kind of input where a classifier has little to go on, but that is a reason for caution, not a measurement. The CodeLifter page on whether you can tell if AI wrote code goes through each method and its limits.

What to collect

You are building a timeline. The strongest items are ones somebody other than you recorded, at the time.

Evidence	Who recorded it	What it shows	How much weight it carries
Commit history with author and committer dates	Your Git client, then the server you pushed to	Which lines existed on which date, and who committed them	Good, especially when the repository was pushed to a hosted service in 2019
A tagged release or published package from 2019	The registry or hosting service	That a version containing the code was public on that date	Strong: a third party stored the file and the date
An archived copy of a project page or README	The archive service	That the page existed, sometimes with the code visible	Strong for what it shows, often partial
Issue tracker threads, pull requests, code review comments	The hosting service	Discussion of the code while it was being written	Good context, and hard to produce later
Coursework submission receipts, emails with attachments	The school system or mail server	That you handed in or sent the file on a date	Good, if you still have the original message
Your own memory of writing it	You	Nothing a reviewer can check	Useful only alongside the items above

Steps to pull the record from Git

1. Find the file's history. In the repository, run git log --format='%h %an %ad | %cn %cd' -- path/to/file.js. That prints each commit's short hash, author and author date, then committer and committer date. The Pro Git book explains the difference: "The author is the person who originally wrote the work, whereas the committer is the person who last applied the work."
2. Find when a specific function first appeared. Run git log -S functionName --format='%h %an %ad' -- path/to/file.js. The -S option shows only commits that changed the number of occurrences of that string, so the oldest result is usually where it arrived.
3. Show the exact lines from that commit. Run git show <commit> -- path/to/file.js and save the output.
4. Narrow to the year if the history is long: git log --since=2019-01-01 --until=2019-12-31 -- path/to/file.js.
5. Link the same commits on the hosting service if the repository was public or shared. A commit page on the service is easier for a reviewer to open than a pasted log, and it shows the service holding the same hash.

A commit date is written by the machine that made the commit, so on its own it is your statement about time. That is why the third-party items in the table matter: a 2019 release, a pushed branch, or a submission receipt is harder to dispute than a local log.

What to write back

Keep the reply short and factual. Something like this works for a course, a client or a project reviewer:

1. Name the file and the claim: which detector, which score, on what date.
2. Give the timeline: first commit hash and date, the release or submission that contained it, and links.
3. Quote the research in one line, with the link, so the reviewer can see the tool's limits for themselves.
4. Offer to walk through the code. Explaining why each part is there is direct evidence of authorship that a score cannot give.
5. Ask what decision the reviewer is making and what would satisfy them. A school may need a meeting; an open source project may only need a statement in the pull request.

Do not rewrite the code to lower the score. A rewritten file loses its link to the 2019 history, which is your best evidence.

If the code was partly copied

Old code often includes pieces from a forum answer, a library example or a tutorial. If the flagged part came from somewhere else, say so and link the source, with its licence. That is a provenance question rather than an AI question, and the thread on what a provenance record for copied code should include covers the fields. For code written now, the broader question of proof is in can you prove you wrote a piece of code yourself.

Going forward

Make the record as you work rather than reconstructing it later. Commit often with messages that say what changed, push to a remote, and when an assistant helps, say so in a trailer. A team that wants that line on every commit can follow the thread on enforcing an Assisted-by trailer. A history like that answers the next detector score in a few minutes.