How to Tell If Code Is AI-Generated: A CTO's Field Guide (2026)

TL;DR: The Detector You Want Doesn't Exist. The Skill Does.

Everyone searching this wants a scanner: paste the repo in, get a percentage out. I audit AI-built codebases for a living, and I'll save you the search — that tool doesn't reliably exist, and the ones that claim to are selling confidence, not accuracy. AI-text detectors work (badly) on prose because prose carries statistical fingerprints in rhythm and word choice. Code goes through formatters, linters, and compilers that erase exactly those fingerprints. What survives is structure — and structure is readable by a human in about ten minutes. This guide is that ten-minute read, from someone who does it weekly on rescue engagements.

Why "Check If Code Is AI-Generated" Tools Come Up Empty

Three reasons, all structural. First, training data: detectors learn on human-vs-AI prose pairs; code's vocabulary is constrained by syntax, so the signal is thinner from the start. Second, normalization: run any developer's code through Prettier or Black and it converges on the same shape AI output already has — the formatter destroys the evidence. Third, the mixed reality of 2026: most professional code is now human-directed AI output with human edits, so the binary question "AI or not?" is the wrong question. The useful question is the one the tells answer: was this code reviewed by someone who understood it?

The 9 Tells of Unreviewed AI Code

From real audits — every one of these has shown up in a codebase someone paid real money for.

• 1. Narrated comments. // Loop through the users and check each one above a loop through users, checking each one. Humans comment why; AI comments what. Density of obvious comments is the single fastest tell.
• 2. Hallucinated APIs. Calls to methods that don't exist in the installed version of the library — or at all. If the repo has ever needed a "fix undefined method" commit spree, you're looking at unverified generation.
• 3. Convention drift. camelCase here, snake_case there, three different date-formatting approaches in one project. Each file reflects a different chat session's mood.
• 4. Copy-paste logic. The same validation or transformation written out longhand in three controllers instead of extracted once. AI doesn't remember it already solved this two prompts ago.
• 5. Ceremonial error handling. try/catch wrapped around code that cannot throw, while the network call two lines down goes naked. Defensiveness distributed by vibes, not by risk.
• 6. Tests that assert nothing. A green suite full of expect(true).toBe(true)-grade checks, mocks that mock the thing being tested, and zero edge cases. Coverage without protection — the most expensive tell on this list.
• 7. Uniform freshness. Whole files that arrive fully formed in single commits, with none of the scar tissue real code accumulates — no TODO, no commented-out attempt, no incremental history.
• 8. Boilerplate maximalism. Every file carries the full ceremony — interfaces, factories, config objects — for a feature that needed twelve lines. AI scaffolds like it's billing by the abstraction.
• 9. The knowledge test fails. The decisive one: ask whoever shipped it to walk you through a nontrivial file. If they can't explain their own code, it doesn't matter who wrote it — nobody reviewed it, and that's the actual risk.

What This Means If It's Your Codebase

If you're an owner or founder reading this because a contractor's deliverable feels off, or your vibe-coded app is starting to wobble — here's the honest framing. AI-written code isn't inherently bad; unreviewed code is, whoever wrote it, and AI just made unreviewed code cheap to produce at volume. The pattern I see on every rescue call is identical: the demo was great, the first two months were great, and then edge cases the prompts never mentioned started arriving as production bugs. That arc, and whether it's fixable, is covered in the honest case for and against vibe coding — the short version is that it's usually fixable, and rarely by a full rewrite.

How AI Code Detection Actually Works: What the 99% Accuracy Claims Do Not Cover

Every detector sells a percentage. Read the vendor's own page and the percentage turns out to be about something else. GPTZero advertises "99% accuracy rates across diverse datasets," and the same page says accuracy "improves with longer inputs" and "is strongest on English prose." Its supported-language list is English, German, Portuguese, French and Spanish. No programming language is on it. Turnitin quotes a false positive rate under 1%, measured on documents that meet a 300-word requirement. Also prose. (Both pages read September 23, 2026.)

Now do the math the accuracy claim skips. Take the best published number at face value and apply it per file: a 1% false positive rate across a 300-file repository flags about three files a human wrote, before it has caught a single AI one. And the signal it measures, word rhythm, is the first thing a formatter rewrites. That is why the tells above check structure and review instead of style. Structure survives Prettier. A detector's signal does not.

The 20-Minute Owner's Audit (Do This Today)

You don't need to read code to run this. First, the knowledge test: ask your developer to walk you through the most important file on a screen share — tell #9 settles most cases in five minutes. Second, security surface: run my free 20-point vibe coding security checklist against the app; exposed API keys and missing auth checks are where unreviewed AI code gets expensive fastest. Third, count the tells above in any two files — a developer friend can do this over coffee. Zero to two tells: relax, review going forward. Four or more, on an app your revenue depends on: get a structural audit before you build anything else on top. That's the front door of Vibe Code Rescue — triage what's salvageable, stabilize what's load-bearing, rebuild only what's actually broken.