Vibe Coded App Bugs in Production: How to See What Actually Broke

You built the thing: three weeks with Lovable or Claude Code, a small bill, a real product with real users. Then a user mentions in passing that something on a form misbehaved the day before. You have no idea which page, what went wrong or when. They cannot recall, or they stop replying. You click through every path you can think of, and nothing breaks. As far as you can tell there is no bug, until a second person hits it.

This is the most common shape of vibe coded app bugs in production, and it shows up again and again in builder forums: the preview works, the demo is flawless, and the version your actual users run, on their own devices with their own messy data, is a different app you cannot see into. The fix is not “learn to code.” The fix is instrumentation, and you can add it today.

What this problem looks like

The first is the blind founder. One non-technical builder described shipping a working app, getting a vague glitch report, and then spending days testing every scenario they could imagine without reproducing it. Nothing was logged and no error tracking existed. Their only source of truth was the one user who spoke up, and that user had moved on.

The second is the team that no longer understands its own product. Someone working on an app that was almost entirely AI-generated described a production incident where finding the underlying cause dragged on well past what anyone planned for, damaged the team’s standing with its users, and, by their own account, burned through roughly a month of AI credits across three developers. Nobody had written the code by hand, so nobody had a mental map of it.

The third is the dashboard that quietly ran on a laptop. A data engineer described being paged late on a Friday because a colleague’s vibe coded internal dashboard had stopped updating while that colleague was on vacation. The manager blamed a git update. The real cause: the scheduled job feeding the dashboard ran on the builder’s own machine, and the laptop was closed. Nothing was written down or monitored.

Why vibe coded app bugs in production are invisible

AI coding tools build the thing you asked for. Prompt for a signup form and you get one that works on the happy path in your preview. You did not ask for it to report failures somewhere you can read them, so it does not. Logging (a written record of what the app did and when), error tracking (capturing crashes with the stack trace, user, browser and page attached) and monitoring (checking the app is alive) are invisible to users, so they never appear in a feature-driven prompt. The model will add them, but only if someone knows to ask.

Second, the model is agreeable. Builders keep noticing that AI tools rarely push back unless firmly instructed to, and are quick to declare something ready to ship. Nothing in the workflow asks how you will know when this breaks. That question is engineering judgment, which vibe coding leaves out unless you put it back.

Third, when you did not write the code, you have no mental map of it, and neither does the AI in a fresh session. Without logs and traces, “find the bug” becomes “regenerate and hope,” the loop described in the 80% debugging trap.

Finally, production is a different environment. Real users bring old browsers, slow connections, odd data and race conditions your preview never produced. Seasoned engineers point out that this predates AI: the prototype was always the easy part, and vibe coding only sped that part up.

How to monitor a vibe coded app and fix bugs you can’t reproduce

Each step takes a session or two in Claude Code; Cursor, Lovable, Replit and Bolt have equivalents.

Step 1: Add error tracking first

Error tracking turns “something was glitchy” into a specific stack trace with page, browser, user and timestamp attached. Sentry is a common choice; one PM-background builder who shipped a large internal tool listed wiring in error tracking and analytics as a standard part of their setup.

In Claude Code, open a fresh session and ask it to integrate error tracking on frontend and backend, capture unhandled exceptions, failed API calls and failed form submissions, attach the user ID and current route to every event, keep secrets and personal data out of payloads, and show you what changed. Then trigger a deliberate error in production and confirm it arrives; until it does, you are not done.

Step 2: Add structured logging on the server

Logging is the app’s diary; ask Claude Code for a structured logger (one that writes searchable JSON lines) and a unique request ID that follows each request through the whole flow. One builder with a serious telemetry setup keeps a couple of dozen lines on this in their agent instructions. Put a version in your CLAUDE.md so every future feature ships with logging by default:

• Every API route logs its start, outcome and duration, with the request ID and user ID.
• Every caught error is logged with a stack trace before it is handled, never swallowed silently.
• Passwords, tokens, card numbers and full personal records are never logged.

Check the logs land somewhere readable and are retained.

Step 3: Add uptime and health monitoring

Monitoring answers “is it up right now?” Ask Claude Code to add a health check endpoint (a URL that returns OK only if the app can reach its database and critical services), then point a free uptime checker at it that alerts you on failure. Make every scheduled job record a “last ran successfully” timestamp and alert when it goes stale; that rule alone would likely have caught the laptop-on-vacation dashboard the first time the job failed to run. Then list where every piece of the system runs and move anything on a personal machine to a hosted job; many production surprises are really deployment mistakes.

Step 4: Make bug reports easy to give

Users will not remember details, so stop relying on memory. Add a feedback button that captures the page, browser, user ID and recent errors automatically. Session replay tools (which record what the user saw, with sensitive fields masked) turn “the form was glitchy” into something you can watch. Write each report up as a ticket and hand it to Claude Code with the matching error event and log lines. One builder who keeps detailed handover docs found their AI locates causes far faster because it has a map of the codebase.

Step 5: Write a regression test for every bug you fix

Once reproduced, ask Claude Code for a test that fails on the bug and passes on the fix, with a CLAUDE.md rule that the fix goes in the code, never in the test. A QA professional in one thread described this exact loop: test, report, fix, retest, check for regressions. Our guide on how to test a vibe coded app covers the testing side.

How a Red Corner CTO would have prevented this problem

Prevention here comes down to one question asked early and never dropped: when this breaks in production, how will you know, and what will you have in hand to fix it?

Before the first prompt, a Red Corner CTO would have put observability (the umbrella term for logging, error tracking and monitoring) into the starting spec, not the launch checklist: a CLAUDE.md with logging conventions written in week one, an error tracking account created before the first form exists, and a decision about where logs live and how long they are kept. It costs a few hours up front and almost nothing afterwards.

During the build, the CTO’s code reviews would look at the failure paths, not just the happy paths. The first review would have flagged errors caught and silently discarded, API calls with no timeout, and forms that fail without telling anyone. The CTO would have insisted that every feature ship with its log lines and at least one test, and asked to see the error in the tracking dashboard, not just the feature in the preview.

Before launch, the CTO would have run a short pre-flight: trigger a deliberate crash and confirm it is captured with user and route attached; confirm health check alerts reach a phone; confirm no scheduled job depends on a laptop; confirm logs are searchable by request ID; and confirm personal data is masked in logs and session replays, since that is where privacy exposure can creep in. If payments were involved, the CTO would have asked what gets logged when a charge fails before a single real customer was charged.

After launch, the CTO would have set a rhythm: review the error dashboard weekly, close every user report with a ticket, a trace and a regression test, and schedule cleanup days so the codebase stays legible to you and the AI. None of that requires you to become an engineer. It requires an engineer’s questions in the room at the right moments.

Frequently asked questions

How do I debug a vibe coded app bug I can’t reproduce?

Stop trying to reproduce it from memory and get evidence. Install error tracking so the next occurrence arrives with a stack trace, add structured logs with a request ID, and turn on session replay if the bug is in the UI. Then hand the trace, the logs and a written bug report to Claude Code and ask it to explain the cause before touching any code.

What is the minimum error tracking for a vibe coded app?

One error tracking tool wired into both frontend and backend, capturing unhandled exceptions and failed API calls with the user ID and route attached, plus an alert when a new error type appears. That alone turns most vague reports into something actionable.

Can Claude Code set up logging and monitoring for me?

Yes, when the request is specific: a structured logger, a request ID on every log line, an error tracking integration, a health check endpoint and a CLAUDE.md logging rule. Then verify it by triggering a real failure in production rather than taking the model’s word for it.

Get a CTO in your corner

You do not need a CS degree to run a reliable app. You need someone who has been paged at midnight enough times to know what to instrument before launch. Red Corner puts real CTOs alongside founders who vibe code, from first spec to first incident. Visit redcorner.io and get a CTO in your corner.