VVibeFootprintWebsite intelligence

What a detector can honestly claim

Can you detect AI-generated website code?

Public analysis can identify delivered patterns and sometimes direct tool traces. It cannot observe private prompts, deleted markers, repository history or the human decisions between generation and deployment.

Format
Evidence and limits brief
For
Anyone evaluating claims made by AI website or code detectors
Reading time
9 minutes

Published by VibeFootprint EditorialPublished · Last reviewed

Claim boundary

Three categories of detector claims

The safest language changes with the evidence category. Most misleading reports turn an inference into an observation or an unknown into a percentage.

Observable

The delivered page contains a named builder marker.

The marker exists in the public response and can be reproduced.

Observable

The page uses recurring class, structure or design patterns.

Those patterns can be recorded from delivered HTML and assets.

Inference

The pattern cluster resembles an AI-assisted reference corpus.

Similarity depends on the selected features, corpus and model boundary.

Inference

A particular builder may have influenced part of the site.

A marker or convention can be inherited, copied, removed or introduced indirectly.

Not knowable from a URL

AI wrote 73% of the website.

A public response contains no denominator for private source creation or later human edits.

Not knowable from a URL

The website owner personally used AI.

Authorship and workflow are private provenance questions.

Why certainty breaks down

The public website is the end of a lossy pipeline

Between an initial prompt and the page you receive, code may be regenerated, refactored, bundled, minified, copied into another project or mixed with years of human work. Templates and design systems also create the same repeated patterns that detectors may associate with AI-assisted production.

This is a classic correlation problem: a feature can be predictive inside one frozen dataset without being a unique cause in the open web. A model result therefore needs a defined corpus, holdout evaluation, uncertainty and a careful label.

  • Absence of a marker is not evidence of absence
  • Presence of a marker is not a generated-code percentage
  • Visual similarity is not a defect count
  • Security posture is independent from production method

Decision matrix

Match the method to the claim

A public scan is useful when the decision fits its evidence boundary. Broader claims need broader access.

QuestionUseful evidenceWhat remains missingResponsible outcome
Does the page resemble common vibe-coding patterns?Delivered HTML, assets and visual structurePrivate workflow and complete sourceA bounded similarity assessment
Was a builder used somewhere?Direct marker plus repository or deployment historyWho used it and how much it influencedA trace with provenance caveats
Who authored the product?Contracts, commits, design history and team recordsUnrecorded collaboration and editsA provenance review, not a URL score
Is the website safe?Headers, application tests, code review and threat modelUnknown systems outside the assessmentScoped security findings with severity
Is the website good?User research, accessibility, performance and product outcomesContext-specific goals and trade-offsA multi-dimensional quality review

Applied example

Why a precise percentage can be less trustworthy

A detector reports ‘87% AI-generated’ after fetching a minified production bundle. The report does not define whether the denominator is files, tokens, components, runtime bytes or model probability.

  • The number cannot be independently interpreted without a measurement definition.
  • Minification and bundling remove or transform much of the original source structure.
  • Training-corpus similarity does not convert automatically into generated-code share.
  • The precision of the number may create confidence that the method has not earned.

Plain answers

Detector questions

Are direct builder fingerprints useless?

No. They can support a narrow, reproducible observation. The mistake is expanding that observation into a complete claim about authorship or generated-code share.

Why does VibeFootprint still use a 0–100 number?

The number is an orientation index for similarity within a frozen method. The interface pairs it with evidence breadth, score drivers and explicit limitations so it is not presented as an AI percentage.

Could detection improve with repository access?

Repository history, source maps and process records can improve provenance analysis, but mixed authorship, copied code and rewritten history still require careful interpretation.

Source notes

References used for this guide

We prefer first-party standards, primary documentation and a visible interpretation boundary. Links are provided for verification and deeper implementation work.

VibeFootprint methodology

Defines the public-surface evidence boundary and the meaning of the similarity index.

NIST guidance on measurement uncertainty

Background on stating measurement results with an explicit uncertainty framework.

Google guidance on generative AI content

An example of evaluating usefulness and policy compliance rather than assuming one production method determines quality.

Apply the framework

Review a real public website.

See its pattern-similarity index, evidence breadth, separate security baseline and concrete findings.

Run the free scan