Vibe coding is a way of building software where you describe what you want in plain English and an AI tool writes most of the code for you. The term was popularised by Andrej Karpathy in early 2025. Tools like Cursor, Claude, GitHub Copilot, Lovable and Replit let founders and non-engineers ship working prototypes incredibly fast — but the speed comes at the cost of a deep understanding of what the generated code actually does, which is exactly why a proper review matters before launch.

How do I review code that was written by an AI?

Review it in small diffs rather than huge dumps, and start from the prompt that generated it so you can tell whether the AI built what was asked. Focus your attention on the high-risk areas first: secrets and API keys, authentication and authorization, input validation, rate limiting, and error handling. If a change is hard to understand, paste it back into the AI and ask it to explain the code in plain English and list what could go wrong — then verify those answers yourself rather than trusting them.

Is vibe coding safe for production apps?

Vibe coding is great for prototypes and early validation, but AI-generated code regularly ships with exposed secrets, weak authentication, missing input validation and no rate limiting. None of those are visible in a working demo. Vibe coding is safe for production only after a thorough security and reliability review — ideally a senior-engineer code audit — covers the areas the AI tends to get wrong.

What are the most common security issues in vibe-coded apps?

The recurring ones are: hardcoded credentials and exposed API keys, broken authentication (sessions without expiry, missing authorization checks), missing input validation that allows injection, no rate limiting on sensitive endpoints, swallowed errors around payments and webhooks, and unsafe AI features such as prompt injection and unbounded token spend. A focused review of these areas catches the large majority of real problems.

Can I just ask the AI to review its own code?

Asking the AI to explain and critique its own code is a useful first pass and will surface some obvious issues, but it is not a substitute for human review. The same model that introduced a vulnerability will often miss it on review, and it has no real accountability for your production system. Use AI self-review to speed things up, then have a human verify the security-critical paths.

When should I get a professional code review or audit?

Bring in a professional review before you handle real customer data, take payments, launch publicly, or fundraise. If your vibe-coded app has logins, billing, or AI-generated output going to real users, a senior-engineer audit of security, reliability and architecture is one of the highest-leverage investments you can make. Finding a broken Stripe webhook or an exposed API key before your first paying customers is always cheaper than finding it after.

Can I just use CodeRabbit, Greptile or another automated tool?

Use them — they're good at what they do and they'll catch a real class of issues on every commit during development. What they can't do is catch the bugs that matter most in AI-generated code: missing logic the model never wrote, functions that are only 'correct' against their own test cases, and architectural inconsistencies where two parts of the app do the same thing differently. Those need a human. The right order is to run a human review of the high-risk paths first and the automated tools last.

How long should reviewing a vibe-coded app take?

A small MVP under a few thousand lines can be reviewed in a day. A mid-sized SaaS app typically takes 3–7 business days for a thorough pass. Larger codebases are best handled in tiers: a surface scan across everything first, then a deep dive on the highest-risk modules — auth, payments, data access and any AI features.

How is this different from a normal code review?

A normal code review assumes a human wrote the code with intent and understands the surrounding system. Reviewing vibe-coded code means accounting for AI failure patterns — hallucinated logic, duplicated files, confidently wrong security code and inconsistent conventions — and often reviewing without the original author's mental model. That's why it pays to start from the prompt, review in small diffs, and weight your attention toward the areas AI tools reliably get wrong.

VibeAudits

Guide

How to Review Vibe-Coded Apps

Vibe coding lets you ship a working app in a weekend. Reviewing it properly is what stops that app from leaking data, dropping payments or falling over in front of your first real customers. This is a practical, step-by-step guide to reviewing code built with Cursor, Claude, Copilot, Lovable and Replit — and knowing when to bring in a professional audit.

What is vibe coding?

Vibe coding is a style of building software where you describe what you want in plain English and an AI tool writes most of the code. The term was popularised by Andrej Karpathy in early 2025, and it has since become the default way a huge number of founders, indie hackers and non-engineers ship their first product.

Tools like Cursor, Claude, GitHub Copilot, Lovable and Replit make it genuinely possible to go from idea to working demo in hours. The catch is that you end up shipping a lot of code you didn't write and don't fully understand. The app looks finished — logins work, the buttons do things, payments go through in testing — but the parts that matter most for real users are often the parts the AI quietly got wrong.

That gap between "works in the demo" and "safe for real customers" is exactly what a code review closes. The rest of this guide walks through how to do that review.

Why vibe-coded apps need a real review

AI assistants optimise for code that runs, not code that's safe. These are the issues that show up again and again in shipped vibe-coded apps — none of which are visible in a working demo.

Exposed secrets & API keys

Hardcoded credentials, keys committed to git, or sensitive config leaking into client-side bundles — the most frequent finding in vibe-coded repos.

Broken auth & access control

Sessions without expiry, missing authorization checks, and IDs in URLs that let one user read another user's data.

Unvalidated input

Raw user input piped straight into queries, paths or commands, leading to injection bugs and corrupted data.

Missing rate limiting

Endpoints with no throttling that can be hammered, run up costs, or be brute-forced on login and payment flows.

Silent error handling

Failures that are swallowed instead of handled — broken webhooks, half-completed payments and jobs that quietly die.

Unsafe AI features

Prompt injection, data leakage, unbounded token spend and tool calls that execute actions without guardrails.

Why automated tools miss the bugs that matter

Scanners like CodeRabbit, Greptile and Graphite are genuinely useful — they catch a real class of bugs on every commit. But they can only see the code that exists. The failures that sink vibe-coded apps come from the model optimising for "does it run" instead of "is it correct and consistent," and those are exactly the things a tool can't flag.

Missing logic

A scanner can't flag a permissions check that was never written. It sees code that exists; vibe-coded apps fail on the code that doesn't.

Wrong assumptions

A function that returns the right answer for the test cases and the wrong one for an unexpected input. It's 'correct' against itself, so nothing complains.

Architectural mismatch

Auth wired up one way in 80% of the codebase and a different way in the rest. Both run; only one is right. A human asks why — a scanner reports both pass.

The takeaway isn't "don't use scanners." It's run them last, after a human has read the high-risk paths. They catch the easy stuff after you've found the hard stuff.

How to review a vibe-coded app, step by step

Work through these in order. The first few catch the highest-risk problems fastest, so even a short review pays off. Weight your attention toward the areas AI tools reliably get wrong rather than reading every line equally.

1. Start with the prompt and the diff, not the code

AI tools generate code from a prompt and a context window, so the fastest way to review vibe-coded code is to read the original prompt next to the change. Ask: did the model actually build what was requested, or did it quietly invent extra behaviour? Review in small, reviewable diffs rather than 2,000-line dumps. If you can't tell what a change does from reading it, paste it back into the chat and ask the AI to 'explain this in plain English and list what could go wrong.'

2. Hunt for secrets, keys and exposed credentials

The single most common issue in shipped vibe-coded apps is hardcoded secrets: API keys, database URLs, Stripe keys and tokens committed straight into the repo or shipped to the browser. Grep the codebase for keys, check that secrets live in environment variables, confirm nothing sensitive is bundled into client-side code, and rotate anything that was ever committed to git history.

3. Pressure-test authentication and authorization

AI assistants are good at making login look like it works and bad at making it actually safe. Check session handling and cookie expiry, password reset and invite flows, and — most importantly — authorization: can user A load user B's data by changing an ID in the URL? Verify that every protected route and API endpoint checks who the caller is and what they're allowed to do, including multi-tenant boundaries.

4. Trace user input all the way to the database

Follow a piece of user input from the form to where it lands. Vibe-coded code frequently pipes raw input straight into database queries, file paths or shell commands, opening up SQL injection and similar holes. Confirm queries are parameterized, input is validated and sanitized, file uploads are constrained, and that there's rate limiting on anything that touches auth, payments or AI calls.

5. Break the happy path on purpose

Demos only ever test the golden path. Review error handling, retries and timeouts around every external call — payment webhooks, third-party APIs and LLM requests. Test billing edge cases (trial expiry, failed payments, downgrades), submit empty and malformed inputs, and check what the app does when an API is slow or returns garbage. This is where vibe-coded apps quietly fall over in front of real users.

6. Review the AI-specific surface area

If the app uses LLMs, RAG or agents, review the prompts and tool calls as carefully as the code. Look for prompt injection paths where user input reaches a system prompt, data leakage through context, unbounded token spend, and tools that can execute unsafe actions. Add guardrails, output validation and spend limits before this hits production traffic.

7. Read for maintainability and dead code

AI tools love to duplicate files, leave half-finished functions and re-implement things that already exist. Scan for orphaned files, copy-pasted logic, inconsistent patterns and TODOs that became permanent. A quick maintainability pass keeps future changes (yours or the AI's) from re-breaking the same areas over and over.

Checklist

The vibe-coding code review checklist

Copy this and run through it before you launch, take payments, or hand the app to real users.

No secrets, keys or tokens in the repo, git history, or client bundle
Every protected route and API checks authentication and authorization
User input is validated and queries are parameterized end to end
Rate limiting on auth, payment and AI endpoints
Error handling, retries and timeouts around all external calls
Payment and subscription edge cases tested (trials, failures, downgrades)
Webhooks verify signatures and are idempotent
AI prompts, RAG and tools have guardrails and spend limits
Core flows tested: sign-up, login, password reset, checkout, mobile layout
No duplicated files, dead code or half-finished functions left behind

Self-review, AI review, or a professional audit?

Each has a place. The trick is knowing which one your app actually needs right now.

Self-review

Reading your own diffs and running the checklist above. Free, fast, and worth doing on every change — but limited by what you don't yet know to look for.

Best for: early prototypes and learning.

AI self-review

Asking the AI to explain and critique its own code. A useful accelerant that catches obvious issues — but the model that wrote the bug often misses it, and it owns none of the risk.

Best for: a quick first pass before human eyes.

Professional audit

A senior engineer reads the code like an attacker and a future maintainer, covering security, reliability, performance and architecture across the whole app.

Best for: before launch, payments, or fundraising.

Code review vs. code audit: what's the difference?

The terms get used interchangeably, but they describe different scopes — and vibe-coded apps usually need both.

Code review

A continuous practice during development. Every change gets a second pair of eyes and issues get caught at the point they're introduced. The problem with vibe coding is that the "second pair of eyes" often never exists — the only author is the AI tool.

Code audit

A one-time deep dive that reads the entire codebase as a finished artifact. It catches the issues that survived ongoing review — or, for most vibe-coded apps, the issues that ongoing review never existed to catch. The audit is often the first human review the code has ever had, which is why the findings can be substantial.

FAQ

Reviewing Vibe-Coded Apps: Frequently Asked Questions

The questions founders and indie hackers ask us about vibe coding, AI-generated code and getting an app review-ready.

Want a senior engineer to review your vibe-coded app?

We specialise in exactly this: taking apps built with Cursor, Claude, Copilot, Lovable and Replit and turning them into something you can safely charge money for. You get a prioritised, founder-friendly report covering everything in this guide — and the option to have us help ship the fixes.