When your AI builder says “done” and the screen looks exactly the same, one of two things is true. Either the change was made and you are not looking at it, or the change was not made and the builder reported it anyway. The first is more common than you would think, and it takes about a minute to rule out. The second is not the builder lying, exactly. It edits files and reports on the edit. It does not watch your screen. So “done” means “I finished typing,” not “you can see it now.” Either way, “done” is a claim, and the running app is the only proof.
Start by checking which copy of the app you are looking at
There are usually two or three copies of your app, and the builder only changed one of them.
The first split is preview versus published. In Lovable, the preview next to the chat is the working version. The live address your users open is a snapshot from the last time you clicked Publish, and new edits are not pushed to it on their own. You click Publish, then Publish changes, or the live app stays frozen. Accepting a draft does not publish it either. If you asked for a change, then opened the live link on your phone, you were looking at last week’s copy.
The second split is your browser’s memory. Browsers keep a stored copy of a site so it opens faster, and sometimes show you that copy instead of the new one. Reload the page, and if it still looks old, open the address in a private window, which ignores what the browser stored. If the private window shows the change, nothing is wrong with the app. Your browser was behind.
The third split is a condition you are not meeting. The change is there, but only when someone is logged in, or only on a narrow phone screen, or only when there is data to show. You asked for a nicer list of saved trips and got one, but you are logged out and staring at the empty version. Try the app the way the change is meant to be seen before you decide it is missing.
Then the cases where the change really was not made
If you have ruled out all three copies, there are three common ways the change did not land.
It changed the wrong thing. You said “the button,” and there are four buttons. You said “the trips page,” and the builder found two screens that could be called that and picked the other one. This is the single most common cause, and it is a naming problem, not a skill problem. The builder did exactly what you said to something you did not mean.
It changed the words but not the behavior. You asked for “a save button that keeps my trip.” The button now says Save. Clicking it does nothing, because the part that stores the trip was never wired to it. The builder satisfied the sentence, not the intent, and its report was honest about the sentence.
The change broke the build, so you are seeing the last good version. Apps have to be assembled before they run, and if the new edit has an error in it, the assembly fails and the screen keeps showing whatever ran last. In Lovable this shows up as a build error with a “Try to fix” button, which scans the logs and attempts a repair. In a builder on your own computer it shows up as red text in the window.
How to tell which one it is in about a minute
Do not guess, and do not send “it still doesn’t work,” which gives the builder nothing to go on. Ask it, in plain words, what it changed and where. The answer usually settles it. If it names a screen you did not ask about, it changed the wrong thing. If it says a button was added and says nothing about what happens when you click it, you have the words-not-behavior case. If it mentions an error, the build is broken. And if the answer matches what you asked for and the change is still not where it says, you are back in the first section, looking at the wrong copy.
Lovable also keeps a version history, and every change it makes creates a new version. Look at the newest entry. If there is no new version since your message, nothing was written. If there is one, you can open it in a snapshot view and see what it contains before you decide to keep it or revert.
What the fix looks like, and why this gets worse as the app grows
You do not need to read the code to know whether a change is real. You need two things. The first is a builder that has to explain and show its change before you believe it: what it changed, where, and what you should see when you click, so that “done” becomes a claim you can check. The second is a saved version to fall back to, so that a change you cannot see, or one that broke everything, is undone in seconds instead of prompted around for an hour. Lovable’s history gives you part of the second. Once your code lives on your own computer, the same safety net exists for any project, kept by your builder and never read by you.
A one-screen app rarely has this problem. There is one button, one page, one copy. The problem arrives around the tenth feature, when “the button” is ambiguous, a change in one place has to be wired to another, and there are enough versions that you lose track of which one you are looking at. Lovable and Claude Code share that problem with every tool ever built, because that is what software is like, and it is the moment people who cannot read code either start checking by behavior or start burning credits on fixes to fixes.
You can learn more, and get the full prompts and the decision tables, in our course: Lesson 2, Trust Without Reading Code. The first lesson is free, no card.
In the next ten minutes: reload, then open the app in a private window, then try it logged in. If it is still not there, ask the builder what it changed and where, and read the answer against the six causes above. Whatever it tells you, name the exact screen and the exact behavior when you ask again, and click it before you believe it.