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.

Rendered page signals#

For a live website, the analyzer goes a step further than reading its files: it opens the home page in a real headless browser and inspects what a visitor's browser actually produces, computed styles, the census of class names in use, meta tags, headings and page structure, console warnings, the hosts behind every loaded resource, and a full-page screenshot. This rendered-page pass only ever runs once, against the home page, and only for a live website: a git repository has nothing to render, and if a browser could not be launched the analyzer simply skips this pass and relies on the file-based checks above. Underneath, these checks are organised into eight categories running forty-nine individual signal checks against the captured page; the list below groups them by theme.

AI website builder fingerprints: the strongest and most direct evidence in this section. One-prompt website builders leave behind a hidden badge, a loader script, a "generator" meta tag, or a distinctive hosting subdomain. The analyzer recognises Lovable, Bolt.new, Replit, Base44, Framer, Wix, Webflow, GoDaddy, Squarespace and embedded Claude Artifacts by name, plus a softer corroborating check for a cluster of shadcn/ui and Radix component markers and for hosting on a generic Vercel, Netlify or Databutton subdomain.
Color and gradient defaults: the exact purple-to-violet gradient and the handful of indigo and violet accent colours that ship as defaults in popular design tools, an oversized glowing purple shadow, an all-dark default theme, and a colour token in the shadcn/ui default lightness band.
Typography defaults: a small set of fonts, Inter, Poppins, Manrope, Geist, Space Grotesk, DM Sans and Plus Jakarta Sans, are the out-of-the-box choice in nearly every AI design tool, especially when the whole rendered page uses only one font family, when a decorative monospace font shows up in a heading or button, or when the page loads the exact canonical Google Fonts weight set these tools request.
Boilerplate layout shapes: the hero-features-testimonials-pricing-FAQ section running order, a translucent blurred navigation bar, one class name repeated across many near-identical cards, and a page full of rendered links that lead nowhere are the same generated shape seen again and again.
Cliche marketing copy: rendered headings and meta text are checked for stock phrases like "unlock the power of" or "take your business to the next level", a cluster of inflated buzzwords, decorative emoji inside a heading, and the same handful of canonical frequently-asked-questions used by countless landing pages.
Neglected SEO and metadata: a missing meta description, structured data, social preview image, page language, canonical link or favicon, and the same meta description reused across every page of a site, are the kind of basic housekeeping a real launch usually gets right and a generated page often skips.
Accessibility shortcuts: generic or duplicated image alt text, a run of images with no alt text at all, and a heading structure that jumps straight from a top-level heading to a much deeper one are quick tells of markup nobody reviewed with real visitors in mind.
Never-productionized build artifacts: loading the Tailwind styling toolkit or React straight from a public content-delivery link, a browser console still showing development-build warnings, unhashed script filenames, an unedited default framework page title, and placeholder copy or a placeholder image host left in the page all mean a prototype build shipped as the live site.
Builder matches decide, everything else only nudges: a confirmed builder fingerprint is treated as decisive evidence on its own. Every other rendered-page signal in this section moves the overall score by only a small, deliberately cautious amount, and only when several of them show up together. Using shadcn/ui, Tailwind, Inter or any other widely used default is completely ordinary and never raises the score by itself.

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.

Starter template and boilerplate provenance#

The canonical definition says slop ships defaults. Those defaults are not only the model's: a
project that is an unmodified starter template or kitchen-sink boilerplate ships its scaffold's
defaults, so recognisable template provenance counts against the authenticity grade. The evidence
is scored and every marker is listed in the report; a project genuinely built on top of a starter,
with its own name, its own README and real application code, keeps most of its grade.

Known template identity: the package manifest still carries a known starter's name, a known
template publisher as its author, or scaffold metadata a generator wrote (for example the
create-t3-app init record).
Template marketing in the read-me: the read-me still says what the template's read-me said:
"boilerplate and starter for", "open-source template built with", "bootstrapped with", one-click
deploy buttons, hosted demo links and sponsor sections.
Kitchen-sink scaffold constellation: a large pile of standard scaffold artifacts (Storybook,
Husky, commitlint, lint-staged, Playwright, Vitest, Drizzle, Crowdin, semantic-release and
friends) arriving together is the signature of a generated setup, not of a project that grew.
Confidence gating: weak evidence changes nothing; only a confident template score lowers the
grade, and near-certain evidence lowers it further. The influence is a floor on the defaults
share, never a replacement for the code analysis.
Untouched templates are slop: when the evidence is near-certain, the verdict category is
ai-slop, whatever the scaffold's code quality. Shipping defaults as-is is the definition of
slop; the curation in a starter belongs to the template author, not to the project presenting
it. Confident-but-partial evidence caps the category at uncertain instead.