Asking for changes without breaking what works
The most common fear once you have a running app: ask for one adjustment and get a different app back. This guide is about why that almost never happens, and what to do the times it does.
The AI does not rewrite your app on every request
A small request produces a small change. The assistant does not regenerate the whole app when you ask it to change a colour: it finds the files involved and touches only those. That is what makes an edit cost few credits and take seconds instead of minutes.
What widens a change is a broad request. "Make the app look more modern" touches everything. "Increase the spacing between the cards on the home page" touches one file.
Bound the request
The sentence that protects your app most is the one saying what not to change:
Change the button text to "Book now". Do not touch anything else on this screen.
It works the other way round too, when you want the change to spread on purpose:
Apply this new font to every screen, not just this one.
When a plan shows up before the build
For requests that risk deleting or rewriting things, the assistant answers with a plan first and only builds after you click Approve and build. Light requests skip that and go straight through.
The plan is the best moment to notice you asked for the wrong thing. If it lists "remove the Customer model" and you only wanted to remove a field, type the correction instead of approving.
Changes the AI should not make
Some things you change yourself, with a button, and asking the AI is the long way round:
- colour, font and corner radius live in the Brand tab;
- the text or position of an element comes out faster through Edit in the top bar, clicking straight on the screen;
- integrations, domain, SEO and login each have their own tab, with their own fields.
Editing visually also consumes no credits, which matters when the adjustment is fine and takes several tries.
If the change broke something
Do not try to patch over it with another prompt. Go back first, then ask again more precisely:
- in the chat, use Undo last edit;
- check that the app is back to what it was;
- rewrite the request saying what went wrong and what must not be touched.
Rewriting on top of a broken app usually stacks a second problem on the first.
The cycle that works
One change at a time, look at the preview after each one, and publish when the whole thing stands up. Stacking five requests before looking is the fastest way not to know which of the five caused the problem.