When you inherit a system that was built fast, with AI assistance or "vibe coding", and it is already live in production, the hardest part is usually not reading the code. It is figuring out who controls what, whether you can deploy safely, and what breaks the first time real traffic hits an edge case.
"It can demo" and "it can be maintained safely" are two different claims. AI helping a team ship something that demos quickly is genuinely useful. The catch shows up on handover. Below is the pre-takeover checklist I run before touching a production change: stabilize first, inventory first, then decide whether to maintain, partially refactor, or rebuild.
1. Nobody actually holds production control
Production control is often fragmented: the repo sits in one personal account, the cloud under a different email, the domain and DNS with a third party, the database and payments with other owners. If the original team leaves, the new owner may be unable to log in everywhere, or to revoke access.
Check first: confirm which account owns the repo, cloud, DNS, database, environment variables and secrets, third-party APIs, payments, email, monitoring, and backups, one by one, and whether you can log in yourself and transfer ownership. Do not change code or redeploy before control is mapped.
2. No reproducible build and deploy
A system can be live while its build and deploy process exists only on one machine or in one person's memory, with no CI/CD, deploy script, or rollback path. That makes even a one-line change risky.
Check first: can you reproduce the build and deploy from source in a clean environment? When a deploy fails, can you roll back to the last working version? The AWS Well-Architected Operational Excellence pillar treats repeatable, reversible change as a baseline requirement, and getting this path working is the safety net for every change that follows.
3. Secrets hardcoded in the code or the frontend
Fast-built systems can hardcode API keys, database passwords, and third-party tokens directly in code, config files, or even frontend JavaScript. Once these land in git history or a public bundle, treat them as exposed.
Check first: scan the repo and frontend for hardcoded credentials and confirm which have entered git history. OWASP documents use of hard-coded credentials as a software weakness, and its Top 10 covers the related security-misconfiguration and vulnerable-component risks. On takeover, rotate anything potentially exposed, then move secrets into environment variables or a secrets manager.
4. Messy dependency versions with known vulnerabilities
Fast projects pull in many packages at once, with unpinned versions or references to unmaintained libraries. If one dependency updates or disappears, the system can break with it, and some may carry known CVEs.
Check first: is there a lockfile with pinned versions? Run a dependency vulnerability scan and list the high-risk and unnecessary packages. Pin versions first, then upgrade incrementally. Do not attempt one big clean sweep that leaves the system unable to start.
5. No tests, no monitoring: you find out after it breaks
A prototype can reach production with no automated tests and no alerts. Without monitoring, users notice failures before the team does, and no signal tells you what broke after a change.
Check first: is there any automated test you can run? Does production have basic error and availability monitoring, with alerts landing somewhere a human will actually see? Before refactoring, add at least the layer that means "someone will know when it breaks", otherwise every change is a blind change.
6. Data model and migrations are not version-controlled
No migrations, no schema versioning, and backups nobody has verified can actually be restored. Changing the data structure becomes a bet, and one mistake can lose data you cannot get back.
Check first: are schema changes managed with migrations? Where is the most recent backup, how often does it run, and has a restore actually been tested? Before touching any schema, confirm you can safely return to the current state.
7. "Looks like it works", but edge cases and error handling are missing
Demos use clean inputs and small volumes. Real production hits null values, oversized inputs, concurrency, third-party timeouts, and exhausted quotas. AI-generated code often covers only the happy path and cannot recover when an exception arrives.
Check first: do the critical flows (login, payment, writes, outbound calls) have error handling and retries? Are inputs validated? Find the spots that break when a user or an external service does something unexpected.
8. No docs, no architecture diagram: just source code
The last problem makes the previous seven harder: no architecture diagram, no deploy notes, no dependency list, just a pile of code. Whoever makes the next decision has to reverse-engineer everything first.
Check first: frame the first deliverable of a takeover as an inventory document, not "change a feature immediately". At minimum produce a system architecture diagram, an Access Map (who can access what), a Dependency Map (services and relationships), and a Risk Register (known risks and the order to address them).
Takeover is not only about rewriting
Once those 8 points are mapped, the assessment usually points to one of four directions, weighed against control, maintainability, and risk:
- Maintain directly: control is obtainable and the system is broadly maintainable; just add the missing deploy, backup, and monitoring.
- Partial refactor: mostly stable, with a few high-risk modules to rewrite or replace.
- Gradual replacement: keep the current service running while swapping out the highest-risk parts piece by piece.
- Full rebuild: control, data, or core-architecture risk is too high, and rebuilding is faster and safer than forcing a rescue.
Not every inherited system needs a full rewrite. An inventory-first assessment tells you which of the four is actually justified.
Sources
- NIST SP 800-218 Secure Software Development Framework (SSDF): secure practices such as key management, dependency control, and reproducible builds.
- OWASP: Use of hard-coded password (software weakness) and the OWASP Top 10 (security misconfiguration, vulnerable components).
- AWS Well-Architected, Operational Excellence pillar: repeatable, reversible deploy and change processes (this does not imply mandating AWS).
This is a pre-takeover check and decision guide, not a security audit or legal opinion, and not a guarantee that any system can be saved. If the original team left and the system still runs but no one dares to touch it, here is how the software takeover and rescue service maps control, deploy, data, and risk first. To gauge it yourself, try the vibe-coded production-readiness self-check.
Canonical version: https://care.omniai.one/blog/ai-coded-app-takeover-common-problems/
Top comments (1)
On item 1 I'd add the mail side of DNS to the inventory: which services the SPF record includes and whether DMARC is set, because switching the sending provider during a takeover without updating SPF is an easy way to send the app's password resets to spam in week one.