Skip to content

Vibe Coding

How to tell if a website is vibe coded

You can tell whether a website or web app is vibe coded by checking seven public signs in your browser. They are a builder badge, a builder hosted domain, leftover builder scripts, leftover paths and meta tags, a nearly empty page source, the default look and comments the AI left behind. No single sign proves it, and a site with none of them can still be AI built. A game on a store or a phone app leaves different clues, which this guide does not cover. We built a checker for supported public builder fingerprints, and this is the manual version.

Vibe CodingVibeZero insight

Some vibe coded websites leave public clues, through the badge in the corner, the domain they sit on or scripts linked from the page. We know because we built a free checker for supported public fingerprints, and to build it we had to work out what Lovable, Bolt, v0 and Replit can leave behind. What follows is the manual version, with seven signs ordered from easiest to more technical.

It is worth defining the term before we start. Vibe coding is building software by describing it to an AI and accepting what comes back, which produces real code on real hosting, and that is what separates it from Wix or Squarespace. I come back to that difference lower down, because plenty of people conflate the two.

The badge in the corner

The free tiers of some AI builders stamp their work, so you may see an "Edit with Lovable" tab floating in the bottom right corner, a "Made in Bolt" mark pinned to an edge or a "Built with v0" line in the footer. A badge is a useful clue, but it is not enough for a confident attribution on its own.

It comes with two caveats. Paid plans often let owners remove the badge, so its absence proves nothing. A badge is also page content that anyone could copy, which puts it below technical markers as evidence.

A builder hosted domain

Some builders give new apps an address on their own infrastructure. Lovable uses lovable.app, Bolt can publish to bolt.host, Replit uses replit.app, and Base44 uses base44.app. An address on one of those domains identifies the platform serving the site. It does not prove who wrote the code or whether the owner intends to keep that address.

Once a custom domain is connected the sign disappears, and that is when you move to the page source.

Builder scripts left in the source

Right click the page, choose View Page Source, and search for the builder's plumbing. A provider controlled runtime marker can be stronger evidence than a badge or a visual style. It can remain after the owner connects a custom domain, though it can also be removed or copied.

These are markers our own ruleset can match. Lovable apps may load a runtime script from cdn.gpteng.co, and newer ones can carry platform scripts at /__l5e/ and ~flock.js on the site's own domain, while Base44 apps can ship a reference to the @base44/sdk package. Provider specific runtime evidence can support a strong public association, but it still does not reconstruct authorship or the full development history.

Leftover paths and meta tags

Stay in that same page source view for three more searches. Lovable projects can use /lovable-uploads/ for uploaded assets and may expose a meta tag named lovable-tagger. Some builders fill the standard generator meta tag with their own name. These are useful clues when they appear together, but an asset path or a tag can be copied and neither is a record of authorship.

A nearly empty page source

Some AI builder projects ship as client rendered apps, so View Page Source shows little readable content. You may find a div with id="root", a script loading /assets/index-[something].js and not much else because the content arrives after JavaScript runs. Plenty of hand built sites use the same approach.

An empty shell plus that /assets/ bundle path can indicate a Vite single page app. It cannot tell you whether AI was involved. Treat it as a reason to look for provider evidence, not as a verdict.

The default look

You have probably seen this website before, because it has a dark background, a headline with a purple to blue gradient sliding through it, pill shaped buttons, rounded corners on everything, Inter or Geist for the font, and the same icon set, Lucide, on every card. AI builders lean on the same component library, shadcn/ui, and the same visual defaults, so their output converges on one look.

Be careful with this one, because plenty of hand built sites use the same kit, including sites by teams who simply like shadcn. The default look is a prompt to inspect the source, not evidence of who built it. Vibe Check does not use visual style to attribute a builder.

Comments the AI left behind

AI assisted static pages sometimes ship with section labels such as Hero or Testimonials, decorative divider comments and emoji left in the markup. These are weak manual clues because a person can write the same comments and build tools can remove them. Vibe Check may report corroborated build comments as supporting context, but it does not use them to identify a provider.

What proves nothing

Two false positives are worth naming, because both get thrown around as gotchas.

The tech stack proves nothing. React, Vite and Supabase power a lot of carefully hand built software. A generic framework or library cannot identify a builder. Our checker reports those patterns as context rather than provider attribution, and anyone who tells you "it uses React so it is vibe coded" is guessing.

Website builders prove nothing either. Shopify, Wix, Squarespace, Webflow and WordPress sites are built from templates in an editor, which is no code, a different thing entirely that long predates AI, so calling a Squarespace site vibe coded is just wrong.

The catch

A site with none of these markers can still be AI built. Code agents such as Cursor, Claude Code or Windsurf write into ordinary repositories that can deploy without a provider fingerprint. A public declaration or several independent traces may support an indicative assessment, but their absence proves nothing. We wrote that limit into our checker, and it applies just as hard to manual checking.

Check the public evidence

If you would rather not read page source, the checker automates the supported hosting, runtime, script and markup checks above, then shows the exact evidence it found. It reports weaker interface and code patterns separately from provider attribution. When no supported provider fingerprint is present, it says so rather than guessing.

If you own the site

A builder fingerprint does not tell you whether an app is ready for customers. Veracode's 2025 testing found security flaws in 45% of its AI code generation tests. That is a test result, not a fault rate for live apps. Our vulnerabilities guide explains the checks behind exposed keys, missing rate limits and over privileged database roles.

Vibe Scan checks selected public security signals. If you want a person to look across the public experience, accessibility, performance and security findings, request the free public app review. A senior engineer sends a PDF within 24 calendar hours of receiving a working public URL. Source code, logged in areas and private infrastructure sit outside the free review. The paid audit covers deeper manual inspection and remediation.

More useful thinking, only when it is ready

New articles and sourced Field Notes, roughly monthly. No recycled AI news and no automated sales sequence.