AI Building

What should you check after AI changes an app?

Start with the change, not the screenshot. Ask which files changed, which packages were added and whether a database migration is proposed. A page can look right while its data rules are wrong. Keep the previous working version available so you can compare the behavior rather than asking for another broad rewrite.

Teaching example: your app already stores a record's status, but the builder proposes a second status column. This is an illustration, not a MessyDev customer incident.

1. 1Show the existing schema and the proposed migration together. Ask why a new column is necessary.
2. 2Check which column the form writes and which column the list reads. Different columns can make a saved change appear to vanish.
3. 3Test an existing record and a new record in an isolated environment before applying the migration anywhere with real user data.

Does a successful build mean the change is safe?

No. Compilation checks the errors covered by your build configuration. It does not prove that a second account cannot read the first account's records, or that a checkout return means payment succeeded. Write down the expected result before testing: who can perform the action, what should persist after refresh, and what a rejected request should show.

Use the app-building guide for the request-to-files sequence and the coding-tools guide for context and tool calls. If the app already fails, move to Troubleshooting rather than changing several unrelated files at once.