AI can audit Laravel migrations well, but refactoring broken ones safely needs a developer in the loop.

The structural pattern — read migration files, trace dependencies, detect broken references — is consistent. But each codebase has unique history and intent, so the agent must exercise fresh judgment on every instance rather than applying a fixed template.

The end goal (migrate:refresh runs cleanly) is a binary, testable criterion, which is good. However, determining the correct fix for a broken dependency — versus the expedient one — involves ambiguity about original intent that the files alone may not resolve.

The agent needs read/write access to the codebase, the ability to run artisan commands in a safe environment, and ideally a schema snapshot or git history to infer intent. Without a sandboxed DB environment to test against, the agent cannot verify its own fixes.

Incorrectly refactored migrations can silently corrupt schema state, cause data loss on refresh, or introduce bugs that only surface in production. Even in a dev environment, a bad refactor can mislead the team about the true schema history.

Deciding whether a dropped table reference was intentional, whether rollback logic should restore data or just structure, and whether a refactor preserves business semantics all require context that lives in developer memory and product history — not in the files.