How to Detect if Code Is AI-Generated

A lot of articles on AI code detection assume you're detecting AI code so you can get rid of it.

That's the wrong goal. Good code is good code, no matter who (or what) wrote it. And the simpler the change, the more alike human-written and AI-written code tend to look. But that doesn't mean it doesn't matter at all whether your code is AI-generated.

AI-generated code tends to have tells, bugs, and errors that differ from the ones humans make. If you're shipping a lot of AI code, those bugs can slip through to production and degrade your codebase over time. Research on real-world repositories suggests a meaningful share of AI-introduced issues never get cleaned up [2].

So the point of detecting AI code isn't to slow your team down. It's to know where AI code lives, so you can put the right review in front of it and hold all of your code to the same standard. Here's how.

Can AI-generated code be detected?

Yes. There are a few ways to detect AI-generated code, and they work best in combination.

• AI code detectors. Dedicated detection tools use statistical analysis and machine learning models to score how likely a snippet is to be AI-generated, based on patterns in syntax, style, and structure. They're quick, but they give you a probability, not a certainty, and they get less reliable as a human edits the code.
• Commit and PR attribution. Many coding agents leave a trail: Co-authored-by trailers in commits, bot accounts as PR authors, or branch and PR title prefixes. That's how our research team identified agent-authored PRs when studying how models review their own code.
• Audit logs in enterprise coding tools. Some enterprise AI coding tools log which suggestions or changes were accepted from the AI, so you can see which parts of a change came from the tool.
• Manual detection. Reviewers can learn to spot AI tells, syntax patterns, and the kinds of bugs AI tools make more often than humans. The rest of this guide covers what to look for.
• Watermarking. Less commonly, some model providers have started embedding machine-readable watermarks in generated output, which detection tools can then look for. It's still early: detection access is limited, and edits and reformatting make marks harder to rely on.

How to tell if code is written by AI: 7 common tells

AI-generated code can look, read, and run like human-written code, but there are usually signs a human didn't write it. Sometimes that doesn't matter. When it does, here are seven tells that suggest an agent was in the loop:

1. Overly generic comments. Comments that are generic, verbose, uniform, or state the obvious are a common sign of AI. Humans tend to leave quick, uneven comments that show their thinking, usually around the tricky parts. AI coding tools comment far more consistently (often too much), and the comments tend to restate what the code does, even when it's obvious.
2. Clean syntax but broken logic. Humans tend to be messy in the small things and logical in the big things. AI is often the opposite. A human will use whitespace inconsistently, make typos, and occasionally ignore the style guide. AI tools are extremely consistent in how code looks. Polished code isn't proof of AI on its own, but polished code that breaks under real inputs or has obvious logic errors is a strong signal.
3. Missing context. Many AI coding tools don't have the context of your entire codebase, which leads to subtler tells: changes that break code several files away, PRs that ignore the requirements in the linked ticket or the docs in Linear or Notion, or code that breaks conventions any developer on the team would know. When new code breaks old code or ignores the bigger picture, there's a good chance AI was used without enough context.
4. Hallucinated data or inputs. When an AI tool can't find a real value, it will often invent one: a config key, an API field, an example payload, or test data that looks plausible but doesn't exist anywhere in your system. A human is more likely to leave a placeholder or a TODO.
5. Superficial fixes and patches. AI tools often take the shortest path to making a problem go away, even when it doesn't fix the problem. They might pin a dependency back to an older version, delete or weaken a failing test, or wrap an error in a catch that swallows it. Or the agent says "X is fixed, here's what changed," but when you check the diff, the code doesn't reflect those changes at all.
6. Overly complex fixes or bloated code. The opposite tell is just as common. A human developer rarely writes hundreds of lines for a simple fix, adds extensive documentation for a small change, or solves a simple problem in a convoluted way. AI tools do this regularly.
7. The same kinds of bugs keep reaching production. When code is written by a model and then reviewed by the same model, the reviewer tends to miss the same bugs the author created. In our research, models found fewer bugs in their own code than in code written by a different model, and the bug types a model introduces most are the ones it's most likely to miss in review. If the same types of errors keep slipping into production, that's a sign AI code is getting reviewed by a process with the same blind spots.

Common errors and bugs in AI-generated code

Another way to identify AI-generated code is to look for the errors and bugs that show up more often in AI-generated code than in human code.

First, an important note: AI-generated code isn't necessarily worse than human-written code. In our study of millions of PRs, two of the four coding agents we tracked had lower revert rates than humans, and review cycles for every agent clustered within 0.4 of the human mean.

What we did find was that each agent has a different pattern of errors, which can help distinguish its code from human-written code (and calls for a different review process, more on that below). Measured per line of code against the human baseline, by category of bug Greptile flagged:

• One agent was flagged for n+1 queries at about 3.5x the human rate, and at 2x or more of the human rate for breaking existing behavior, missing tests, off-by-one errors, and timezone or date bugs.
• Another agent's above-human categories cluster around configuration and breakage: env var and config bugs (1.35x), breaking existing behavior (1.34x), secrets in logs (1.34x), and SQL injection (1.25x).
• A third agent's highest categories are around tenancy and authorization: IDOR and missing tenant checks (1.75x), stale comments or wrong docs (1.69x), off-by-one errors (1.64x), XSS (1.57x), and auth bypass (1.5x).

A higher rate in one category isn't proof that a given agent wrote a given PR. But if your codebase keeps producing one cluster of bugs, it's a useful clue about where AI code is coming from and what your review should watch for.

Across the agents we studied, a few categories came up above the human rate for three of the four:

Agent rate divided by human rate, per line of code, April 2026. Above 1x means the agent was flagged for that category more often than humans. The full per-agent breakdown and methodology are in Rise of the Overnight Agents.

Notably, these are mostly security and runtime errors: issues that can open up serious vulnerabilities and make your codebase less stable over time. They're also hard to spot in a traditional PR review. Often you don't notice them until the app is running, which is why runtime validation matters so much for AI-generated code, and one more reason to know which code is AI-generated.

Why does it matter if code is AI-generated?

AI-generated code isn't the same as human-written code. It has its own tells, syntax habits, bugs, and errors.

That doesn't mean you shouldn't use AI to code. It means you need to know when you used it, so you can adjust your process accordingly.

If you're using AI to scale code generation, you also need to scale code review. If you don't, you'll run into one or more of these problems quickly:

1. Code review becomes the bottleneck

AI coding moves the bottleneck from writing code to reviewing it. At Atlassian, an engineering organization of about 6,000 people, coding is now roughly 15% of how engineers spend their time. The rest goes to new bottlenecks, including validation [1].

Many large engineering teams are feeling the same shift. You adopted multiple coding agents, PR volume jumped, review capacity didn't, and now the gap is obvious.

Without the right support in place, AI-generated code just moves the bottleneck, and you don't get the full benefit of the speed AI coding gives you.

2. Traditional code review doesn't work as well on AI-generated code

A traditional code review process doesn't fit AI-generated code as well as it fits human code.

Part of the reason is that the bugs AI introduces usually aren't the kind linters or SAST tools catch. AI-generated code is syntactically clean and reads well, and its bugs tend to be cross-file logic issues you only catch by understanding how a change interacts with the rest of the codebase. Across the issues Greptile has flagged since March 2026, more than half were real defects in how the code behaves, not style or quality feedback.

AI tools also make subtle mistakes that human reviewers easily miss: changes that break other parts of the codebase at runtime, code that's missing context, and other issues a human wouldn't think to look for because they aren't the kinds of mistakes humans usually make.

In an internal test, we found that AI was better than our own engineers at finding these bugs. The then-newest Anthropic Sonnet model correctly identified 32 of the 209 bugs in the "hard" category of our bug-finding benchmark. None of the highly skilled engineers at Greptile could identify more than 5 to 7.

That isn't because humans are bad at reviewing. It's because AI code needs a different kind of review, one that pays attention to the errors and bugs AI is likely to make. When human reviewers read AI-generated code assuming a human wrote it, they're more likely to miss those errors. That's a big part of why it matters to know when code is AI-generated.

Otherwise, those mistakes get missed, ship to production, and stay in the codebase, degrading it over time.

3. Review isn't standardized, so the codebase degrades

When all your code is human-written and human-reviewed, a simple code review checklist often provides enough standardization to catch most bugs.

With AI-generated code in the mix, it isn't enough:

• AI-generated code often looks right, even when it isn't. Because it looks right on the surface, reviewers are more likely to skim it. If they don't know AI wrote it, they don't realize they should spend more time digging into logic errors and cross-file dependencies.
• AI PRs are larger. In our data, the same developer's AI PRs are about 20% larger by median lines of code than their non-AI PRs. Bigger PRs make it easier for reviewers to skim and leave a quick "lgtm!", and with AI-generated code that's how critical errors get through.
• Self-review has the same blind spots. Some developers review code with their coding agent first, but when the same model writes and reviews the code, it tends to miss the same kinds of bugs it introduced. If you've rolled out an AI review tool and it's noisy, developers start ignoring it, and the bugs your coding agents make still get through.

The result shows up in research on AI-generated code in the wild. Liu et al. built a dataset of AI-authored commits from 6,299 GitHub repositories and tracked 484,366 issues those commits introduced, mostly code smells plus correctness and security issues. 22.7% of those AI-introduced issues still survived in the latest version of the repository [2].

Issues like these erode trust and add complexity, which leads to more issues later, especially with AI-generated code that already struggles with codebase context and complex cross-file interactions.

The goal of detecting AI code is to know when and where it was used, so you can apply the right review to it and make sure all of your code, however it was written, meets your standards.

How Greptile helps teams catch more bugs in AI-generated code

There's no reason not to use AI coding tools to speed up development. But you need to scale every part of your process together, and that includes code review.

At Greptile, our AI code review is designed to catch the failure modes of agentic coding, so your development process can become more autonomous and more secure:

• Full codebase context. Greptile builds a graph of your entire codebase and learns your codebase and coding standards as you use it, so every change is reviewed with the whole codebase in mind. That's how it catches AI errors that come from missing context or that break other code at runtime.
• Built to catch both human and AI errors. Greptile is purpose-built to surface the bugs that slip through code review, whoever wrote the code, with detailed PR reviews that explain each issue and less noise for your team to filter.
• Reviews in your terminal. The Greptile CLI lets your coding agents run Greptile while they work, so bugs get caught and fixed earlier. Add the Greploop skill and your agents can review, iterate, and fix bugs on their own, with Greptile as an independent reviewer.
• An independent reviewer. Greptile is agent-agnostic: it works with any coding agent and uses a mix of models to play to each model's strengths, so code isn't reviewed by the same model that wrote it.
• Security checks on every PR. Greptile pairs static scanning with an AI security agent in a built-in security check to catch the kinds of vulnerabilities AI coding tools are likely to introduce.
• Runtime validation. TREX runs the code in a sandbox and attaches evidence to the PR comment: logs, screenshots, traces, scripts, videos, or API output. Your developers can see what happened and why, which makes runtime errors faster to fix.

This is how engineering teams use Greptile to surface more issues, catch bugs before they hit production, review more code changes, faster, and cut time to merge.

It's also why Mixpanel, where upwards of 95% of merged PRs have some detectable coding agent attribution and 10% are fully generated end-to-end by an in-house coding agent, relies on Greptile for review.

Here are a few of the issues Greptile has caught in real open-source codebases:

Want to see how Greptile handles your AI-generated code? Try Greptile free for 14 days →

Sources

[1] Taroon Mandhana, Chris Kasten, and Ryan Sokol. "How Intuit, DoorDash, and Atlassian are adopting AI coding." Cursor Compile '26, June 2026.

[2] Liu, Y., Widyasari, R., Zhao, Y., Irsan, I.C., Chen, J., and Lo, D. "Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild." arXiv:2603.28592, March 2026 (revised October 2026). arxiv.org/abs/2603.28592