How to Check if Code Was Written by AI: Detection Methods That Work

Maybe you’re a teacher suspecting a submission, a manager reviewing a PR, or just curious. How to check if code was written by AI? I’ll be straight with you: there’s no definitive test. But there are signals — some strong, some weak — and knowing how to read them (plus knowing their limits) is genuinely useful.

How to check if code was written by ai: What Actually Works

• Suspiciously thorough comments. AI-generated code often has a comment on nearly every block, written in a consistent explanatory voice. Humans comment sparsely and inconsistently.
• Generic naming + textbook structure. process_data(), handle_request() — competent but soulless. Though plenty of humans write this way too.
• Over-engineered for the context. A simple script with enterprise-grade error handling and docstrings everywhere? Classic AI.
• Inconsistent skill levels. Elegant algorithm next to a rookie mistake in the surrounding code — suggests AI wrote the hard part.
• No personal quirks. Human code has fingerprints: odd spacing habits, favorite patterns, TODO comments with personality. AI code is fingerprint-free.

Important: every one of these also describes good human code. Tells are probabilistic, not proof. Which brings us to…

Detector Tools (Use With Caution)

AI code detectors exist, and they’re roughly as reliable as AI text detectors — meaning not very. False positives are common (flagging human code as AI) and false negatives are trivial to achieve (ask the AI to “write in a casual style with sparse comments”). No detector result should ever stand alone as evidence of anything. For the academic context, what teachers use to check for AI covers the tools — and their well-documented accuracy problems.

What Actually Works: Forensics

Forget the code; investigate the process:

1. Git history. Human code arrives in messy increments — commits, reverts, “fix typo” at 2 AM. AI-assisted code often appears as large, perfect, single commits. A 500-line flawless first commit is a signal.
2. Explain-it-back test. Ask the author to explain a tricky section. Someone who wrote it (even with AI help) can usually explain the logic; someone who pasted it blindly cannot. This is the gold standard.
3. Live modification. “Change this function to handle X instead.” Fluency with the code reveals authorship better than any detector.

The deeper question is often why you’re asking — which connects to knowing if code is AI-generated generally. In professional settings, the healthier question is usually “is this code correct and maintainable?” rather than “who typed it?”

When the Question Actually Matters (And When It Doesn’t)

Not every “was this AI-written?” question deserves investigation. It matters when: academic integrity is at stake (a student’s learning is the product), when security review needs to know the code’s provenance, when hiring (you’re evaluating the candidate, not their tools), and when licensing questions arise around training data. In these cases, use the forensic methods — process evidence over stylistic guesses.

It doesn’t matter when: the code is correct, tested, reviewed, and maintainable — in professional software engineering, provenance is trivia compared to quality. Teams that fixate on “did AI write this?” instead of “is this good?” are asking the wrong question and creating the wrong incentives (developers hiding tool use instead of disclosing it). The healthiest team norm: disclose AI assistance freely, review everything rigorously, and judge the artifact. Curiosity about authorship is natural; making it a witch hunt is counterproductive.

The Arms Race (And Why Detection Loses)

Step back and see the dynamic: detectors improve, then prompting improves (“write this in a casual style with inconsistent comments and a couple of TODOs”), then detectors improve again. This arms race has a predictable winner — generation, not detection — because generating human-like variation is easier than detecting its absence. Every detector is a classifier; every classifier has false positives and negatives; and the stakes of those errors (false accusations ruining a student’s semester) are asymmetric and severe.

The institutions adapting well are moving past detection entirely: process-based assessment (drafts, version histories, in-class work), oral defenses, and assignments designed so AI assistance doesn’t defeat their purpose. The institutions adapting poorly are buying detector subscriptions and disciplining students on statistical guesses. If you’re on the receiving end of the latter, the forensics in this guide are your defense. If you’re designing policy, skip the arms race — invest in assessment that measures understanding directly. Detection was always a proxy; measure the real thing instead.

A Note on False Accusations

A serious word of caution: every method in this guide produces signals, not proof — and acting on signals as if they were proof ruins lives. Students have faced disciplinary hearings over detector false positives. Developers have been questioned over clean, well-commented code. Before you raise an AI-authorship concern about someone’s work, ask yourself: what will I do if I’m wrong? If the answer involves formal accusations, you need process evidence (git history, explanation tests), not stylistic hunches. And consider whether the question even matters — in most professional contexts, “is this code good?” is the question worth asking. Reserve authorship investigations for situations where authorship genuinely matters, and conduct them with the fairness you’d want if you were the one being questioned.

The Takeaway

Stylistic tells give hints, detectors give unreliable guesses, but process forensics — git history and explain-it-back tests — give real answers. And in most professional contexts, redirect the energy: verify the code’s quality, not its parentage. Good code is good code.

On the ethics of detection: Wikipedia’s overview of AI content detection documents the accuracy limitations honestly.