One’s Vibe

Blog · July 11, 2026

The Scar Tissue Census

What scanning 1,495 live, AI-built products taught us about vibe-coding's real pitfalls — and the one thing that predicts them.

One's Vibe is itself a vibe-coded product: specced with an AI, built with an AI, and mostly run by scripted agents. In its first weeks it shipped mistakes we are not proud of — a soft 404 that served a 200, an Open Graph card that never rendered, a homepage that briefly returned 500. Then we noticed something more useful than our own embarrassment: almost none of the mistakes were in the code. They were in the thin layer around it — the metadata, the share cards, the broken link nobody clicks in dev but everybody hits in production.

So we started scanning for that layer on every project we list. This is the census of what we found across 1,495 live, AI-built products — the scar tissue of the vibe-coding era.

What we check, and what we refuse to

First, the boundary, because it is the whole point. We do not audit security and we do not judge quality. A passing scan is a fact — "we reached this URL and it served these things publicly" — never an endorsement. The checks are non-intrusive: we look only at what a site already serves to anyone with a browser. We never log in, never probe authenticated endpoints, never send an attack payload, never download a file. Every fetch runs in an isolated checker behind an SSRF guard, on a separate process from the app — the same boundary that lets us verify a stranger's URL without trusting it.

Within that boundary we run two families of check on each published project, nightly for new arrivals and weekly for everything:

  • Site-health suggestions — a dozen web-app hygiene checks: Open Graph and Twitter cards, favicon, <title> and meta description, a single <h1>, a viewport tag, an accidental noindex, image alt coverage, a soft-404 probe, and up to eight sampled internal links.
  • Security self-check — non-intrusive hygiene only: secrets left in client code, an exposed .git, a published source map, and a Google Safe Browsing lookup.

The health suggestions are public as a count on each project; the details, and the entire security check, are private to the maker who claims the project. We report the aggregate here and name no one.

The census

Of 1,495 scanned projects, 989 — two in three — carry at least one health suggestion. Not broken, not unsafe: just missing a piece of the layer that makes a live thing legible to search engines, social cards, and screen readers. Here is how the 2,063 suggestions break down.

SuggestionProjectsShare
Nonexistent paths return 200 (soft 404)43329%
Incomplete Open Graph tags40427%
No <h1> heading38626%
Missing Twitter card30520%
Images without alt text1289%
No meta description1268%
Favicon unreachable1097%
A sampled internal link is broken997%
og:image set but unreachable453%
No <title>131%
Accidental noindex90.6%
No viewport tag60.4%

A few of these deserve a sentence.

The soft 404 is the most common scar, and the quietest. A soft 404 is when a page that should not exist — /this-was-never-a-page — answers 200 OK with your homepage instead of 404 Not Found. It looks fine to a human and lies to a machine: search engines index phantom pages, monitoring never fires, and a broken link never announces itself. Nearly a third of live AI-built sites do this, almost always because a single-page-app fallback was wired to catch everything.

Incomplete Open Graph is the most visible. When someone posts your link on X or in a group chat and it renders as a bare grey rectangle instead of a card with a title and image — that is an incomplete og: set. Twenty-seven percent of projects ship without the full trio, and another 3% point og:image at a URL that 404s. It costs nothing to fix and it is the difference between a link that gets clicked and one that gets scrolled past.

A missing `<h1>` and no `alt` text are the accessibility tax. A quarter of sites have no top-level heading; nine percent ship images a screen reader will skip entirely. Neither breaks the page for a sighted user, which is exactly why they survive to production.

The one split that mattered

We sliced the data every way we could. Where a project was discovered — X, Hacker News, Reddit — made no real difference: hit rates clustered between 62% and 74% regardless. We were ready to write "the pitfalls are universal" and move on.

Then we sliced by where the project is hosted, and the universe split cleanly in half.

HostingProjectsAvg. suggestions
GitHub Pages173.24
Netlify482.25
Render261.50
Cloudflare5871.40
Vercel4801.16
Lovable520.46

Read the top and bottom rows together. A hand-rolled GitHub Pages site averages 3.24 suggestions; a site built on Lovable — an AI app-builder — averages 0.46. That is a 7× gap, and it is not about the maker's skill. It is about who owns the metadata layer.

When you build on an opinionated AI platform, the platform quietly fills in the boilerplate: it ships a viewport tag, a favicon, a sane <title>, an OG card, a real 404. When you hand-roll static HTML, you own every one of those, and the vibe-coding workflow — describe the feature, ship the feature — optimizes for the thing you asked for and silently skips the scaffolding you didn't. The scar tissue is not a symptom of building fast. It is a symptom of building the interesting layer and inheriting nothing underneath it.

The security footnote

The security self-check is deliberately narrow, and the news is mostly good. Across every scanned project, Google Safe Browsing flagged zero — no malware, no phishing in the gallery. Client-side hygiene was cleaner than we feared, but not spotless: a handful of sites shipped a published source map or a Google Maps API key visible in client code (usually harmless, sometimes not), and four projects exposed something genuinely sensitive — a live secret or a readable .git directory. Those makers were told privately the moment we found it; we name none of them, and we never will. Existence of a security finding is never public — only the maker who claims the project sees it.

What we conclude

Two in three live, AI-built products ship with a piece of the web-legibility layer missing. The gap is real, it is common, and — this is the important part — it is not a code problem and not a competence problem. The code works; that is why these projects are in a gallery of things you can actually try. What's missing is the unglamorous scaffolding that AI coding is structurally bad at volunteering: the 404 that should 404, the card that should render, the heading a screen reader needs.

That is not an argument against vibe-coding. It is an argument for a second pair of eyes on the layer the vibe never mentions. It is, frankly, part of why this gallery exists — and why a maker who claims their project here gets the full private report, a one-click rescan, and fifteen minutes later, a clean bill. The scar tissue is easy to heal once someone points at it. Mostly, no one does.

Numbers snapshot the gallery at publication and will drift as we scan and as makers fix. The method — non-intrusive, isolated, aggregate-only — does not.

The Editor
The Editor · One's Vibe
“One's vibe, another's poison.”

Comments

Sign in to join the discussion.