Is vibe coding bad? Where it works, where it breaks
Is vibe coding bad? Not inherently. Vibe coding – describing what you want to an AI tool and accepting the code without really reading it – is excellent for prototypes, internal tools and validating ideas. It becomes bad when unreviewed code starts handling authentication, money, multi-tenant data or anything an attacker would want.
I use AI coding tools on my own products, and I take on cleanup of vibe-coded apps that have reached paying customers. This guide is the balanced version: what vibe coding is good for, the specific ways it fails, how it differs from agentic coding with review, and a checklist to run before real users arrive.
What vibe coding actually means
Andrej Karpathy coined the term in early 2025 to describe a way of working where you “give in to the vibes” and forget the code exists: you prompt, run the result, paste errors back in, and keep going until it works. The defining trait isn’t the tool. It’s that nobody reads or understands the code.
That distinction matters, because the same tools – Cursor, Claude Code, Lovable, Bolt, Replit – can be used in a completely different way, where an engineer specifies the change, reviews the diff and owns the merge. Calling both “vibe coding” muddles the debate. One is a prototyping style. The other is just software engineering with a faster keyboard.
Where vibe coding is genuinely great
- Validating an idea. A clickable, working product in a weekend beats a pitch deck. If nobody wants it, you’ve lost a weekend, not a quarter.
- Prototypes that will be thrown away. Exploring a UI, testing a workflow with five users, showing investors something real.
- Internal tools with a small blast radius. An admin dashboard over read-only data, a script that tidies a spreadsheet, a one-off migration helper you’ll run once and delete.
- Non-engineers building for themselves. Founders, PMs and designers making things that would never have been prioritized otherwise.
- Getting to first revenue. Plenty of founders have used AI builders to reach paying customers before they could afford an engineer. That’s a real achievement, not a mistake.
The common thread: the cost of the code being wrong is low, or the code has a short life.
Where vibe coding breaks
The failures aren’t random. AI tools optimize for “it works when I click through it”, and the parts of software that fail are the ones you can’t see by clicking through:
- Authorization. The UI hides the admin button, but the API endpoint behind it doesn’t check the role. Or row-level security in Supabase is missing on a table, so any user can read everyone’s rows with the public publishable key (the anon key on older projects).
- Data integrity. No foreign keys or unique constraints, no transactions around multi-step writes, schema changes made by hand in a dashboard with no migration history. Data corrupts slowly and silently.
- Multi-tenancy. Every query has to filter by tenant. Miss one, and customer A sees customer B’s invoices. Generated code misses one surprisingly often. See multi-tenant SaaS architecture.
- Payments. Webhooks without signature checks, no idempotency so a retried event charges or credits twice, subscription state stored only on the client. This is where bugs turn directly into money.
- Secrets. API keys bundled into frontend code, committed to the repo, or shared between environments.
- Maintainability. The tool solves each prompt locally, so the same logic gets reimplemented five times in five styles. After a few months, every fix breaks something else, and the AI spends most of its effort repairing its own regressions.
- Performance. N+1 queries, missing indexes and unbounded list endpoints that are fine with ten users and fall over at ten thousand.
Vibe coding security: the specific risks
Vibe coding security problems deserve their own section, because they’re the ones that end companies. Security researchers in 2025 found many apps generated by AI builders exposing user data through missing or misconfigured Supabase row-level security policies. The pattern is easy to repeat: the frontend talks directly to the database with a key that’s public by design, and the only protection is policies the builder may or may not have written correctly.
Other recurring issues: injection through string-built SQL or shell commands; missing rate limits on login and on AI endpoints that cost money per call; trusting prices and user IDs sent from the browser; verbose error messages leaking stack traces; and hallucinated or typo-squatted package names pulled into the dependency tree. None of these show up in a demo. All of them show up in a security questionnaire from your first enterprise customer.
Vibe coding vs agentic coding
Agentic coding uses the same models, often in the same tools, but with a different contract. The agent plans a change, edits several files, runs the tests and iterates on failures. The human writes the spec, constrains the scope, reads the diff and decides whether it merges. The difference between vibe coding vs agentic coding is accountability and feedback loops, not capability.
- Specification: vibe coding prompts for an outcome; agentic coding gives the agent a written task with acceptance criteria and constraints.
- Feedback: vibe coding relies on “does it look right?”; agentic coding relies on tests, type checks and linters the agent must pass.
- Review: vibe coding has none; agentic coding has a human reviewing every diff, often with an AI reviewer as a first pass. See AI code review.
- Context: vibe coding starts fresh each session; agentic coding uses conventions files that describe the architecture, commands and rules of the codebase.
- Ownership: with vibe coding, nobody understands the code; with agentic coding, a named engineer can explain every merged change.
Teams that get real speed from AI are doing the second thing. The guide to rolling out AI coding assistants covers how to set that up across an engineering team.
Is vibe coding the future?
Partly. The share of code written by models will keep rising, and the floor for who can build working software has dropped permanently. That’s good. But the bottleneck moves rather than disappears: from typing code to specifying it precisely, verifying it and owning the consequences. Someone still has to know whether the tenant filter is right.
My bet is that “vibe coding” survives as the name for the prototyping phase, and production software converges on agentic coding with strong tests, clear specs and human review. The skill that gets more valuable is judgement – knowing which parts of a system can be vibed and which must be designed.
Checklist before real users
If your vibe-coded app is about to take signups, payments or personal data, run through this first:
- Code in your own repository, with version history, not only inside the AI builder.
- Every secret server-side and rotated if it was ever in frontend code or a commit. Scan the repo history.
- Row-level security or equivalent on every table, with policies tested by logging in as two different users and trying to read each other’s data.
- Authorization enforced on the server for every endpoint and database function, not just hidden in the UI.
- Server-side validation of every input, including prices, quantities, IDs and roles.
- Payment webhooks verified and idempotent. Replaying the same event twice changes nothing.
- Database changes as migration files, with staging and production separated.
- Automated tests for the money paths – signup, login, checkout, the core feature – running in CI on every change.
- Rate limits on auth endpoints and anything that costs you per request.
- Error monitoring and backups, and one backup you have actually restored.
- A dependency check: every package exists, is the one you meant, and is maintained.
- Someone who can read the code has read the critical parts: auth, data access and payments.
What to do if you’re already past that point
If you have paying users and some of that checklist is unticked, don’t panic and don’t rewrite. Close the security gaps first – secrets, access rules, server-side checks – which is usually days of work, not months. Then add tests around the flows that earn money, and decide module by module what to keep. Most of a working vibe-coded app is worth keeping.
That’s the work I do in vibe coding cleanup: an audit and the urgent fixes inside a two-week sprint, then a keep-or-rewrite plan per part of the app. If you’d rather have someone independent assess it first, a code audit is the lighter-weight option.
Questions
Is vibe coding bad for beginners?
It’s a great way to build something quickly, and a poor way to learn how software works if you never read the output. Beginners get the most from it by asking the tool to explain each change, reading the diffs, and writing small parts themselves.
Is vibe coding safe for production apps?
Not without review. Vibe-coded apps can run in production safely once someone has checked authorization, secrets, input validation, data integrity and payments, and added tests and monitoring. The risk is in skipping those steps, not in how the code was first written.
What is the difference between vibe coding and agentic coding?
Vibe coding accepts AI-generated code without reading it. Agentic coding has an AI agent plan, edit and test changes, but a human writes the spec, reviews every diff and owns the merge. Same tools, different accountability.
Is vibe coding the future of software development?
For prototypes and personal tools, largely yes. For production systems, the trend is toward AI agents working under specs, tests and human review. The work shifts from writing code to specifying and verifying it.
What are the biggest vibe coding security risks?
Missing or broken database access rules such as Supabase row-level security, secret keys exposed in frontend code, authorization enforced only in the UI, unvalidated client input, unverified payment webhooks and missing rate limits.
Vibe-coded app with real users on it?
I’ll audit it, close the urgent security gaps and give you a keep-or-rewrite plan, all inside a two-week sprint. No lectures about how it was built.
GMT+2 · Full EU overlap · US East mornings