What Vibe Coding Actually Produces - and Why It Looks Fine Until It Doesn't

What Vibe Coding Actually Produces - and Why It Looks Fine Until It Doesn't

Andrej Karpathy coined the term "vibe coding" in early 2025 to describe a development approach where the developer describes desired behaviour in natural language and accepts AI output without detailed review. By 2026, surveys suggest that roughly 92% of developers use AI coding assistance in some form, and AI generates close to half of all new code on GitHub.

The core issue is what AI tools optimise for. A language model generating code is rewarded for producing something that works in the described scenario - it is not reasoning about edge cases, concurrent users, data access patterns under load, or what happens when an authentication token expires mid-session. The code passes the happy path. Everything else is untested territory.

These are not obscure attack vectors. They include SQL injection, cross-site scripting, and broken authentication flows - the same categories that have been on the OWASP list for years precisely because they are the first things attackers check. Real incidents have started to surface.

The Moltbook breach made headlines in January 2026 when its founder, who built an AI social network using only AI coding tools without writing a single line of code himself, exposed 1.5 million API authentication tokens plus 35,000 email addresses within 72 hours of launch. The vulnerability was not sophisticated - any experienced engineer conducting a standard code review would have caught the configuration gap. But no code review happened because the entire application emerged from conversational prompts.

The speed advantage of vibe coding is real. The assumption that speed is the only thing that matters is what gets founders into trouble.

The Five Ways AI-Generated Code Fails in Production

Authentication and Authorization That Looks Correct

AI tools generate authentication flows that satisfy the described requirement - a login form, a token endpoint, a session management pattern - without reasoning about what the system should prevent. The result is code where the authentication mechanism exists but the authorization layer has gaps: API routes that skip permission checks, IDOR vulnerabilities where one user can access another user's data by changing an ID in a request, and session tokens logged in plaintext. These issues are invisible in local testing because the developer is using their own test account and never tries to access someone else's data.

No Error Handling and No Recovery Path

Production software fails. Databases go unavailable, third-party APIs return unexpected responses, network calls time out, disk fills up. The question is what the application does when those things happen. In AI-generated code, the common answer is: it crashes, returns a 500 error with a stack trace, or enters an inconsistent state and continues running until the next request breaks something else. Error handling requires thinking about failure modes in advance, which is exactly the kind of systematic reasoning that natural language prompting tends to skip.

Database Queries That Break Under Real Load

A query that runs in under 100 milliseconds against a development database with 50 rows can take 30 seconds against a production database with 500,000 rows. AI-generated database code frequently produces N+1 query patterns, missing indexes, unoptimised joins, and queries that lack pagination - patterns that are invisible during development and catastrophic at scale.

Zero Observability

When something goes wrong in production, you need to know that it went wrong, understand what happened, and be able to reproduce it. AI-generated codebases typically have no structured logging, no error tracking, no performance monitoring, and no alerting. The first sign that something is broken is a user complaint or a spike in support tickets - not an automated alert that gave you a 30-minute head start. Operating a production system without observability is not a minor inconvenience; it is the difference between a five-minute fix and a two-day incident.

Tangled Business Logic That Blocks Every New Feature

AI models solving an immediate problem generate code that solves that problem, without awareness of the broader architecture. The same logic appears in multiple places with slight variations. Business rules are scattered across controllers, database queries, and frontend components with no single source of truth. When a business rule changes - and it always changes - the developer needs to find and update every copy, and missing one produces bugs that are difficult to trace because they only appear in specific combinations of circumstances. This is what makes vibe-coded codebases increasingly expensive to maintain as they grow: not any single piece of bad code, but the accumulated cost of a structure that was never designed.

What a Professional Fix Engagement Actually Involves

The first conversation most founders have when they realise their vibe-coded product has problems is about rebuilding. The instinct is understandable: the existing code feels like a liability, and starting over seems cleaner. In practice, rebuilding from scratch has a poor track record. It takes longer than projected, reproduces many of the original bugs in new locations, and stops feature delivery for months. The experienced approach is almost always to fix in place.

Starting with a Technical Audit

Before anything gets changed, a proper fix engagement begins with a structured review of the existing codebase, architecture, and infrastructure. The goal is not to list every imperfection - it is to identify what is actually creating risk and what the priority order for addressing it should be. A well-run audit produces a written assessment with a prioritised fix list, an effort estimate, and a clear recommendation on whether the existing structure can be evolved or whether a specific component needs to be replaced. This document becomes the foundation for every subsequent decision.

Separating Critical from Non-Critical

Not everything in a troubled codebase is equally urgent. Security vulnerabilities that expose user data, production crashes that happen under real load, and data integrity issues that silently corrupt records are in a different category from code that is messy but functional, or performance that is slow but tolerable. A good technical partner helps founders separate these categories clearly and sequence the work based on actual business impact - getting the product stable before refactoring the parts that are simply unpleasant.

Stabilisation and Refactoring as Distinct Phases

Stabilisation addresses the things that are actively breaking or creating risk: security holes, production crashes, broken error handling, missing authorization checks. This phase should be fast and targeted. Refactoring - restructuring the codebase so it is maintainable, extensible, and possible to onboard new developers into - happens after the product is stable, not simultaneously. Running both at the same time tends to produce instability in the fixes themselves.

Adding Observability Before Anything Else

One of the early deliverables in any professional fix engagement should be basic observability: structured logging, error tracking, and production monitoring. Without these in place, the team fixing the codebase cannot measure whether the fixes are working, and the founders operating the product cannot know when new problems appear. This is often the first infrastructure addition, not the last.

How to Choose the Right Partner for This Work

The market for vibe coding fix services is new and not yet well-defined, which means the range of quality is wide. A few things separate a team that will genuinely improve your product from one that will produce an expensive audit report and then disappear.

They Read the Code Before They Make Claims

Any team that gives you a firm cost estimate or a confident diagnosis before spending time in the actual repository is making things up. Vibe-coded codebases vary enormously in their specific failure patterns, and the only way to know what is wrong is to look. A credible partner will scope the audit before scoping the fix.

They Explain What They Will and Will Not Change

A team fixing an existing codebase should be able to explain, in plain terms, which parts of the system they are touching and why. Vague commitments to "clean everything up" or "modernise the architecture" without specific scope are a warning sign. Good technical partners can tell you exactly which files are being refactored, which security issues are being addressed in which order, and what the measurable outcome of each phase of work is.

They Can Stay as a Long-Term Partner

The most valuable outcome of a fix engagement is not just a more stable codebase - it is a technical relationship that allows the product to grow without accumulating new debt at the same rate. The best outcomes happen when the team that fixed the product continues as an engineering partner through the next phase of development, because they carry the context of what was changed and why.

Conclusion

Vibe coding as a prototyping tool has earned its place. The speed to a working demo is genuine, and for founders who need to validate an idea quickly, it is the right approach for that phase. The problem arrives when the prototype becomes the product without the engineering work that bridges the gap - security review, error handling, observability, architectural structure, and the kind of systematic thinking about failure modes that natural language prompting does not produce on its own.

The industry has moved from treating AI-generated code as a curiosity to recognising it as a category with specific, well-understood failure patterns - which also means those patterns can be addressed systematically, by people who know where to look.

The product you built with AI is not a failure. It is a starting point. Getting it to production-readiness is an engineering problem, and engineering problems have solutions.