Vibe coding gets you from idea to working app faster than anything before it. You describe what you want, the AI generates the code, you review it, and within hours you have something that runs. For an MVP, that speed is genuinely valuable. Getting something in front of users quickly is how you learn whether the thing is worth building at all.
But fast does not mean correct, and the same handful of mistakes shows up in almost every vibe-coded MVP. They are not random. They are predictable consequences of how AI code generation works and how developers interact with it. Understanding the pattern makes them easy to spot before they become incidents.
This post names the mistakes so you can look for them in your own repo. The goal is not to slow you down. It is to close the gap between "this works on my machine" and "this works for real users in production."
Why These Mistakes Are So Common
The AI optimizes for code that looks like it works. It has been trained on examples of working code, so it produces patterns that are syntactically correct, follow common conventions, and pass the happy path. What it is not optimizing for is production correctness: failure modes, edge cases, security boundaries, and the behavior of the system under load or adversarial input.
When you are writing code line by line, you are thinking through each decision. When you are reviewing AI output, you are evaluating the result. That is a fundamentally different mode, and it has a specific failure: you approve something that compiles and runs without fully thinking through whether it is correct in every case. The happy path runs in your test. The error path, the unauthorized request, the missing index on a growing table: those do not show up until later.
You tested the happy path because that is the path the AI showed you. The mistakes live in the paths it did not show you.
The Mistakes
No Environment Separation
In a vibe-coded MVP, it is common to stand up one database, one set of API keys, and one config, then use that same setup throughout development and testing. The AI does not know you have real users. It generates connection strings, environment variables, and config values without distinguishing between dev and prod contexts, because you did not tell it to.
The result is that your local dev environment and your production environment point at the same database. A test action you run on your laptop affects real users and real data. A seed script you run to populate test records wipes or corrupts production rows. The problem is invisible until it is not.
- Check that
DATABASE_URL, API keys, and any service credentials are different between your dev and prod environments. - Confirm that your
.env.localand.env.productionfiles point to separate resources. - Look for any scripts that modify data and make sure they can never run against the production database by accident.
Secrets Committed to the Repo
This is the most common and most immediately dangerous mistake in AI-built codebases. When you are iterating quickly with an AI, you paste API keys into prompts, the AI includes them in generated code, and they end up in a commit. Or you configure a connection string in a config file and commit the file without noticing it contains real credentials. The AI has no concept of what is sensitive. It uses whatever values you give it.
What makes this serious is that git history is permanent. Even if you remove the key from the current file, the value is still in the commit history and is accessible to anyone with repo access. If the repo is public, automated scanners find it within minutes.
- Run
git log -p | grep -iE "api_key|secret|password|token|sk_live|AKIA|ghp_"and scan the output for real values. - Check that
.env,.env.local, and similar files are in.gitignoreand have never been committed. - Rotate any key that has ever touched a commit, regardless of whether you think the repo is private.
No Error Handling Beyond the Happy Path
AI-generated code handles the case where everything works. The database returns rows, the API call succeeds, the user input is valid. Error handling is frequently absent or cosmetic: a try/catch that catches the exception and does nothing with it, or a .catch() that logs to the console and returns silently. From the outside, the feature appears to work. In production, failures become invisible, and users get a broken experience with no way for you to know it happened.
- Search for
catchblocks that are empty or only callconsole.log. These swallow errors silently. - Check async functions for missing try/catch entirely. An unhandled promise rejection in Node.js will produce a 500 with no useful response.
- Confirm that every data-fetching component in the UI has an error state that renders something meaningful, not a blank screen.
- Make sure errors are logged server-side with enough context to diagnose them later.
Auth Checks That Look Right but Are Not
This is the subtlest mistake and the one with the most serious consequences. The AI generates frontend code that hides a button or a route from unauthorized users, and it generates backend code that handles the request if it arrives. What it often does not generate is the check on the backend route that actually verifies the requesting user has permission to perform the action.
The frontend protection is cosmetic. It prevents a normal user from clicking a button they should not see. It does nothing to prevent someone from calling the API endpoint directly with a tool like curl or Postman. If the backend route does not check authorization, the protection is completely bypassed.
- Test every protected API route directly, without a session cookie or auth token. It should return 401 or 403, not data.
- For any route that accepts a resource ID, confirm the backend verifies the requesting user owns that resource, not just that they are authenticated.
- Admin routes need to check for admin privileges, not just authentication. Being logged in is not the same as being authorized.
Database Queries With No Limits or Indexes
In development, your database has a handful of rows. Queries return instantly. The AI generates a query that fetches all records matching a condition, with no limit, because in development that query returns three rows and there is no reason to think about it further.
In production, that same query runs against 50,000 rows, returns all of them into memory, and either crashes the server or takes long enough that the request times out. Missing indexes have the same effect: a query that is instant on a small table becomes a full table scan on a large one.
- Look for any query that fetches a list of records without a
LIMITclause or equivalent. Paginate or cap every list query. - Check that columns used in
WHEREclauses on tables that will grow have indexes defined. - Foreign key columns and columns used for sorting or filtering are the most common ones to be missing indexes.
Dependency Bloat
When you ask an AI to implement a feature, it will often suggest a package that handles the use case. That is usually fine. But across twenty features, you accumulate twenty packages, some of which solve problems you already had a solution for, some of which were used once and never removed, and some of which pull in large transitive dependency trees. The package.json grows without anyone reviewing it holistically.
Every package you ship is an attack surface. A compromised or malicious package in your dependency tree can exfiltrate data, inject code, or open a backdoor. Packages you installed experimentally and forgot about are still in your production build.
- Go through
package.jsonand ask, for each package, whether it is actually used in production code. Remove anything that is not. - Run
npm auditoryarn auditand resolve high and critical severity findings before launch. - Look for duplicate functionality: two packages that both do date formatting, two HTTP clients, two UI component libraries. Pick one and remove the other.
How to Catch These Without Rebuilding Everything
None of these require a rewrite. They require a focused review pass before you ship. The most effective approach is to read the diff line by line before merging, not trusting the result because it ran. Running is necessary but not sufficient. Code that runs correctly on the happy path can still have all six of the issues above.
A structured self-audit is faster than a full review of every file. Start with the highest-risk areas: auth routes, database queries on large tables, any code that touches external services or credentials. The pre-launch audit checklist covers the mechanical steps in detail. The checklist turns the audit into something repeatable instead of something you reconstruct from memory each time.
The other practical approach is to slow down at merge time. When a PR is ready, do not merge it because it passed CI. Read what the AI actually generated. Look for the patterns above. The overhead is small, and the alternative is discovering the problem after users are affected.
What Happens If You Skip This
These are not theoretical risks. They are the specific things that go wrong in production for vibe-coded MVPs, and they happen on a predictable timeline.
A shared dev/prod database means the first time someone runs a seed script or a destructive test locally, it runs against real user data. Depending on what the script does, that is anywhere from a minor data inconsistency to a complete loss of production records with no backup.
An unprotected route gets found within days of launch. Bots continuously probe common endpoint patterns: /api/admin, /api/users, /api/export. If those routes return data without checking authorization, that data is accessible to anyone who discovers the URL. You will not know it is happening.
An API key in a public repo gets scraped in minutes. This is automated. Services monitor GitHub for newly committed credentials. The key gets used before most people would notice it was there, and the first indication is usually a billing alert or a service suspension.
The AI Is Not the Problem
Vibe coding is not the issue. The speed is real, the productivity gains are real, and the ability to get something working without deep expertise in every layer of the stack is genuinely valuable. The problem is unreviewed AI output. Code that no one read critically before it shipped.
The AI generates code that looks like production code. It follows patterns, uses the right libraries, and handles the case you described. It does not know your security requirements, your data sensitivity, or the behavior of your system at scale. That context has to come from you, in the form of a review pass before you merge.
If you want to automate the mechanical parts of that review, GitDoctor can scan your repository for the patterns above: exposed secrets, missing auth checks, dependency vulnerabilities, and more. Each finding comes with context and a suggested fix. It is not a replacement for reading your code, but it catches the things that are easy to miss when you are moving fast. The first scan is free.