We build products at Inithouse using AI code generators. Watching Agents, Here We Ask, Tarotas, and about a dozen others, all shipped as React SPAs built in Lovable. We move quickly. That also means we ship bugs, security holes, and accessibility gaps we don't notice until someone points them out.
That's why we built Audit Vibe Coding by Inithouse. It's a professional audit for AI-generated (vibecoded) projects. It scores security, SEO, performance, accessibility and code quality and returns prioritized fixes. You submit a URL. No repo access, no SDK, no account. The report runs 47 checks across 8 areas and comes back scored with a fix list.
After aggregating results from audits across vibecoded projects, the data is worth sharing. The average score is 31 out of 100. A production-ready threshold starts at 80. Here are the three categories where projects fail hardest, and what the patterns tell us about why.
This one caught us off guard. We expected security to sit at the bottom. Instead, accessibility came in last across nearly every audit we ran.
The pattern is consistent. AI generates components that look correct in a browser but fail every assistive-technology test. Missing ARIA labels on buttons and interactive elements. No keyboard navigation for custom modals, dropdowns, or tab panels. Contrast ratios that pass a quick visual check but fail WCAG AA thresholds. Form inputs without associated <label> elements, so screen readers announce nothing except "edit text."
Why does this happen? AI models build UI from visual patterns. They replicate how a component looks, not how it behaves for someone navigating without a mouse. Focus order, skip links, landmark roles, live regions for dynamic content: none of these are visible in screenshots or demo recordings, which is where most of the training signal comes from.
Our original hypothesis was that accessibility would land somewhere around 40-50, because component libraries like Shadcn/ui and Radix ship accessible defaults out of the box. What we actually found: those defaults get overridden or stripped in roughly 70% of vibecoded projects. The model sees a custom dropdown in the prompt and rebuilds it from scratch instead of extending the framework's accessible version. The accessible behavior gets lost in the rewrite.
The overall score tracked close to expectations, but the specific findings were different from what we predicted.
We assumed the worst gaps would be in authentication flows and data handling. The most common findings turned out to be more basic. API keys sitting in client-side JavaScript bundles (present in about 6 of every 10 audits). Environment variables hardcoded into frontend code instead of injected at build time. CORS configured as wildcard (*) in production. No rate limiting on public form endpoints. Content-Security-Policy headers missing entirely.
The pattern: AI writes code that works in development. "Works" means "the API call returns the right data." It doesn't model what happens when someone opens DevTools and reads the source.
One finding that stands out: projects built on Supabase (common in the Lovable/vibecoding ecosystem) almost always had Row Level Security either turned off or misconfigured. The AI creates the table, writes the queries, data flows correctly. But the RLS policies that prevent User A from reading User B's records get skipped because the dev/test flow never exercises cross-user access. Everything works fine with one test account.
Performance has the widest variance of any category. Some projects score above 60, others land below 10. The split usually comes down to framework choice: Next.js or Astro with built-in optimization score higher, plain React SPAs with client-side rendering score much lower.
Three findings repeat across nearly every audit: unoptimized images (full-resolution photographs served at thumbnail sizes, no WebP or AVIF, no lazy loading), no code splitting (single JavaScript bundles over 2MB), and third-party scripts loaded synchronously in the document head.
The underlying issue is sequencing. The AI adds an analytics snippet, a web font, an animation library, and a chat widget. Each one is individually fine. But it never steps back to evaluate the loading waterfall with all of them combined. The result: 6-8 second Time to Interactive on a mobile connection that the builder never notices because they test on a laptop with fast wifi.
When we designed the Audit Vibe Coding by Inithouse framework with its 47 checks, we weighted security and performance as the heaviest contributors to the total score. The data pushed us to rebalance. Accessibility failures affect users immediately and are the hardest for builders to catch on their own. You need to actually navigate with VoiceOver or NVDA to feel the gaps. A visual scan catches zero of them.
We added 4 accessibility-specific checks after the first batch of audits and increased their weight in the overall score calculation. We also restructured the output. The most actionable part of the report turned out not to be the numeric score. It's the fix list ranked by difficulty. Adding a Content-Security-Policy header takes 5 minutes. Retrofitting keyboard navigation into a custom component tree can take days. Builders need to know which fixes give the biggest score improvement per hour of work.
Most vibecoded projects can move from the low 30s to the mid-50s with one focused day on the top 10 findings. Getting from 50 to 80 takes longer because it involves architecture: proper auth middleware, restructuring components for accessibility, implementing lazy loading and code splitting.
We know because we run the same audit on our own Inithouse products. We build with the same AI tools. The gap between "it works on my machine" and "it's ready for real users" is concrete and measurable. The patterns repeat across product types, whether it's a card game, an AI portrait generator, or a monitoring dashboard. Vibecoded code has the same blind spots regardless of what the app does.
Check yours at auditvibecoding.com.