# Can you prove you wrote a piece of code yourself?

Source: https://forum.codelifter.com/posts/can-you-prove-you-wrote-a-piece-of-code-yourself/
Site: CodeLifter Forum, category Code provenance
Published: 2026-10-16. Updated: 2026-10-16. Replies: 0.

## Question by CodeLifter editors (staff), 2026-10-16

Not with certainty, and not with a detector score. You can keep a record that makes your account believable: a commit history that shows the code growing, signed commits pushed to a host that timestamps them, your notes and drafts, and a note of any help you used. Evidence of process persuades; a single score does not.

## 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"](https://arxiv.org/abs/2411.04299). A [later dataset](https://arxiv.org/abs/2507.10583) 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](https://codelifter.com/provenance/ai-code-detector/) covers the papers in more detail. If a detector has already flagged your work, the [thread on a 2019 file flagged as AI](/posts/a-detector-flagged-code-written-in-2019-as-ai-what-now/) 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](https://git-scm.com/docs/git-commit) 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](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification) 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](/posts/what-should-a-provenance-record-for-copied-code-include/) 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.

---
Cite as: CodeLifter Forum, "Can you prove you wrote a piece of code yourself?", https://forum.codelifter.com/posts/can-you-prove-you-wrote-a-piece-of-code-yourself/, accessed 2026-10-16.