Vibe Coding and Incidents: Why Your AI-Built App Needs a Status Page

Vibe coding lets one person ship in a weekend what used to take a team a quarter. It also means a lot of software now runs in production that nobody fully understands — including the person who shipped it. When that software breaks, the fix may take a while. What your users see in the meantime doesn't have to.

What vibe coding is

The term comes from a February 2025 post by Andrej Karpathy, who described “a new kind of coding” where you “fully give in to the vibes” and “forget that the code even exists.” You describe what you want, accept what the AI writes, paste error messages back in and keep going until it works.

Karpathy pitched it for throwaway weekend projects. Since then it has become how many real products get built: founders launching SaaS apps with AI app builders, product managers shipping internal tools, and engineers using agents to write whole features they skim rather than read.

That's mostly good news. More people can build, and ideas get tested faster. But it changes one thing that matters a lot: the gap between what's running and what anyone understands keeps getting wider.

Why vibe-coded apps have different incidents

Every product has incidents. Vibe-coded products tend to have a particular kind:

• Bugs nobody has read. Code that “works” on the happy path can fail on the first real edge case — an empty list, a timezone, a user with an apostrophe in their name.
• Security holes that look like features. Veracode's 2025 GenAI Code Security Report tested code from more than 100 language models and found that 45% of the samples introduced a known security flaw. Missing access checks and exposed keys turn into data incidents, not just outages.
• Agents with production access. In July 2025, SaaStr founder Jason Lemkin reported that a Replit AI agent deleted his production database during a code freeze, then told him a rollback wasn't possible. It was. The tool did what tools do; the safeguards weren't there.
• Slow diagnosis. If you didn't write the code, finding the cause means reading it for the first time under pressure — or asking the same AI that wrote the bug to find it.
• Long dependency chains. Many vibe-coded apps lean on a hosted database, an auth provider, a payment provider and one or more AI model APIs. Any of them can be the outage.

The last two points are the important ones. Vibe-coded incidents often take longer to understand than incidents in code your team knows well. That's exactly the window where users decide whether to trust you.

The fix can wait a little. Communication can't.

Users don't know or care how your app was built. During an incident they want three answers: is it broken, is someone on it, and when will they hear more. You can give all three before you have any idea what the root cause is.

This is the quiet advantage of a status page: it separates “we're fixing it” from “we're telling people.” You can spend an hour asking your AI assistant to trace a failing query while the status page has already told every user what's affected and when the next update is coming.

You can vibe-code the app. You can't vibe-code your users' trust. That gets built in the first ten minutes of an outage.

Writing updates when you don't know the cause

The hardest part of incident communication for a vibe coder is admitting you don't know yet. You don't have to explain anything technical. Describe what users experience and commit to a next update:

A few rules that matter more when the code is AI-written:

• Never let the AI guess the cause publicly. Use an AI writing assistant to make your update clearer, but the facts — what's affected, since when, what you're doing — come from you.
• Don't blame the tool. “Our AI agent deleted the database” is not an explanation users accept. You shipped it; the incident is yours.
• Be honest about data. If an incident might have exposed user data, say what you know and what you're checking. Silence here costs more than anywhere else.
• Prepare the wording in advance. Incident templates let you post a first update in seconds instead of writing one at 2 a.m. See also our incident communication templates.

A minimum reliability setup for vibe-coded apps

You don't need an SRE team. You need a few things set up before the first incident, most of which take an afternoon:

1. Monitoring that tells you first. Check your homepage, login and one key API route every few minutes with endpoint monitoring. Finding out from an angry user is the worst way to start an incident.
2. A public status page. Group components the way users think about your product — “App,” “Login,” “Payments,” “AI features” — not the way your code is organized.
3. Subscribers. Let users get updates by email, Slack or webhook, so they don't have to keep checking.
4. A rollback you've tested. Know how to go back to yesterday's version in one step. Many vibe-coding incidents end with “we reverted.”
5. Backups an AI can't touch. Keep production data and its backups out of reach of any agent that can run commands. Separate dev and production databases.
6. A short postmortem habit. After each incident, write down what happened and one change you'll make. A postmortem template keeps it to ten minutes. Over time this is how you start to understand your own codebase.

Using AI agents for incident updates

If your workflow already runs through AI agents, they can help here too — drafting updates, or opening an incident through a status page API when monitoring fires. Keep the same rule as for code changes: an agent can draft and propose, but a human approves anything that goes out publicly.

Ship with vibes, run with discipline

Vibe coding is a real shift, and it isn't going away. The builders who do well with it won't be the ones whose apps never break. They'll be the ones whose users always know what's going on when they do.

If you're shipping a vibe-coded product, create a free Statusentry account, add your components and turn on monitoring before your next release. You can see what your users would see on our demo status page. For the broader picture of how AI is changing reliability, read AI development and incident communication.