How to Tell if Code Was Written by ChatGPT

Practical signs that a piece of code came from ChatGPT or another AI assistant, why none of them is proof on its own, and how to check fairly.

If you review code for a class, a hiring process or an open-source project, you have probably looked at a submission and wondered whether a person wrote it or asked ChatGPT for it. There is no single tell that settles the question. What you can do is look for a cluster of signals, weigh them against what you know about the author, and then ask questions. This guide walks through the signals that experienced reviewers actually use, where each one fails, and a sensible process for checking.

Why there is no simple test

Code is much more constrained than essays. There are only a handful of reasonable ways to parse a CSV file or reverse a linked list, and a strong student, a senior engineer and a language model will often converge on the same one. ChatGPT also does not embed a hidden watermark in the code it writes, and even if it did, copying the code into an editor and reformatting it would remove most traces. So the realistic goal is not to prove anything from the code alone, but to decide whether there is enough reason to look closer.

Signals in the comments

• Comments that narrate the obvious. Lines like "# Loop through the list" or "// Return the result" above code that plainly does exactly that. People rarely bother to comment trivial lines; assistants do it by default.
• Even, tidy coverage. Every function has a docstring of similar length and every block has a one-line comment. Human comments are usually patchy: dense around the tricky part, absent everywhere else.
• Tutorial tone. Phrases such as "This function takes a list of numbers and returns..." or "Example usage:" read like documentation written for a reader who has never seen the problem, which is how chat answers are framed.
• Leftover chat context. Occasionally a comment refers to "the code above", "your requirements" or a step-by-step explanation that only makes sense inside a chat conversation. This is one of the stronger signals when it appears.

Signals in naming and structure

• Textbook names everywhere. Variables like result, input_list, current_node and is_valid, used with perfect consistency. People drift: res in one place, out in another, a stray tmp2.
• Defensive checks for everything. Input validation, type checks and edge-case guards that the assignment or task never asked for, often with generic error messages.
• A demo block. An if __name__ == "__main__": section or a main function with sample inputs and printed output, even though the task only asked for a function.
• No mess. No commented-out attempts, no debug prints, no TODO notes, no dead variables. Real work in progress usually leaves some scaffolding behind.

Signals in what the code knows

Some of the most useful clues are about context rather than style. Code that comes from a chat answer is written without access to the rest of the project, so look for mismatches:

• Techniques or library functions that were never taught in the course, or that the rest of the codebase never uses.
• Helper functions that duplicate utilities which already exist in the project.
• Placeholder names such as your_api_key, example.com or data.csv where the real project uses something specific.
• A style that does not match the author's earlier work: suddenly different indentation habits, naming conventions or error-handling approach.

That last point is often more telling than anything inside the snippet. One clean file proves little, but a sharp change from someone's usual style is worth a conversation.

Signals that point the other way

A fair check looks for human fingerprints too. Typos in comments or names, unusual but working shortcuts, project-specific hacks, jokes, inconsistent formatting, and comments that explain why something weird is necessary ("the API returns 200 even on failure, so check the body") all lean toward a human author. So does code that is clearly mid-debugging, with a half-finished idea and a note about what to try next.

Common false positives

Plenty of human code looks "AI-like". Be careful with:

• Experienced developers who habitually write clean, consistent, well-documented code.
• Code run through a formatter or linter, which removes many of the small inconsistencies that suggest a human.
• Students who learned from the same sources the models learned from, such as popular tutorials and textbook examples, and who copy that style faithfully.
• Very short or very standard snippets, where there is simply not enough room for personal style to show up.
• Non-native English speakers who write deliberately formal, careful comments.

A practical way to check

1. Read it yourself first. Note which of the signals above you actually see, and which human signals are present.
2. Compare with the author's other work. Earlier submissions, previous pull requests or the rest of the codebase are your best baseline.
3. Get a second opinion. Run the code through an AI code detector and read its reasons, not just its score. If the reasons match what you noticed, that is more meaningful than a high number alone.
4. Check the history if you have it. Commit history, editor history or drafts show how the code evolved. Code that appears fully formed in a single paste is different from code built up over several sessions.
5. Talk to the author. Ask them to walk you through the code, explain one design choice, or make a small change live. Someone who wrote the code, or who used AI but genuinely understands the result, can usually do this comfortably.

The conversation is the step that matters most. Detection signals tell you where to look; understanding is what you usually care about in the end.

What a detector can and cannot tell you

An AI code detector automates the stylistic part of this checklist. It is quick and consistent, and it is useful for triage when you have many submissions. It cannot see the author's history, the assignment rules or the project context, and it can be wrong in both directions, especially on short snippets or AI output that someone has edited. Use its result as a probability that tells you whether to look closer, never as a verdict on its own.

If you want to try it on a snippet now, the ChatGPT code detector runs this checklist for you and returns the reasons behind its score. For Python specifically, see the Python AI code detector; for graded work, the AI code checker for homework.

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.