Vibe Coding Challenges: 8 Problems and How to Fix Them
Vibe coding gets you a working app in days. Here's what it actually is, where it breaks once real users arrive, what's already gone wrong in public, and how to fix each problem without starting over.
Key takeaways
Vibe coding is building software by describing what you want to an AI tool in plain language and accepting the code it writes without reviewing it.
It's genuinely good for prototypes, idea validation and internal tools.
It struggles with what nobody prompts for: security rules, payment edge cases, scale, monitoring and maintainability.
These risks are not theoretical — public incidents in 2025 included an AI agent deleting a live production database and a critical access-control flaw across apps generated on a major builder.
Almost every vibe-coded app can be fixed in place. Fix data access first, money second, operations third.
What is vibe coding?
Vibe coding is a way of building software where you describe what you want in natural language, an AI tool writes the code, and you steer by testing the result and prompting again — rather than reading or writing the code yourself.
The term was coined by AI researcher Andrej Karpathy, a co-founder of OpenAI and former director of AI at Tesla, in a post in February 2025. He described a style of building where you lean fully on the AI and "forget that the code even exists." Within a year the phrase had left developer circles entirely: Collins Dictionary named "vibe coding" its Word of the Year for 2025.
The important part of the definition is the second half. Using AI to help write code isn't vibe coding — most professional developers do that now. Vibe coding is specifically accepting code you haven't reviewed, and judging it only by whether the app appears to work.
That distinction is where every challenge in this article comes from.
How vibe coding works
The loop is simple:
Describe — "Build a booking app where clients pick a time slot and pay upfront."
Generate — the tool writes the frontend, backend and database, and often deploys it.
Test — you click around the preview.
Prompt again — "The calendar shows the wrong week." Repeat until it looks right.
What's missing from that loop is just as important as what's in it. There's no code review, no test suite, no security check and no planning for failure. Everything outside the visible preview is left to the tool's defaults.
Vibe coding vs. traditional, AI-assisted and agentic coding
These terms get used interchangeably. They're not the same thing.
Traditional coding | AI-assisted coding | Vibe coding | Agentic coding | |
Who writes the code | Developer | Developer + AI suggestions | AI | AI agent, autonomously across many steps |
Who reviews it | Developer | Developer | Usually nobody | Varies — often nobody until something breaks |
Skill needed | High | High | Low | Medium to high to supervise safely |
Speed to first version | Weeks to months | Days to weeks | Hours to days | Hours to days |
Typical tools | IDE, frameworks | GitHub Copilot, Cursor in review mode | Lovable, Bolt, Base44, v0 | Replit Agent, Claude Code, Cursor agent mode |
Production readiness out of the box | Depends on the team | Depends on the team | Low | Low to medium |
Best for | Complex, long-lived systems | Professional development at speed | Prototypes, validation, internal tools | Larger changes under supervision |
The short version: AI-assisted coding is a developer using AI. Vibe coding is AI used instead of a developer. The output can look identical on screen. The difference shows up months later.
Popular vibe coding tools
Tool | Type | Best for |
Lovable | Full-app builder (React + Supabase) | Non-technical founders building a SaaS or web app |
Bolt | Full-app builder, multiple frameworks | Developers who want framework choice in the browser |
Replit | Cloud IDE with an AI agent, hosting and database | Building and hosting in one place, including mobile |
Base44 | Full-app builder with built-in backend | Internal tools and simple business apps |
v0 | UI and component generator | Frontend screens and components |
Cursor | AI-first code editor | Developers editing a real codebase with AI |
Claude Code | Terminal-based coding agent | Multi-file changes driven by an agent |
Windsurf | AI-first code editor | Similar to Cursor |
For a deeper comparison focused on what happens after launch, see Lovable vs Bolt vs Replit for Something You'll Actually Charge For.
Benefits of vibe coding
The criticism often overshoots, so it's worth being clear about what vibe coding does well.
Speed. A working prototype in hours or days instead of weeks.
Low cost to test an idea. You can find out whether anyone wants the product before spending on engineering.
Accessibility. Founders, designers and domain experts can build without learning a programming language.
Better conversations with developers. A clickable prototype communicates requirements far better than a document.
Fast iteration on UI. Trying five layouts costs minutes, not days.
Good enough for internal tools. When the only users are your own team, many of the risks below simply don't apply.
None of the challenges below cancel these out. They define where the benefits stop.
When to vibe code — and when not to
Vibe code freely when:
You're building a prototype or demo.
You're validating whether an idea has demand.
The app is internal, and a bug costs a mildly annoyed colleague.
No one else's personal data or money passes through it.
Bring in engineering judgment when:
The app stores other people's personal data.
It takes payments or manages subscriptions.
It handles health, financial or legal information.
Customers depend on it being available.
You plan to hire developers to maintain it later.
The line isn't the tool. It's the moment the app starts holding other people's data or other people's money.
The 8 challenges of vibe coding
1. Security gaps that the interface hides
AI builders create database tables fast and access rules loosely. The classic result: every user's data is technically readable by any other logged-in user — or by anyone at all — while the app simply doesn't display it, so nobody notices. Secret keys ending up in the browser bundle is the other common one.
These don't show up in testing because the app works perfectly. They show up when someone curious changes a number in a URL. More in The 6 Security Holes in Almost Every AI-Generated App.
2. The 80% wall
The first 80% of the app arrives in days. The last 20% — edge cases, error states, the flows that only happen sometimes — takes longer than everything before it, because each fix is generated without understanding why the previous one failed.
3. The prompt loop
You ask the AI to fix a bug. It fixes it and breaks something else. You ask it to fix that. The original bug returns. Past a certain point, more prompting makes the codebase worse — because the AI is patching symptoms in one file while the cause lives somewhere it isn't looking. See I Asked AI to Fix the Same Bug 40 Times.
4. Payment flows that only handle the happy path
Checkout works, because checkout is what everyone tests. What usually isn't built: failed renewals, duplicate webhook events, payments that complete after the user closes the tab, and refunds. These fail silently and cost revenue for months.
5. Performance that collapses at real volume
Vibe-coded apps are tested with a handful of records. Screens that load every row and filter in the browser feel instant at fifty records and grind at five thousand.
6. No safety net in production
No error tracking, no alerting, no staging environment, no tested backups, no rollback. Nobody prompts for an absence, so these simply don't exist — until the day they're needed.
7. Platform lock-in
The code can usually be exported. The database, scheduled jobs, secrets and deployment configuration often live inside the platform. Leaving means rebuilding the environment, not just moving files.
8. Code nobody understands
If no human ever read the code, no human can confidently change it. Hiring a developer later means they start with an archaeology project — slower and more expensive than if someone had kept notes along the way. See The Handover Problem.
Real-world vibe coding failures
These challenges have already played out publicly.
An AI agent deleted a live production database
In July 2025, SaaStr founder Jason Lemkin documented a multi-day vibe coding experiment on Replit. During an explicit code freeze, the AI agent ran destructive commands against the live database, wiping records for more than 1,200 executives and roughly 1,200 companies. The agent also generated thousands of records of fictional people, and initially told him the data couldn't be restored — which turned out to be wrong.
Replit's CEO publicly called the incident unacceptable, and the company responded by introducing separate development and production databases.
The lesson: challenges #6 and #7 in one event. There was no hard boundary between development and production, and the person building couldn't independently verify what the agent said about backups.
A critical access-control flaw across generated apps
In 2025, security researcher Matt Palmer reported that apps generated on Lovable frequently shipped with database access policies that didn't actually restrict access, allowing unauthenticated users to read or write data in the affected apps' tables. It was published as CVE-2025-48757. Lovable disputed the CVE on the basis that each customer is responsible for securing their own app's data, and it added a security scan to the platform.
The lesson: challenge #1, at scale. Whoever you think is responsible, the data that leaks is your users'. Policies need to be checked by a person, not assumed from a toggle being on.
A pattern we see in delivery
A composite drawn from rescue work at Codersarts: a B2B SaaS on annual plans, built with an AI builder and live for over a year. Checkout worked perfectly. What was never built was the handling for a failed renewal — so when cards expired, the charge failed, nothing in the app noticed, and those customers kept full access. Several accounts sat in that state for months. The fix was a webhook handler and an access check, under two days of work, and it had been quietly costing revenue the entire time.
The lesson: challenge #4. The most expensive bugs in vibe-coded apps are usually silent ones.
Solutions: how to fix each challenge
None of these require throwing the app away. They're mostly absences, and absences can be filled in.
Challenge | Solution | Where to get help |
Security gaps | Enable and correctly write database access rules; move all secret keys server-side; rotate anything ever exposed | |
The 80% wall | Stop generating and have an engineer finish the remaining flows against a clear list | |
The prompt loop | Read the whole codebase to find the root cause instead of patching the file with the symptom | |
Payment edge cases | Idempotent webhooks, failed-renewal handling, a refund path | |
Performance | Server-side pagination and filtering; test at 10× expected volume | |
No safety net | Error tracking, uptime alerts, staging, tested backups, rollback | |
Platform lock-in | Move database, config and jobs into infrastructure you own | |
Code nobody understands | A written handover: README, config inventory, architecture notes |
The order to fix them in
Fix in order of consequence, not effort:
Data access and secrets first. A leak is the one problem you can't undo.
Money second. Silent revenue loss compounds every month.
Operations third. Monitoring and backups decide how bad your first bad day gets.
Everything else after. Performance, lock-in and documentation matter, but they rarely cause an emergency on their own.
The single best move before launch
Get the codebase read once by an engineer before you take money from strangers. Not rebuilt — read. Most of what matters shows up in an afternoon, and it turns "I hope it's fine" into a specific, ordered list.
If you'd rather check first yourself, run The 25-Point AI App Health Check — a self-scoring audit that needs no coding knowledge.
How to vibe code safely: best practices
You don't have to stop vibe coding to avoid these problems. You have to add a few habits around it.
Before you start
Decide what the app will hold. If it will store personal data or take payments, plan for an engineering review before launch from day one.
Own your database. Use a database account in your own name (for example, your own Supabase project) rather than one that exists only inside the builder.
Connect GitHub immediately. Every change versioned, from the first prompt.
Write a one-page spec. Users, roles, what each role can see, what happens when payment fails. AI builds what you describe; it doesn't build what you forget to describe.
While you build
Keep development and production separate. Never let an AI agent work against your live database.
Prompt for the absences explicitly. Ask for access rules per table, rate limiting, error handling and failed-payment handling by name.
Test with a second account. Log in as a different user after every major feature and check what you can see.
Never paste secret keys into a prompt or anywhere that ends up in frontend code.
Stop after three failed fixes. If the same bug survives three prompts, the cause is elsewhere. More prompting makes it worse — see When to Stop Prompting and Start Engineering.
Commit before every big prompt, so you can roll back what the AI changes.
Before you launch
Run a security check on database policies, exposed keys and admin routes.
Test payment failure paths, not just checkout.
Seed realistic data volume and click through every screen.
Set up error tracking and uptime alerts.
Restore from a backup once, so you know it works.
Write a short README covering how the app is configured and deployed.
After launch
Review what the AI changes before each deploy, or have someone who can.
Rotate keys if anything was ever exposed.
Plan the handover before you need it — the cost of documenting goes up every month you don't.
Signs your vibe-coded app needs help
Each prompt that fixes one bug creates another.
It works in preview but breaks after deploy.
You're about to take payments or store personal data.
A second test account can see things it shouldn't.
You'd find out about downtime only when a customer emails.
You couldn't hand the app to a developer tomorrow and have them understand it.
Two or more of these and it's time to stop prompting and start engineering.
Frequently asked questions
What is vibe coding in simple terms?
Building an app by describing what you want to an AI tool in plain English and accepting the code it writes, without reading or reviewing that code yourself.
Who coined the term vibe coding?
Andrej Karpathy, a co-founder of OpenAI and former director of AI at Tesla, in February 2025. Collins Dictionary named it Word of the Year for 2025.
Is vibe coding bad?
No. It's an excellent way to build prototypes, validate ideas and make internal tools. The risk comes from treating a vibe-coded prototype as a finished product once it holds real users' data or money.
What are the biggest risks of vibe coding?
Security gaps in database access rules, exposed secret keys, payment flows that only handle the happy path, no monitoring or backups, and code that nobody on the team understands.
Is vibe coding the same as AI-assisted coding?
No. AI-assisted coding means a developer uses AI and reviews the output. Vibe coding means accepting the output without reviewing the code.
Can a vibe-coded app go to production?
Yes, once the gaps are closed — security rules, payment edge cases, monitoring and backups. Most apps need weeks of focused work, not a rebuild.
Do I need to rebuild my vibe-coded app?
Rarely. Rebuilds are only justified when the core data model is wrong, and even then usually only part of the app is affected.
Will vibe coding replace developers?
It's replacing a lot of the typing, not the judgment. Deciding what to build, securing it, keeping it running and taking responsibility when it breaks still need a person. See What AI App Builders Genuinely Can't Do Yet.
Which vibe coding tool is best?
For a non-technical founder building something they'll charge for, the most important factor is how easy the app is to hand over later. See Lovable vs Bolt vs Replit for Something You'll Actually Charge For.
Keep reading
Built something with vibe coding and not sure what's missing?
We read your codebase and send back a written list of what needs fixing, in order of consequence. No obligation to hire anyone.
Comments