Was this code written by AI?

Why spotting AI in code is harder than in prose

Code is a constrained language. Two engineers solving the same problem in the same framework will often arrive at nearly identical syntax, so the kind of stylistic variation that gives away AI-written essays is naturally compressed in source code. A clean, idiomatic function looks much the same whether a person or a model typed it — which is exactly why a code-specific detector matters instead of running a snippet through a text detector built for paragraphs.

What this detector keys on isn't whether the code is good. It's the texture around the logic: how comments are phrased, how consistently things are named, how evenly the formatting falls, and how much scaffolding sits around the part that actually does the work. Assistants like Copilot, ChatGPT and Claude have habits — they tend to explain themselves, reach for safe generic names, and produce code that's a little too tidy. Human work usually carries the small inconsistencies of someone building under real constraints.

What the analyzer actually looks at

When you hit Analyze, the snippet is sent over HTTPS to the TextSight API and broken down into several measurable signals, each weighed and combined into one probability:

• Comment density and tone — explanatory, textbook-style comments that narrate every step ("// loop through the array and add each item") read very differently from the terse, context-assuming notes most developers leave.
• Naming patterns — defaults like data, result, temp and item used wholesale, instead of names that carry the domain.
• Formatting uniformity — spacing, line length and structure that are almost suspiciously even, with none of the drift a person leaves behind.
• Boilerplate and scaffolding — generous error handling, defensive null checks and try/except blocks wrapped around a problem that didn't ask for them.
• Structural variety — whether the code reuses one or two safe shapes throughout, or mixes approaches the way an individual style tends to.

No single one of these proves authorship. A careful junior developer can write evenly formatted, heavily commented code; a senior engineer can paste an AI draft and leave it untouched. The score is the weighted picture, not a verdict on any one line.

How to read the result — and where it's weakest

Treat the percentage as a confidence reading, not a courtroom finding. A high score means several signals lined up toward generated code; a low one means the snippet looks more like hand-written work. The honest middle — anything that lands around the fence — usually means the sample was too short or too generic to call, and the right move is to look at more of the codebase, not to trust a single number.

There are real blind spots worth naming. Very short snippets carry almost no signal — a five-line utility function can be written exactly one sensible way. Heavily edited AI output, where a developer renamed variables and trimmed the comments, drifts toward looking human, because that's effectively what happened. And boilerplate-heavy code — config files, generated migrations, framework stubs — can read as machine-made regardless of who wrote it. None of these are flaws unique to TextSight; they're the limits of code detection itself.

So use it as a first pass, not the last word. It's most useful for triage: flagging a pull request worth a closer human review, sanity-checking a take-home submission before an interview, or settling your own suspicion about a chunk of pasted-in code. The score points you at what to examine; you still make the call.

Where a code check earns its keep

AI coding assistants are now part of almost every workflow, which makes "did a person actually write this?" a question that comes up far more than it used to:

• Hiring teams reviewing take-home assignments and live coding submissions, where the point is to see how a candidate thinks — not how well an assistant autocompletes.
• CS instructors and TAs checking whether a programming assignment reflects the student's own reasoning before a grade or an academic-integrity conversation.
• Reviewers and tech leads deciding which pull requests deserve a slower, more skeptical read.
• Engineers themselves who inherited a file, found something that smelled generated, and want a second opinion before they assume.

You can start without an account: anonymous use covers 3 short snippets a day, up to about 50 lines, and a free account raises that to 5 a day. Starter raises the daily limit to 25 a day and lifts the line cap, and Pro removes the cap and extends scanning across multiple files and whole repositories — which is where reviewing a real contribution, rather than a fragment, actually starts to make sense. Throughout, this tool only estimates authorship; it doesn't run your code, and the goal is never to help anyone slip past a reviewer — just to give the people doing the reviewing a clearer place to look.