90% of Apps Built Entirely with Claude Code Will Fail in Production

That number isn't from a formal study, and treating it like one would be dishonest. It's a pattern anyone who reviews a lot of AI-generated codebases will recognize immediately: an app that runs perfectly in a demo, gets pushed to production, and starts failing in ways that had nothing to do with whether the code compiled.

What 'Fails in Production' Actually Means

It rarely means the app crashes on day one. What usually happens is quieter and worse: a user finds they can see another user's data by editing a number in the URL, two people editing the same record at once silently overwrite each other, a single bad actor runs up a five-figure API bill by hitting an unprotected endpoint in a loop, or the codebase becomes something nobody, including the person who prompted it into existence, can safely change six weeks later.

Claude Code Is Extremely Good at One Thing: Getting to 'It Runs'

This isn't an anti-AI take, and it shouldn't be read as one. Claude Code is genuinely excellent at getting from an idea to working code fast: scaffolding, boilerplate, wiring up a UI to an API, translating a clear spec into a functioning feature. That speed is real and it's valuable. The gap is between 'working' and 'production-ready,' and that gap has almost nothing to do with how capable the model is.

The Five Places Vibe-Coded Apps Actually Break

• No authorization checks beyond the happy path, so an authenticated user can often access someone else's data just by changing an ID in a request.
• No handling for concurrent writes, so two users touching the same record at once corrupt data instead of one request queueing or failing cleanly.
• No rate limiting or input validation on endpoints that call paid third-party APIs, which turns one bad actor into a runaway bill overnight.
• No migration strategy, just a schema that got reshaped by prompting until it worked, with no record of how to change it safely later.
• No tests, which means every future change is a guess about what might break instead of a checked assumption.

Why This Isn't an Argument Against Using Claude Code

Think of it like hiring an extremely fast junior developer. The output speed is incredible. That developer still needs code review, architectural guardrails, and someone senior checking the boundaries before anything ships. In my experience, AI coding tools follow the exact same pattern: a serious force multiplier for a team that already has engineering discipline, and a liability for a team with nobody checking the output against how production actually behaves.

What Actually Closes the Gap

Architecture decisions made by a human before prompting starts, not discovered by reading whatever Claude Code guessed. Code review as a non-negotiable step, even for AI-generated code, especially for AI-generated code. A security pass specifically on authentication and authorization, since that's the most common and most expensive gap. Load and concurrency testing before launch, not after the first outage. And an actual migration and rollback plan instead of a schema that evolved by accident.

The Actual Takeaway

The 90% isn't a knock on the tool. It's what happens when a powerful tool for generating code gets used without the engineering process that was always supposed to sit around code, AI-written or not: review, testing, and someone senior asking what happens when this gets used the wrong way. That process is exactly what our AI development team wraps around Claude Code and similar tools when we build production software with them.