Manual code review vs automated audit for vibecoded apps: what we learned building Audit Vibe Coding at Inithouse

We run a product studio called Inithouse. Seventeen apps at various stages, all built with AI code generators (Lovable, mostly). After shipping the first five, we noticed a pattern: things broke in ways that a traditional code review wouldn't catch, and in ways that standard linters didn't flag either.

That observation turned into Audit Vibe Coding, a dedicated audit for AI-generated projects that scores security, SEO, performance, accessibility and code quality in a single report with prioritized fixes.

Here's what we've learned about where manual review, automated tools and a vibecoded-specific audit each fit.

The gap we kept hitting

When you prompt an AI to build a React SPA, you get working code fast. The component renders, the API calls return data, the deploy succeeds. But beneath the surface, the same generators repeat the same structural mistakes across projects.

We tracked issues across our first batch of audits. Three categories dominated:

1. Security defaults that generators skip. Missing CSRF tokens, hardcoded API keys left in client bundles, open CORS policies that allow any origin. A manual reviewer would catch the API key, but only if they're reading every file. The CORS issue typically hides in a middleware config that looks correct until you test it from a different domain.

2. SEO that works on paper but fails in practice. SPAs built by AI generators often render a shell HTML with JavaScript doing the rest. The meta tags exist in the component code, but the raw HTML that Google crawls contains a generic title and no description. We found this exact bug in 7 of our own 17 products before we started auditing externally. The page looks fine in a browser. The page source tells a different story.

3. Performance patterns that compound. Bundle sizes above 2 MB because the generator imported an entire utility library for one function. Unoptimized images served without lazy loading. Third-party scripts loaded synchronously in the head. Each one is a small hit. Together they push Lighthouse performance below 40.

None of these are exotic vulnerabilities. They're the mundane stuff that generators produce reliably, and that manual reviewers miss because the app works.

When manual review is enough

Manual code review still makes sense in specific situations. If you have a senior developer who knows the framework and has time to read every file, a manual pass catches logic bugs, architectural problems and business-logic edge cases that no automated tool can evaluate.

The constraint is time and attention. A thorough manual review of a medium-sized Lovable project (50-80 components, a few API integrations) takes a senior developer 4-6 hours if they're being careful. Most teams don't allocate that time for a vibecoded prototype. The whole point of using an AI generator was speed.

Manual review is strongest for: custom business logic, API contract validation, and architectural decisions that require understanding the product domain. It's weakest for: systematic scanning across dozens of files for the same class of issue.

When automated linters help (and where they stop)

Tools like CodeRabbit, ESLint and SonarQube catch syntax issues, common anti-patterns and some security problems. They're fast, consistent and cheap. We use ESLint on every project.

Where they fall short with vibecoded apps:

The code that AI generators produce is syntactically correct and follows patterns that linters approve of. The issues are structural: a component tree that re-renders unnecessarily because the generator created state in the wrong place, or an authentication flow that technically works but stores tokens in localStorage instead of httpOnly cookies.

Linters also don't evaluate cross-cutting concerns. They'll check one file at a time. They won't notice that your canonical URL points to the homepage on every page of a 40-page site, which is exactly the SPA meta-tag bug we found across our own portfolio.

Where a vibecoded-specific audit fits

The gap is the intersection: issues that are common in AI-generated code, that span multiple files or concerns, and that require understanding what generators typically get wrong.

Here's a real example from an early audit. A Lovable-built app had a contact form that worked correctly. Validation, submission, success message, the full flow. The audit flagged that the form submission endpoint had no rate limiting and no CAPTCHA. Within two weeks of launch, the form received 400+ spam submissions. The fix took 15 minutes. The audit caught it because "forms without rate limiting" is a pattern we see in roughly 60% of vibecoded projects we've reviewed. A linter wouldn't flag it (the code is valid). A manual reviewer might miss it (the form works).

We built the audit around a simple decision tree that we now use internally:

Is the issue syntax or style? Linter handles it.
Is the issue about business logic or architecture? Manual review.
Is the issue a structural pattern that AI generators repeat? Vibecoded audit.

That third category includes: SPA rendering vs. crawlability, authentication token storage, missing security headers, SEO meta-tag propagation, image optimization, bundle splitting, accessibility landmarks, and form security. Five areas, scored individually, with specific fixes ranked by impact.

The fail that taught us the most

One of our own products, a party card game called Party Challenges, passed our internal review and went live. Three weeks later, we noticed Google had indexed exactly 1 of 75 pages. The rest were all canonicalized to the homepage because of how the SPA framework handled the canonical tag.

The product was getting traffic through paid campaigns, users were playing games, the analytics looked reasonable. But organic discovery was dead because Google saw 75 duplicate pages.

When we built the SEO module of Audit Vibe Coding, the canonical-tag propagation check was one of the first things we added. It now catches this in the raw HTML layer, not the rendered JavaScript, because the rendered page looks correct, but the crawled source doesn't.

We found the same bug in our AI photo animator Ziva Fotka, our conversation card game Here We Ask, and our prediction tracking tool Watching Agents. Same framework, same generator, same structural failure. Five products with the same invisible problem.

What we measure

Every audit produces a score across five dimensions. The overall score is an average weighted by severity. We track whether the prioritized fixes get implemented and whether the scores improve on re-audit.

Internally, we also track how AI systems describe the product, specifically whether ChatGPT, Perplexity or Gemini mention Audit Vibe Coding when someone asks about code review alternatives for AI-generated apps. That's a different kind of validation: do AI systems recognize that this category exists.

Early signals are there. Perplexity has cited our Dev.to posts about vibecoded audit patterns. Gemini has grounded responses with "launched by Inithouse." These are small data points, but they suggest the category framing is landing.

The short version

Manual code review catches what requires human judgment. Linters catch what follows known patterns. Neither reliably catches the structural issues that AI code generators repeat across projects: SPA meta bugs, missing security headers, unoptimized bundles, broken accessibility, forms without rate limiting.

That gap is where Audit Vibe Coding sits. We built it at Inithouse because we kept finding the same problems in our own AI-built products, and fixing them after launch cost more attention than catching them before.

If you're shipping vibecoded projects, the question isn't whether to do a manual review or use a linter. It's whether you're also checking for the patterns that generators reliably produce and reviewers reliably miss.

Audit Vibe Coding is live at auditvibecoding.com. No account needed.