What actually happens when AI builds an app?

What does the tool know before it writes anything?

A model has no memory of your project between requests. Everything it appears to know was put in front of it moments earlier by the tool wrapped around it: your message, the project's file list, the contents of the files it thinks are relevant, your framework's conventions, and any rules the platform enforces.

Missing project context can explain a wrong change. For example, your database already has a `status` column, but the builder never receives that schema and proposes a second column. Compare the proposed migration with the existing schema before applying either change.

What are the actual steps between prompt and page?

1. 1Read the request and gather context: existing files, project structure, previous messages.
2. 2Decide on a plan: which files to create, which to edit, what data is needed.
3. 3Write the files. This is plain text output that the tool saves to disk.
4. 4Install any packages the new code imports.
5. 5Apply database changes, if the feature stores anything — new tables, columns and access rules.
6. 6Run the build. If it fails, read the error and edit again.
7. 7Show you the result in a preview that is running the newly written code.

Nothing in that list is magic, and nothing in it is hidden from you. The files are in your project. The database changes are in your database. The packages are in your dependency list.

Why does it sometimes produce code that looks right and behaves wrong?

A model predicts plausible code. Plausible and correct overlap most of the time, and diverge in the places where correctness depends on something the model could not see: your real data shape, the permission rules on your tables, the value of an environment variable in production, the version of a library you happen to be on.

• It calls an API endpoint that existed in an older version of the library.
• It reads a column name that is close to yours but not yours.
• It writes a query that works for you as the owner and fails for everyone else, because the access rules only allow you.
• It assumes an environment variable exists because the code reads it — nobody has set it yet.

These are not exotic bugs. They are the four failures you will meet most often, and all four are found in seconds if you know where to look.

What happens to the database?

If the feature stores anything — a note, a signup, a saved setting — the tool writes a migration: a piece of SQL that creates the table and sets the rules for who can read and write each row. That SQL runs against your real database and the change is permanent until another migration changes it.

Access rules matter more than the table itself. A table with no rules is either unreachable (nothing can read it) or wide open (anyone can). Both look identical while you are the only user, which is why database permission problems usually surface on the day someone else signs up.

How do you check what the AI actually did?

1. 1Read the list of changed files. If a change touched something you did not expect, ask why before moving on.
2. 2Open the new code and find the line that does the real work — the fetch, the query, the redirect. Everything else is scaffolding.
3. 3Test the unhappy path: signed out, empty input, wrong value. The happy path almost always works.
4. 4Look at the database rules for any new table and say out loud who can read it.
5. 5Check whether the feature needs a secret, and whether that secret exists in the live environment as well as locally.

Where does MessyDev fit?

Tools like Lovable are for building — you describe the thing and it gets built. MessyDev is the layer around that: understanding what was produced, testing it, finding out why it broke and verifying your fix. You keep building where you build. MessyDev makes you the person who can explain what the build did.