Can you prove you wrote a piece of code yourself?

Why a detector cannot settle it

People often reach for an AI code detector, hoping a "human" result will clear them. The research does not support leaning on one in either direction. A 2024 study that evaluated existing detectors on code found that "they all perform poorly and lack sufficient generalizability to be practically deployed". A later dataset of over a million samples across seven languages and 43 models reported that detectors fail to generalise across coding domains and languages. Watermarking, the other proposed fix, has its own problem: code is low entropy, and existing watermark methods were found to fail on code generation for that reason.

So a detector result is a weak signal about a piece of text, not evidence about who wrote it. The AI code detector guide covers the papers in more detail. If a detector has already flagged your work, the thread on a 2019 file flagged as AI deals with that case.

What git history shows, and what it does not

A commit history is the most natural evidence you have, but read it for what it is. The git commit documentation lists --date=<date> to "Override the author date used in the commit" and --author=<author> to "Override the commit author", and the GIT_AUTHOR_DATE and GIT_COMMITTER_DATE environment variables do the same. The dates and names in a commit are statements made by whoever created it, not facts recorded by a third party.

History is still useful because of its shape. Many small commits with dead ends, fixes and renamed variables show work happening over time. One large commit with a finished program shows only that a finished program arrived. Neither proves anything alone, but the first is much easier to explain and defend.

Signed commits and host timestamps

Signing adds a second layer. GitHub's commit signature verification page says a commit signed with GPG, SSH or S/MIME that is cryptographically verifiable is marked "Verified". When a signed commit is pushed, GitHub stores a verification record that "can't be edited", including a timestamp of when verification was completed, readable through the REST API as verified_at. The record persists even if the key is later rotated or revoked.

That gives you two facts a skeptic can check: the commit was signed by a key tied to your account, and it existed on GitHub by a certain time. It does not show that you typed the code rather than pasted it. GitHub also notes that signing a commit is different from signing off on one.

What each kind of evidence can carry

Evidence	What it supports	What it cannot show
Many small commits over days	The code grew in steps	Who wrote each step; dates can be set by hand
Signed commits pushed to a host	Your key signed them; the host saw them by a recorded time	That the content was not pasted from elsewhere
Drafts, notes, failed attempts	How you reached the solution	Anything about code you did not keep notes on
A provenance record for copied snippets	Where outside code came from and under which licence	Who wrote the rest
An Assisted-by: trailer	That you disclosed tool help	How much of the change the tool wrote
Explaining and changing the code live	That you understand it now	That you wrote the first version

The last row is the one you can produce on demand. Being able to walk through why each part exists, and change it when asked, answers questions that no score can.

Build the record as you go

1. Commit small and often, with messages that say what you tried: git commit -m "Try pointer capture for drag; fixes jump on fast moves".

2. Sign your commits. With a signing key set up, git commit -S signs a single commit; GitHub's verification pages walk through GPG and SSH keys.

3. Push to a remote regularly, so a third party records when each commit arrived.

4. Keep a plain notes file or issue thread with sketches, links you read and dead ends.

5. When you copy code, record where it came from and its licence. An SPDX-License-Identifier comment near the top of the file travels with it, and the provenance record thread lists the fields to keep.

6. When you use an assistant, say so. The Linux kernel asks for an Assisted-by tag, and git trailers go at the end of the commit message after a blank line:

   Add keyboard support to slideshow
   
   Assisted-by: <tool> (keyboard handler reviewed and tested by hand)
   

   The wording after the tool name is an example; check the format your project uses.

Disclosure does not weaken your case. A record that admits where you had help is easier to believe than one that claims none, and projects such as the Linux kernel, LLVM and Mesa already ask for it.

The honest limit

No combination of these proves authorship the way a signature proves a key. What they do is turn "trust me" into a record someone else can inspect. If you start keeping that record now, the question becomes much easier to answer the next time it comes up.