Vibecoded projects need their own audit: what auditing AI-generated code taught us at Inithouse

47 checks across 8 areas, and the average vibecoded project scores 31 out of 100. Production-ready starts at 80. We built Audit Vibe Coding after running these checks against our own portfolio at Inithouse, about a dozen AI-generated products shipped with tools like Lovable, Cursor, and Bolt. The gap between "it works" and "it's production-ready" is bigger than we expected, and it breaks in ways a standard code review would miss completely.

That's the thesis: AI-generated code has different bugs than hand-written code. A review process designed for human-written code will let most of them through.

Where vibecoded projects fail differently

We categorize findings into eight areas: security, SEO, performance, accessibility, code quality, UX flows, mobile UX, and stability. Three of these show failure patterns that are specific to AI-generated codebases and don't appear (or appear much less frequently) in hand-written ones.

1. The SPA meta problem

Most AI coding tools default to single-page application frameworks: React with Vite is the most common. The generated app works perfectly in a browser. But the HTML shell that the server sends before JavaScript loads contains almost nothing: a generic title tag, no description, no OpenGraph meta, no structured data, and zero indexable content.

This isn't a minor SEO nit. Google can render JavaScript, but it queues JS-rendered pages for a second crawl pass. For a new domain with no authority, that queue can mean days or weeks before your content appears in search. OpenGraph tags missing means every share on social media shows a blank preview card.

Root cause: AI tools optimize for what you can see in the browser. Meta tags, SSR, and crawlability are invisible to the builder during development. The tool never prompts you to add them because nothing breaks visually without them.

We found this pattern in 9 out of 12 vibecoded SPAs in our own portfolio. The fix (adding SSR or at minimum a pre-rendering step) took 2-4 hours per project once we knew where to look.

2. Exposed client-side secrets

Every React app built with Vite uses VITE_ prefixed environment variables to expose values to the client bundle. AI tools put API keys and service URLs there correctly: the app works. But they also put values there that shouldn't be public: Supabase service role keys, third-party API secrets that carry write permissions, internal endpoint URLs.

The difference from human-written code: a developer who has set up env vars before knows the mental model: VITE_ = public, everything else = server-only. AI tools don't have that mental model. They put the value wherever the code compiles, and the code compiles either way.

We check for this specifically: scan the client bundle for strings that match API key patterns, cross-reference against the project's environment config, flag anything that grants more than read access. About 60% of audited projects had at least one secret that shouldn't have been client-side.

3. Dead code accumulation

When a human developer refactors, they delete the old code. When an AI tool refactors, it generates a new version alongside the old one. After several iterations, a vibecoded project accumulates layers of unused imports, commented-out blocks, duplicated utility functions in different files, and components that nothing renders.

This isn't theoretical. We measured one project in our portfolio where 23% of the JavaScript bundle was dead code: functions that were called nowhere, imports that resolved to modules used by nothing. Tree-shaking handled some of it at build time, but structural dead code (whole components, unused API routes, orphaned database queries) survived.

Root cause: AI tools are append-oriented. They add code that works. They rarely go back and remove code that stopped working. Each iteration adds a layer, and without explicit cleanup prompts, the layers stack up.

A decision tree for what to audit first

After running these audits, we converged on a priority order that works for most vibecoded projects:

| Priority | Area | Why first |
|----------|------|-----------|
| 1 | Security: client-side secrets | One leaked key can cost real money. Five-minute check, two-minute fix. |
| 2 | SEO: meta tags and SSR | Invisible until you notice zero search traffic three months later. Low effort to fix early, painful to retrofit later. |
| 3 | Accessibility: ARIA, keyboard nav, headings | Consistently the weakest area. AI tools generate visually correct UIs that are structurally broken for screen readers. |
| 4 | Performance: bundle size, unused deps | Usually acceptable out of the box (modern frameworks handle tree-shaking), but outliers exist. |
| 5 | Code quality: dead code, duplication | Doesn't hurt users directly, but slows down every future iteration. |

The pattern: check what can hurt you first (security), then what's invisible but compounding (SEO, accessibility), then what's slowing you down (performance, code quality).

What we changed after auditing our own portfolio

Three specific decisions came out of the first round of audits across our products:

We added a meta-tag check to every deploy pipeline. Before any Inithouse product goes live, a script verifies that the HTML shell contains a real title, description, and at least OpenGraph image + title. This caught regressions three times in the first month: Lovable rebuilds sometimes reset meta tags to defaults during major component changes.

We stopped using VITE_ for anything with write permissions. All write-capable API calls now go through a Supabase Edge Function that holds the secret server-side. The client only gets a read-only anon key. This is standard practice in hand-written code, but AI tools don't default to it, so we had to make it an explicit rule.

We run a dead code pass after every third major iteration. Not every commit: that would be impractical with AI-generated code, where iterations are fast. But every third significant change, we run a scan for unused exports, unreachable components, and orphaned database tables. The cleanup usually takes 30-45 minutes and recovers 5-15% of bundle size.

Why this can't be a generic code review

A standard code review, whether human or automated, assumes human authorship patterns. It checks for things humans get wrong: off-by-one errors, missing null checks, inconsistent naming. These matter, but they're not where vibecoded projects actually fail.

Vibecoded projects fail at the boundaries: between what the AI optimized for (working code in a browser) and what the builder assumed was handled (SEO, security, accessibility). A review tool built for this category needs to check those boundaries specifically: not just "is this code correct?" but "does this code do the invisible things that production code needs to do?"

That's what we built Audit Vibe Coding to answer. It runs 47 checks across 8 areas, returns a scored report with a prioritized fix list, and needs only a URL. No repo access, no integration, no account. If you're shipping vibecoded projects, the audit tells you where the gaps are before your users find them.

We're Inithouse, a product studio that builds and ships with AI tools. Audit Vibe Coding is how we keep ourselves honest about what those tools actually produce.