Why Vibe-Coded Apps Break

The Problem Nobody Talks About Before You Ship

There is a specific kind of confidence that comes from building with AI APIs. You write a few lines of code, call the API, get back a response, and ship. The product works. You show it to people. They like it. You launch.

Then production happens.

Not in a dramatic way — at first. It starts with an unexpected bill. Then a user report that the app returned an error. Then a vague feeling that the outputs seem different than they used to. None of it is a catastrophic failure. All of it is the consequence of building the fun part (the AI integration) without building the boring part (the infrastructure that keeps it alive).

Lesson 501 introduced the five layers a vibe-coded app skips as a checklist — what to build. This lesson looks at the same five layers from the opposite end: the failure mode each missing layer produces once real traffic hits, the order those failures tend to arrive in, and what they cost you when they do. If 501 was the blueprint, this is the incident log. They are not edge cases. They are not bad luck. They are the predictable consequences of skipping the layers from the previous lesson. If you build without them, you are not moving fast — you are deferring a bill you will pay in money, users, or both.

The Five Failure Modes

No rate limiting is the most financially dangerous of the five. Your AI API endpoint costs money on every call. When there is no cap, any user — or any bot that discovers your endpoint — can call it as many times as they want. The economics are simple: they pay nothing, you pay everything. This is not hypothetical. It is the most common first production incident for developers who launch AI products without rate limiting in place.

No response caching is the most wasteful failure. In most AI products, a meaningful percentage of requests are identical or nearly identical. An FAQ bot, a writing assistant with a fixed set of tasks, a summarization tool — all of these see repeat inputs constantly. Without a cache, every request hits the AI API and incurs a cost. With a cache, repeat inputs return the stored response instantly at zero API cost. The fix is simple. The waste is substantial.

No auth hardening combines two related mistakes: running an AI endpoint that anyone can reach without authentication, and — the more common mistake — exposing your AI provider API key in client-side code. If your API key appears in JavaScript that runs in the browser, it can be extracted and used by anyone. This happens regularly in vibe-coded apps because the developer is thinking about the product, not the attack surface.

No error fallback is the failure that surprises developers because it feels like an edge case until it happens. AI APIs return errors. Rate limits get hit. The provider has an outage. The API returns a 503. If your code has no try/catch around the AI call, that 503 becomes an unhandled exception and your users see a white screen or a crash. The failure is invisible to you until you check metrics — which, if you also have no observability, you may not check for days.

Prompt drift is the only failure mode that can occur without any code change, without any user action, and without any obvious trigger. When your LLM provider updates their model, the same prompt can produce different outputs. Not wrong outputs, necessarily. Different ones. More formal, less formal. More verbose, more concise. If you are not logging AI outputs and comparing them over time, you will not notice until users complain — and by then you have no data to work with.

Why These Happen to Everyone

None of the five failure modes require a mistake in your business logic or your AI prompt. They require only that you built the integration but skipped the infrastructure. This happens because the infrastructure is invisible when the product is working — and the product always works in development.

Your dev environment has no bots. You do not call the API 10,000 times in testing. Your API key is in a .env file, not in client-side code. You always refresh the page when something errors. And you use one model version, which never changes during development.

Production is different on every one of those dimensions.

The Vibe Coding Cycle

The pattern repeats. Ship fast. Something breaks in production. Emergency patch. Ship the fix. Something else breaks. Repeat.

This is not a problem with building fast. Building fast is an advantage. The problem is treating "works in development" as equivalent to "ready for production." They are not the same environment. The gap between them is exactly where these five failure modes live.

The next lesson covers the minimum viable architecture that closes this gap — the four layers every AI product needs before it is ready to charge money.

If you are building your own AI product and want to discuss how these patterns apply to your specific stack, jeremyknox.ai has more on production AI product architecture.