The problem with vibe coding has nothing to do with AI

A working demo is the most dangerous artifact in software. It passes the stakeholder squint test, runs in the browser, and if it was assembled with a handful of prompts and an AI coding assistant, it even looks polished. The cost hides beneath the surface — and it only surfaces when real users arrive with concurrent writes, production traffic, and the kind of usage patterns no demo ever anticipated. The real problem with vibe coding is not the AI generating the code. It is the absence of engineering judgment reviewing, shaping, and owning what ships.

Vibe coding disguises fragility as completeness

The term was coined in early 2025 to describe a specific workflow: prompt an AI assistant, accept the output with minimal review, and repeat until the application appears to work. Within months it went mainstream — Collins Dictionary named it Word of the Year. The speed is genuine. The illusion of completeness it creates is even more so.

To a non-technical observer, a vibe-coded application looks indistinguishable from one built by a senior engineering team. It has routes, a database, a login screen, and a deployment URL. But what sits underneath often tells a different story: a database schema that collapses past a few hundred records, authentication logic with no input validation, API calls that break under concurrent traffic, and zero logging, tests, or deployment pipeline.

Perception is the hardest bug to fix. The gap between "it works on my screen" and "it works for a thousand users on a Saturday night" is where most vibe-coded projects die — quietly, expensively, and always at the worst possible moment.

Where vibe-coded systems break in production

Three failure categories account for nearly every vibe-coding postmortem: security, scalability, and maintainability. Each one compounds the others, and together they form a pattern that repeats with remarkable consistency across teams, stacks, and industries.

Security: the vulnerabilities nobody reviewed

Between 45% and 48% of AI-generated code contains security vulnerabilities — a figure that has held steady across independent audits throughout 2025 and 2026. AI co-authored code introduces security flaws at roughly 2.7 times the rate of human-written code. The patterns are predictable: hardcoded API keys shipped to the client, JWT validation skipped or misconfigured, Row-Level Security policies that look correct on the surface but grant access to every row in the table.

The risk is not theoretical. In early 2026, a vibe-coded application built on a popular AI platform exposed over 18,000 user records, including student accounts with likely minors among them. The root cause was a misconfigured RLS policy — a five-line fix that any experienced engineer would catch in review, but that nobody reviewed before deployment.

When security is treated as something the AI will handle, the AI handles it the way it handles everything else: statistically, without context, and without accountability.

Scalability: the architecture nobody designed

AI coding assistants optimize for the immediate prompt, not for the system's future. They produce code that satisfies the current request without awareness of connection limits, query planning, caching strategies, or the behavioral difference between a table with 50 rows and one with 500,000.

Database schemas generated through prompts routinely lack composite indexes, store structured data as JSON blobs in text columns, and default to configurations that exhaust connection pools under modest traffic. The application runs perfectly in the preview environment. It fails on the first real traffic spike — not with a clean error but with a cascade of 30-second timeouts that propagates across every service sharing the same database connection.

Context drift compounds the problem. Most AI assistants lose coherence on codebases past a few thousand lines. By file seven or eight, the model has forgotten the architectural decisions it made in file two. New suggestions conflict with earlier ones, and the resulting system behaves less like designed software and more like an accidental assembly of independent fragments.

Maintainability: the code nobody owns

A vibe-coded application has an unusual property: the person who shipped it did not write it, and often does not fully understand it. This creates a gap between intent and implementation that no amount of re-prompting can close after the fact.

When a bug surfaces three months later, the engineer tasked with fixing it encounters auto-generated naming conventions, inconsistent architectural patterns, and logic flows that reflect the model's training distribution rather than the domain's requirements. Debugging becomes archaeology. Every change risks a regression because the implicit assumptions in the code were never made explicit by a human who understood them.

Ownership is not a management concept — it is an engineering one. Code without an owner is code that nobody can safely change, and code that nobody can safely change is code that rots.

The velocity trap that vibe coding creates

Speed is the most seductive quality of vibe coding. A functional prototype in hours. A feature per prompt. A deployment by lunch. But the acceleration curve is deceptive — it looks exponential at the start and hits a wall somewhere around the third month.

Teams that build aggressively with vibe coding report a consistent pattern: by week twelve, the majority of sprint capacity is consumed not by new features but by regressions. Fixing one AI-generated component breaks another. The codebase has grown past the assistant's context window, so new suggestions conflict with decisions the model made in earlier files. The project hits what some practitioners call the spaghetti point — the moment where adding anything new costs more than starting over.

The initial speed was never free. It was borrowed against future engineering time, and the interest rate compounds faster than anyone expects. A feature that took thirty minutes to prompt can take a full week to debug once it interacts badly with the rest of the system. Teams that treated the first month's velocity as the baseline discover, painfully, that it was the anomaly.

AI is the tool, not the problem

Nothing here is an argument against using AI in software development. AI-assisted engineering — where a developer uses AI to accelerate work they understand, review, and own — is a genuine productivity multiplier. The distinction between this approach and vibe coding matters far more than the specific tools being used.

A developer who generates a boilerplate migration with AI, then reviews the SQL, adds the missing index, and tests the rollback path is practicing engineering with better tools. A developer who prompts "add user authentication" and deploys the result without reading it is practicing hope with a keyboard.

AI produces drafts. The quality of the final product depends entirely on the judgment applied between the draft and the deployment. That judgment requires understanding how a database behaves under load, recognizing insecure patterns in authentication logic, and knowing when a suggestion is subtly wrong — skills that develop over years of building, breaking, and repairing real systems. AI accelerates the hands. It does not replace the mind behind them.

What responsible AI-assisted development looks like

Moving from vibe coding to disciplined AI-assisted engineering does not mean abandoning AI or going back to writing every line by hand. It means restoring the engineering judgment that vibe coding skips.

• Review every suggestion before accepting it. Not a skim — a review. If you cannot explain the generated code to a colleague, you are not ready to ship it.
• Own the architecture. AI should implement your design decisions, not make them. Define the schema, the service boundaries, the error handling strategy, and the security model before the first prompt.
• Test what matters. Automated tests catch regressions before users do. A vibe-coded project without tests is a project that breaks silently and repeatedly.
• Add logging and observability from day one. If the application's behavior in production is invisible, fixing it when it misbehaves is guesswork. And it will misbehave.
• Treat security as a prerequisite, not a feature. Input validation, proper authentication, secure credential storage, and correct authorization policies are the foundation everything else depends on. They are never an enhancement to add later.

What practitioners ask about vibe coding?

The line between vibe coding and AI-assisted engineering raises practical questions that surface repeatedly in technical teams evaluating how to bring AI into their workflows.

Is vibe coding acceptable for throwaway prototypes?

For a demo that will never see real users or handle real data, vibe coding can be a useful exploration tool. The risk begins when the prototype quietly graduates to production without being rebuilt with proper engineering practices. The safest stance is to treat vibe-coded prototypes as disposable artifacts — valuable for validating ideas, never for shipping to actual users.

Can security scanners compensate for vibe-coded vulnerabilities?

Automated scanners catch known patterns: dependency vulnerabilities, common injection vectors, missing headers. They do not catch architectural flaws, misconfigured authorization policies, or business logic errors. A clean scan result on a vibe-coded application does not mean the application is secure. It means the scanner's coverage has limits the codebase has not yet exceeded.

Does vibe coding erode team ownership over time?

The erosion is gradual but measurable. When a team consistently ships code that none of its members fully understand, the collective ability to debug, refactor, and extend the system degrades month over month. Eventually the team depends on the AI tool not only for building new features but for understanding existing ones — a dependency that shatters the moment the tool's context window is exceeded or its suggestions diverge from the codebase's implicit conventions.

The case for unrestricted speed

A common argument runs the other way: speed to market is everything, and vibe coding delivers it. In competitive environments where being first matters more than being polished, shipping fast and fixing later is a rational strategy. Technical debt is an acceptable trade-off when survival depends on reaching users before the runway ends.

The argument holds — up to a point. For a solo founder validating a hypothesis with a landing page and a waitlist, the trade-off can make sense. But it breaks down the moment real user data enters the system, the moment a second engineer joins the team, or the moment the application needs to handle its 500th concurrent session. The speed that vibe coding offers in week one becomes the paralysis that blocks the team in week twelve. Survival demands shipping fast, but it also demands shipping something that still works when the users actually show up.

Key takeaways

• Vibe coding creates a perception gap: applications look complete but lack the engineering foundations that keep them running under real conditions.
• Between 45% and 48% of AI-generated code ships with security vulnerabilities, including exposed credentials, misconfigured authorization, and missing input validation.
• The initial speed advantage collapses within months as regression loops and architectural debt consume more time than new feature development.
• AI is a legitimate engineering multiplier when paired with human review, architectural ownership, and disciplined testing.
• Code without a human owner — someone who understands it and can safely change it — is code that eventually cannot be maintained at all.
• Security, scalability, and observability are prerequisites for production, not features to add after launch.

Conclusion

The conversation around vibe coding often gets framed as a debate about AI, but at its core it is a debate about engineering responsibility. AI tools are improving at a pace that will make today's limitations look quaint within a few years. What will not change is the need for someone to understand what ships, to own the consequences when it breaks, and to make the architectural decisions that determine whether a system survives its first real encounter with users. The question worth asking is not whether to use AI — that ship has sailed. The question is whether the person hitting deploy understands what they are deploying, and whether they are prepared to stand behind it when it matters.