How to Prove You Wrote Your Own Code

Nobody can prove authorship from the final file alone. Finished code does not carry a signature, and a tidy human solution can look a lot like a generated one. What you can show is how the code came to exist: the small steps, the mistakes, the fixes and the understanding behind them. This page explains which records count, where to find them in common tools, and how to present them. If you have already been flagged, read my code was flagged as AI but I wrote it for the step-by-step response; this page is about the evidence itself, and ideally about setting it up before anyone asks. Tool details below come from the official documentation, which we read in October 2026.

1. Git commits: the backbone of your record

According to GitHub's documentation, a commit records changes to one or more files, and each commit has a unique ID tied to who made the changes, when they were made and what the changes were. It also carries a message describing the change. A history of many small commits with honest messages, such as "parse input", "fix off-by-one in loop" and "handle empty list", shows a solution being built rather than appearing.

Habits that make your history useful:

• Commit early. Your first commit can be a skeleton that does not run yet.
• Commit small. One idea or one fix per commit is easy for a reader to follow.
• Keep your mistakes. A commit that introduced a bug and a later one that fixed it is good evidence, not an embarrassment.
• Push regularly to the repository your course provides, or a private one, so there is a copy beyond your laptop.

Be realistic about what Git shows. The git commit documentation includes a --date option that overrides the author date, so commit dates are set on your own machine and are not tamper-proof. That is why reviewers read history as supporting evidence alongside everything else. It also means you should never rewrite or backdate history to make it look better; show what really happened.

2. Your editor's local history

Even if you never used Git, your editor may have been keeping a record.

• VS Code Timeline. The VS Code user interface docs describe the Timeline view as a unified view of a file's event history. It can show Git commits and local file history; depending on your settings, a new local entry is added each time you save, and each entry holds the full contents of the file at that moment. Open your file and look at its Timeline view to see the entries.
• JetBrains Local History (IntelliJ IDEA, PyCharm, CLion and others). JetBrains' Local History documentation says it records your project's state as you edit code and run tests, and by default keeps revisions for the last five working days. Right-click in the editor and choose Local History, then Show History, to see revisions by timestamp. The docs also say Local History is not a replacement for version control and is cleared when you install a new IDE version, so if you need it, look soon and do not reinstall first.
• Online IDEs and cloud drives. Some browser-based coding environments and cloud storage services keep file versions. Check the history or versions menu of whatever your course uses.

Local history is usually less tidy than Git, with many saves a few seconds apart, and that is fine. Untidy, incremental change is exactly what a person writing code produces.

3. Drafts, notes and your learning trail

Process evidence is not only in version control. Collect anything that shows your thinking:

• Pseudocode, diagrams or a plan on paper, even a photo of a whiteboard.
• Earlier versions of files, scratch scripts and test inputs you tried.
• Questions you posted on the course forum or asked in office hours.
• Lecture slides or textbook sections you followed, so a similarity to course examples has an explanation.
• Your earlier assignments, which show your usual style.
• If your course allowed AI help, your disclosure note and any log of what you asked.

4. Explaining your code live

The most convincing evidence is not a file at all. It is being able to sit with an instructor or teaching assistant and explain your solution: why you structured it this way, what alternatives you rejected, which part was hardest and how you would change it if the requirements changed. If they ask you to make a small modification on the spot, that is normal. Prepare by explaining your code out loud once, and by re-reading any part you have not looked at for a while. Practising a walkthrough is not gaming anything; it is how you show understanding you really have.

5. Putting it together

If you need to present your evidence, make it easy for a busy reader:

1. A short timeline. Five to ten lines with dates: when you started, key milestones, where you got stuck and what you did.
2. Links or screenshots of the commit history or local history that match the timeline.
3. Supporting items such as drafts, forum posts or office-hours notes.
4. An offer to walk through the code at a time that suits them.

Keep it factual and calm. You are not trying to win an argument; you are giving someone the information they need to see your process.

A note on honesty

Everything here is about showing work you actually did. If some of the code came from an AI tool or another source, the right move is to say so and explain how you used it, checked against your course policy. See is using ChatGPT for coding homework cheating? for how to read your policy.

Seeing how your code reads

Paste your code into the detector at the top of this page to see which patterns a reader might associate with AI output, along with the reasons. It does not prove authorship either way, but it tells you which parts you are most likely to be asked about, so you can be ready to explain them.

Read more

• Can professors tell if you used ChatGPT for code? — the checks courses use.
• Does MOSS detect AI-generated code? — how similarity tools work.

Frequently asked questions

Try the detector

Have a snippet you are unsure about? Paste it into the free AI Code Detector to get a verdict, an AI probability and the reasons behind it. No sign-up, and your code is not stored.