AI Usage Analyzer: every check explained

The AI Usage Analyzer reads a website or a code repository and estimates how much of it was written by a person and how much was generated by artificial intelligence. This section explains, in plain language, every clue it looks for.

This page documents, in plain language, every check the AI Usage Analyzer runs. No detector is definitive on its own: results are calibrated guidance with explicit confidence levels, never proof of provenance. Every heading below is linkable: hover a title and copy its anchor.

How the check works#

When you give the AI Usage Analyzer a link, it fetches the page or repository, looks through the readable files, and counts small clues. No single clue is proof. A verdict is only formed when several independent clues agree. The result is a guide, not an accusation.

Two questions, kept separate: the analyzer asks two different questions about every file. First: does this look like a person or a machine wrote it? Second: is the work carefully finished, or rushed and left messy? Keeping the two questions apart matters, because tidy AI work is not the same as sloppy human work.
The human percentage: The headline number is how much of the project appears to be genuinely human-written. A high human percentage is good. A high, easily recognisable amount of AI is what lowers the score.
The authenticity grade: The A to F grade is an authenticity grade. It is driven mainly by how much AI usage is detected and secondarily by how many quality problems are found. Even neat AI code lowers the grade, because the badge certifies human authorship.
Confidence level: Every result comes with a confidence level of low, medium or high, based on how many strong clues were found and how much readable content there was. Small pages get a low confidence on purpose.
What is ignored: Downloaded libraries, automatically generated files, images and other non-code files are set aside before the check, so they cannot unfairly change the result. Compressed program files are still scanned for brand fingerprints even though their style cannot be judged.

Tell-tale AI writing in comments and text#

AI assistants have writing habits. When their output is pasted into a project without cleanup, those habits stay in the comments and notes inside the files. These are some of the strongest and clearest clues.

Leftover placeholder notes: Notes like "your code here" or "rest of the code" mean an unfinished answer was pasted in and never completed.
Assistant chatter: Phrases like "certainly!", "here is the updated code" or "I hope this helps" are how a chatbot talks, not how code is normally written.
AI tool signatures: Some tools sign their work with lines like "Generated with" a named assistant. That is direct evidence of the tool used.
Comments that narrate the obvious: A comment that simply repeats what the next line already says is a habit of machine-written code; people rarely bother.
Signature AI vocabulary: Words such as "delve", "showcase", "pivotal", "seamless" and "meticulous", used together, are strongly associated with AI writing.
Dash overuse: Assistants use the long dash far more often than most people. A cluster of them is a small but real clue.
Emoji in comments and headings: Sprinkling emoji through code comments and buttons is uncommon in careful human work but common in AI output.
Marketing language: Boastful phrases like "blazingly fast" or "robust and scalable" inside code read like advertising copy, not engineering notes.
Edit-narration comments: Comments like "Updated section" or "Added new feature" are left behind when someone repeatedly asks an assistant to change a page.

Website look-and-feel fingerprints#

AI design tools reach for the same visual recipe again and again. When many of these defaults appear together, the page was very likely generated rather than hand-crafted.

The signature purple gradient: One specific purple-to-violet gradient appears in a huge number of AI-generated pages. It is almost a logo for machine-made design.
Other default purple tones: Even without the exact signature, the indigo and violet colours that ship as defaults in popular tools point the same way.
The default toolkit: A particular bundle of building blocks (a specific icon set, ready-made components and utility styling) is the standard kit these tools assemble. Finding several together is a strong sign.
The stock landing-page layout: Hero banner, three feature cards, testimonials, pricing, frequently-asked-questions: the same running order used by nearly every template.
Section banner comments: Big comment labels like "Hero Section" or "Features Section" dividing the page are a generation habit.
Styling loaded from a shortcut link: Loading the styling toolkit straight from an internet link is the quick prototype default, not how finished sites are built.
The default font and icon pairing: A specific web font paired with a specific icon library is the out-of-the-box combination these tools use.
Automatic scroll effects: Ready-made smooth-scrolling and fade-in-on-scroll snippets are copied in wholesale by generators.
The universal reset block and generic colour variables: A boilerplate style reset and colours named simply "primary" and "secondary" are textbook scaffolding.
Emoji inside headings and buttons: Decorative emoji placed inside page headings and buttons is a common generated-page flourish.

AI website builders and framework leftovers#

Some tools build an entire website from a single prompt. They leave behind unmistakable traces in file names, hidden markers and untouched starter text. These are among the most reliable clues of all.

Builder brand markers: Hidden identifiers and upload folders left by well-known one-prompt website builders are direct evidence of the tool that made the site.
Build-tool file names: File and folder names produced automatically by popular app frameworks reveal how the site was assembled, even when the file itself is unreadable machine code.
Untouched starter pages: Default titles like "Create Next App" or "Vite + React", the "You need to enable JavaScript" notice, and empty starter containers show a template was never personalised.
Unrendered template tokens: Leftover placeholders that were supposed to be filled in automatically, but were shipped as-is, mark hurried generated output.
Everything crammed into one file: A single page with hundreds of lines of styling and script all inlined together is the shape of a straight copy-paste from a chat window.

Placeholder and unfinished content#

Generated pages are frequently shipped with the sample content still in place. These leftovers show the work was never truly finished for real use.

Sample names, emails and phone numbers: Fictional contacts like "john@example.com", "Your Company" or a "555" phone number are stand-ins that a real owner would have replaced.
Latin filler text: The classic "lorem ipsum" placeholder paragraphs mean the real words were never written.
Buttons and links that go nowhere: A page full of links that lead back to the same spot is a mock-up, not a working site.
Default project names: Names like "my-app" or "my-project" left in the settings show the starter was never renamed.
Tutorial startup messages: Console messages copied straight from a getting-started guide are a small sign of stitched-together code.

Security mistakes assistants commonly make#

AI tools learned from years of tutorial code that took shortcuts for the sake of a quick demo. They reproduce those same shortcuts, which turn into real security weaknesses. These carry the most weight in the score.

Passwords and keys written into the code: Secret keys and passwords typed directly into files are a serious risk, and assistants do this routinely.
Well-known placeholder secrets: Stock secret values like "your-secret-key" or "supersecret" are favourites that assistants reuse across projects, which makes them easy to guess.
Doors left open to any website: A permissive setting that lets any website talk to the app, combined with sign-in credentials, is the classic generated-code vulnerability.
Demo login details: Built-in accounts like "admin123" that were never removed leave an obvious way in.
Sign-in tokens kept in an unsafe place: Storing a user's sign-in token where any injected script can read it exposes accounts to takeover.
Cookies without safety flags: Sign-in cookies set without the standard protective flags can be stolen or misused.
Secrets exposed to the public side: A secret placed where the visitor's browser can read it is effectively published to everyone.
Master database keys in the browser: The all-powerful database key reachable from the public page hands full control to anyone who looks.
Unsafe handling of user input: Building database queries or web content by gluing raw user input together opens the door to well-known attacks.
Debug mode left switched on: Shipping with debugging enabled leaks internal details to the public.
Insecure resource links: Loading parts of a secure page over an insecure connection weakens the whole page.
Default database addresses: Connection details copied straight from a tutorial show the setup was never made real.

Code structure and style fingerprints#

Machine-written code is often too tidy. Its spacing, naming and structure are more uniform and more textbook-perfect than the code people write under real deadlines. That very neatness is a clue.

Unnaturally even spacing: People vary their spacing and blank lines naturally. Code where every line is spaced with machine regularity stands out.
A note on top of every single function: When every function, even trivial ones, carries a tidy description in the same template, that uniformity points to generation.
Over-explained simple functions: A one-line function wrapped in a formal description it does not need is a classic assistant habit.
Extremely long textbook names: Names like "total_user_input_character_count" are the descriptive-but-impractical style assistants prefer.
Textbook error message pattern: The exact "print an error message" style of handling problems is straight out of introductory examples.
Uniform textbook structure: Full type labels, a description on every function and a standard program entry point all at once is the hallmark of by-the-book generated code.
Unnecessary layers of abstraction: Elaborate structures built for a task that does not need them are a known over-engineering habit of assistants.
Generic names everywhere: A high count of vague names like "data", "result" and "temp" in real code suggests little human thought went into naming.
Mixed naming styles: Two different naming conventions used side by side for the same kind of thing points to stitched-together sources.

Quality problems and error handling#

This group looks at whether the work was finished with care. Missing safeguards and copied-in debugging leftovers show code that was generated and shipped without a proper review.

Errors quietly swallowed: Code that catches a problem and then ignores it hides real failures and is a frequent generated-code shortcut.
Catch-everything handlers: Handling every possible error the same vague way, instead of the specific ones expected, is a tell of unreviewed code.
Leftover debugging output: Debugging print-outs and markers scattered through the code were meant to be removed before release.
Missing clean-up after timers and listeners: Starting a timer or a listener without ever stopping it is a common oversight in generated interface code.
Assuming a reply is always valid: Reading a server reply without checking it is the expected type is a fragile shortcut.
Files opened without safe closing: Opening files without the standard safe-closing pattern risks leaks and is against normal practice.
Dead code that never runs: Blocks written so they can never actually execute are needless scaffolding left behind.

Dependency and correctness red flags#

Assistants sometimes invent things that do not exist or produce needlessly complicated code. These clues point to work that may not even function correctly.

Imagined libraries: References to outside libraries that are not actually installed anywhere may be invented, a well-documented failure of AI tools.
Over-complicated functions: A single function packed with far too many decisions is hard to maintain and often machine-produced.
Very long functions: Functions that stretch on for well over a hundred lines usually should have been broken up.
Copy-pasted repetition: The same block of logic repeated instead of shared is a smell of quick generation.
Everything-in-one-file modules: A single oversized file mixing many unrelated jobs is a known generated anti-pattern.
Data-fetching done the fragile way: A common interface mistake, fetching information without protection against retries or duplicate requests, is a frequent AI habit.
Outdated or loose coding shortcuts: Old-style declarations and vague catch-all types in modern code point to defaults an assistant reached for.

AI-generated images and artwork#

Beyond the code and text, the analyzer looks at the pictures themselves. It examines up to twenty images (chosen evenly across the whole set when there are more) and asks a vision model to judge each one, giving every picture its own A-to-F authenticity grade. All images are reviewed at the same time to keep it fast.

Hands, fingers and faces: AI pictures still slip up on hands with extra or fused fingers, and on faces with strange teeth, eyes or ears.
Waxy, too-perfect skin: Skin that looks plastic, airbrushed or unnaturally smooth, without the natural imperfections of a real photo, is a common giveaway.
Garbled text in the picture: Signs, labels and packaging with letters that spell nonsense are one of the clearest signs a picture was generated.
Lighting and shadows that do not add up: Shadows falling the wrong way, or some objects casting shadows while others do not, reveal that no real light source existed.
Warped backgrounds and impossible shapes: Bent architecture, melted objects and geometry that could not exist in reality are classic generation artifacts.
The too-perfect, over-smooth look: A mathematically smooth, over-saturated, dreamlike finish across the whole image is typical of image generators.
Sensible exceptions: Ordinary screenshots, logos, diagrams and real product photos are recognised as such and are not mistaken for AI art.
A grade for every image: Each reviewed picture receives its own grade and a short explanation, which are kept and shown in the report so you can see exactly why.

Read-me and documentation smell#

The read-me file that introduces a project has its own generated style: over-structured, decorated with emoji, padded with badges and written in an over-eager tone.

Generic read-me skeleton: A stack of emoji-topped headings with the same boilerplate sections and no project-specific detail is a generated-introduction pattern.
Emoji-topped headings: Every heading prefixed with an emoji is a strong stylistic tell in project documentation.
Badge stuffing: A long row of decorative status badges padding out the top of a read-me is a cosmetic generated habit.
Signature AI phrasing: The "it is not just X, it is Y" sentence shape and similar constructions are characteristic of assistant prose.