Vibes-Only Migration
AI can port the files. It cannot infer every behavior your old system quietly provides.
What it is
A vibes-only migration is a framework, platform, or database move where AI translates visible code before the team inventories hidden behavior, integrations, and rollback. The new system “works” — until cutover reveals what the files never described.
How it happens
The team starts with the obvious files. AI can translate visible, mechanical code quickly. Routes port. Tests port. The dashboard renders against the new stack. Confidence climbs file by file. But nobody enumerated the unseen layer: the implicit behaviors of the old system (auto-commit semantics, default timezones, NULL ordering, the way the ORM coerced types), the integrations the old system silently satisfied (webhooks no service owns, observability that piggy-backs on a specific log format, the cron that runs against the old hostname), and the features whose correctness depends on framework-specific behavior that doesn’t translate.
AI can reason about behavior when given the relevant constraints. But a translation of visible code cannot establish parity with production contracts that were never supplied. The port can look complete because the visible parts are.
Why it’s dangerous
If those gaps survive to cutover, an incident may become the first real audit. In an illustrative case, invoices show the wrong timezone, a scheduled report emits empty CSVs, or a partner webhook returns 404 because it was absent from the migration inventory. Customers and on-call engineers discover those differences after the old path has stopped receiving normal traffic. Rolling back may still be possible, but only if the team preserved a tested route back and knows how to reconcile data written since cutover.
AI makes file translation fast enough that the missing inventory may not become obvious until rollback is expensive. The same speed can help the team repair the gap: use AI to compare old and new behavior, turn differences into checks, and rehearse the cutover before real traffic depends on it.
How to prevent it
Start an inventory early, before translation work is mistaken for migration readiness. Identify semantic differences, implicit integrations, and behavior that new-code inspection cannot verify. AI can scout for candidate gaps in code and configuration: ask “what could break that won’t be obvious from a file-by-file translation?” Check that candidate list against production configuration, logs, integrations, and real users. Before production cutover, document the sequence and a tested recovery path, including how to handle writes made after cutover.
Scale the checks to the stakes. A library upgrade, a database swap, and a platform migration call for different levels of rehearsal. The friction signal is the moment someone says “we’re mostly done” without being able to name what’s left.
The serious team fix
Three things, reinforcing each other:
- A written cutover plan before production traffic moves. Names the semantic differences, the integration points, the cutover sequence, and the rollback path. AI drafts it; humans interrogate it; the team commits to it. The plan is a precondition for cutover, not a deliverable after it.
- An AI-assisted differences review. Give AI access to the old and new code and ask it to flag possible changes in type coercion, timezone defaults, NULL handling, ordering, encoding, and error shapes. The output is a candidate list, not a parity verdict. Owners of the old system check it against observed behavior and decide which differences need tests, migration scripts, or explicit acceptance.
- Representative behavior comparison. Where safe, replay read-only traffic against both systems and compare outputs. Stateful writes need an isolated replay or a deliberately engineered dual-write and reconciliation process; sending live writes to both systems by default can create new failures. Choose the method to fit the migration’s stakes. Resolve or explicitly accept material differences before cutover. A AWS cutover guidance also calls for rollback planning that handles data written after cutover.
The shift is: files ported is a progress report, not proof of a migration. Make behavioral differences observable before cutover.