Production reality check
The AI changed your app. The update changed your plans.
Treat the incident as a regression, not an invitation for ten more speculative prompts. Restore a stable service first; improve the code second.
01
What happened?
Generated updates can touch distant files, upgrade packages, change schemas or reinterpret a vague request. If the release was not tied to a reviewed commit, the real change may be larger than the visible feature.
02
Why this happens
- A broad agent edit included “helpful” changes outside the requested scope.
- A dependency or generated lockfile changed runtime behavior.
- Frontend and backend contracts or database schema moved out of sync.
- A forward-only migration made application rollback unsafe.
03
What you can check yourself
- Stop deployments and identify the exact last good and first bad versions.
- Compare code, lockfiles, configuration and migrations between them.
- Check whether data changed after the release before rolling application code back.
- Write a test that fails on the bad version and passes on the good one.
04
How to test the fix safely
If data compatibility allows, restore the known-good artifact. Test the proposed repair in staging against a safe production-like dataset, then release it as a new version rather than editing production in place.
05
When you need a developer
Call a developer when rollback affects schemas, queued work, external side effects or security. Shipvise keeps versioned releases, checks and explicit deployment decisions together so the recovery path is known before the next incident.
FAQ
Questions people ask after the demo stops working
Should I roll back immediately?
If user impact is material and rollback is known safe, usually yes. Check database and external side effects first; application rollback does not undo every change.
Can I ask the AI what it changed?
You can, but use the version-control diff as the source of truth. Agent summaries may omit generated files, dependency changes or side effects.
How do I prevent this next time?
Use small branches, automated checks, staging, reviewed diffs, explicit approval and a rehearsed rollback for every production release.