Production reality check
The vibe was immaculate. The app is broken.
A fast prototype can become a real system before its architecture, tests and release process catch up. The safest next prompt may be no prompt at all.
01
What happened?
Vibe coding optimises for momentum. Production demands repeatability. When prompts make broad edits without a stable baseline, each attempted repair can mix bug fixes, refactors, package upgrades and schema changes.
02
Why this happens
- There is no small, reviewable diff between the working and broken versions.
- Generated components duplicate state or validation rules in different places.
- Preview data, browser storage or mocked APIs hid a missing production dependency.
03
What you can check yourself
- Freeze new edits and save the current commit, logs and screenshots.
- Find the last known-good commit and inspect only the changes after it.
- Verify authentication, API endpoints, database migrations and secrets separately.
- Turn the original failure into a repeatable test before accepting another generated patch.
NOT TECHNICAL
You don't need to code to stop making it worse.
The most useful thing you can do right now is stop generating new changes, not produce a better prompt.
- Freeze the project — no more "just try this" prompts until someone has looked at what broke.
- Note roughly when it last worked and what you asked the AI to build or change since then.
- Save, or ask your AI tool for, the current project export or repository access.
- List anything that touches real users, money or personal data — that changes how carefully the fix needs to be handled.
Shipvise or a senior reviewer can take that history and work out which change caused the break, without you needing to understand commits or diffs yourself.
04
How to test the fix safely
Test a narrow patch on a staging copy of production configuration and representative, non-sensitive data. Keep the last stable artifact available for rollback.
05
When you need a developer
Use a senior reviewer when no one can explain the generated architecture, when data may be lost, or when every fix breaks a different path. Shipvise adds versioned staging, checks, review and an explicit release decision without forcing you to abandon your AI tool.
FAQ
Questions people actually ask
Is vibe-coded software always unsafe?
No. The risk comes from unreviewed behavior and an uncontrolled release process, not from the label. Small scope, tests, review and reversible deployment reduce that risk.
What should I give a developer?
Provide repository access, the failing URL, steps to reproduce, logs, the last working commit, deployment configuration and a description of what the AI changed.
Do I need to rebuild the app from scratch?
Not automatically. First determine whether the problem is localised. A rewrite is justified only after comparing its cost and risk with a controlled repair.
How do I fix a vibe-coded app that suddenly broke?
Stop prompting for more changes first — each new attempt can hide what actually broke. Find the last point where it worked, compare that to the current state, and fix the specific regression instead of asking the AI to rebuild the feature from scratch.
Why does vibe coding keep breaking features that used to work?
Broad, fast prompts tend to touch more of the app than the task needed, so a fix for one thing can quietly break another. Without small, reviewable changes and tests, nothing catches that collateral damage until a user hits it.
Should I keep asking the AI to fix it, or will that make things worse?
Another "fix it" prompt can help. It can also break three more things. Preserve the current broken version first, work out what actually changed, and give the AI a narrower, more specific task instead of repeating the same vague request.
I don't use Git — how do I get back to a working version?
Check your AI tool for a version or checkpoint history, a previous export, or an earlier deployment you can restore. If none of those exist, this is the moment to start keeping one — even a manual copy of the working project before each big change saves you here.
Can a developer fix an app built with Lovable, Bolt, Replit or Cursor even if they did not build it?
Yes. A developer does not need to have used the same tool — they need access to the code, the failing behavior, and what changed recently. The underlying app is still just code and services; the AI tool used to generate it does not change that.