How to Tell If Code Was Written by AI (and What to Do About It)

TL;DR: Detecting AI-Written Code in 2026

The question usually isn't academic. When someone asks me "was this code written by AI?", what they actually mean is: my freelancer delivered this, my last developer left this behind, my co-founder built this over a weekend — and something feels off. As of 2026, the honest answer is that a lot of it was AI-written, and that's not the problem. The problem is whether anyone understood it before it went to production.

I review AI-built codebases for a living — fixed-price rescues of apps built with Lovable, Cursor, Replit Agent, Bolt, and friends. Below are the tells I actually use, why the automated detectors don't work on code, and the exact order to fix things in once you know what you're holding.

Can You Tell If Code Was Written by AI?

Yes — with pattern reading, not software. Here's the core insight from a couple dozen rescues: humans are inconsistent in small ways but consistent in approach. AI is the exact opposite. AI code is eerily uniform line by line — every comment formatted the same, every function documented identically — and wildly inconsistent in architecture, because every prompt session reinvented the approach from scratch.

That inversion is the fingerprint. You're not looking for bad code. You're looking for code that's locally perfect and globally incoherent.

How to Detect AI-Generated Code: 9 Tells From Real Rescues

1. Comments that explain the obvious, uniformly. # increment the counter above counter += 1. A human writes that comment zero times. An AI writes it forty times, in identical style, on every file.
2. The same problem solved five different ways. Three HTTP clients. Two date libraries. Four patterns for form validation. Each prompt session picked its own favorite, and nobody was watching the whole.
3. Dependency bloat. Packages imported and never called. Libraries pinned in the manifest that nothing uses. Three tools doing one job. AI reaches for a library the way a nervous cook reaches for another pan.
4. Generic naming. data2, result_final, handleClick2, newFunction. Names carry intent; AI-in-a-hurry code carries numbering.
5. Tests that don't test. Either no tests at all, or test files that assert true == true in various costumes. Looks like coverage in the file tree; proves nothing.
6. TODO and placeholder blocks in production. // TODO: add real authentication here — live, on the internet, taking user data. I've seen this more times than I want to type.
7. Git history made of boulders. An "initial commit" with 40,000 lines, then five commits called "fixes" and "updates" at 3,000 lines each. Real development leaves a trail of small decisions; prompt sessions leave craters. This is my single most reliable check, because history can't be faked after the fact without real effort.
8. Dead code that looks load-bearing. Whole components, routes, and helpers that nothing calls — fully built, nicely formatted, wired to nothing. The AI built what was asked for, and also what it guessed might be asked for.
9. Error handling that swallows everything. Beautiful try/catch blocks on every function… that catch every exception and do nothing. It looks defensive. It's actually a blindfold — the app can't crash, so you never learn it's broken.

Scoring: any single tell shows up in tired-human code too. Four or more, uniformly across the repo, is a diagnosis.

How Can I Tell If My Python Code Was Generated by AI?

Python deserves its own list because the tells are so specific, as of 2026:

• Docstrings in identical format on every function — including three-line utilities that need none.
• Type hints everywhere or nowhere. Humans drift; AI commits to a policy per session.
• A requirements.txt full of pinned packages the code never imports.
• except Exception: pass — the Python edition of the blindfold from tell #9.
• if __name__ == "__main__": boilerplate on modules that nothing ever runs directly.

Do AI Code Detectors Work?

Short version: no, and code is the worst possible input for them. Detector tools were built for prose, where word-choice statistics carry signal. Code passes through linters and formatters that normalize style, follows community conventions on purpose, and legitimately repeats common patterns. That erases exactly the signal detectors depend on — so they false-positive on clean human code and false-negative on lightly-edited AI code.

The heuristics above plus twenty minutes of git archaeology outperform every automated detector I've tried. I don't run a detector on rescue audits. I read the log.

Does It Matter Who Wrote It?

Here's the honest part: no. I use AI to write code every single day. Reviewed, tested, understood AI code is just… code. The thing the tells above actually detect isn't authorship — it's the absence of a human who understood the system before it shipped.

That absence has a name: Vibe Debt — the silent cost of running software nobody on the team can explain. It comes in three flavors: comprehension debt (nobody can explain it), drift debt (five patterns for one job), and dependency debt (the bloat from tell #3). The "was it AI?" question is really the "does anyone understand this?" question wearing a trench coat.

What Steps Should I Follow to Fix Bugs in AI-Generated Code?

The most common mistake I see: opening the bug list and starting at the top. In an AI-built codebase, that means fixing symptoms inside a structure you don't understand yet — you'll fix some of them twice. The order that works (the same triage I run on paid rescues — full framework at The Crash Cart):

1. Security first, always. Exposed API keys, missing auth on endpoints, client-side "validation" as the only validation. AI-built apps ship these disproportionately, and they're the bugs that end companies. Run the free 20-point security checklist before touching anything else — it takes an evening.
2. Stabilize. Get the app running reproducibly, under version control, with a way to deploy that isn't "it worked on the builder's laptop."
3. Survey. Map what actually executes versus what's dead weight (tell #8). You can't reason about a system you haven't bounded.
4. Strip. Delete the dead code. It's not an asset; it's fog.
5. Then fix bugs — writing a failing test before each fix, so the fix stays fixed and the test suite stops being decorative.

If you'd rather have a professional read before deciding anything: I do a free 20-minute repo audit — a recorded walkthrough of what's actually in your codebase and a written summary, no strings. Owners usually walk away knowing whether they need a cleanup weekend or a real rebuild ($25K–$50K fixed, if it comes to that — you'll know before you spend a dollar).

Related guides: what is vibe coding, vibe coding examples, Vibe Debt, The Crash Cart triage framework, the 20-point security checklist.