Guides / Prompting and shipping

How to Iterate on an AI-Built App Without Breaking It

Improve an AI-built app one small change at a time: describe what you see, plan big changes, test each prompt and roll back instead of piling on fixes.

Mythex Team · 2026-09-29 · 5 min read

To iterate on an AI-built app without breaking it, change one thing per prompt, check it in the preview, and save a checkpoint before moving on. Describe what you see rather than what you think the code does, plan big changes before building them, and when a change goes wrong, roll back to the last good version instead of asking the AI to fix its own fix.

The first version of an app often comes together in minutes. The hard part is the fiftieth change, when each new prompt risks breaking something that already worked. This guide is the loop that keeps that from happening.

The iteration loop

1. Pick one change. One feature, one bug, one page.
2. Describe it in terms of what the user sees and does.
3. For big changes, plan first. Ask for a plan, read it, then build.
4. Check the result in the preview — the change and the flows near it.
5. Save a checkpoint or commit.
6. Repeat.

Every step exists to keep changes small and reversible.

Step 1: Keep a short list

Before prompting, write down what you want to change, in order of importance. It stops you from sending a paragraph of ten wishes in one message, and it gives you a way to say "not now" to ideas that pop up halfway through.

If a change is big, break it down. "Add team accounts" becomes: create teams, invite a member, switch between teams, limit data to the current team. Each is its own prompt. Writing user stories is a good way to do this.

Step 2: Describe what you see

The AI can't see your screen unless you tell it. Point at specific things, and say what should happen:

On the pricing page on a phone, the Pro card's button is cut off at the right edge. Keep the desktop layout the same; on screens under 640px, stack the cards and make the buttons full width.

Compare that with "the pricing page looks bad on mobile". The first can be done and checked in one go; the second invites a redesign you didn't ask for.

Screenshots help. If your builder accepts images, attach one and circle the problem.

Step 3: Plan before big changes

For anything that touches several parts of the app — a new data model, payments, user roles — ask for a plan before any code changes:

Don't change code yet. I want users to belong to teams and see only their team's projects. Plan the change: which tables, pages and API routes change, what happens to existing users' data, and in what order you'd build it.

Read the plan. If it's wrong, correcting a plan is much cheaper than undoing a build.

Step 4: Say what must not change

AI tools sometimes "tidy up" things you didn't ask about. Protect what works:

Add a date filter to the orders table. Don't change the table's columns, styling or the export button.

For rules that apply everywhere — brand colours, tone of voice, "never delete data without confirmation" — put them in a project notes file or knowledge setting the AI reads every time, instead of repeating them.

Step 5: Check more than the change

After each prompt, test:

• The change itself. Does it do what you asked, on desktop and phone?
• Its neighbours. Things on the same page, and flows that use the same data.
• The critical path. Sign up, log in, the main action, payment. A thirty-second pass after each big change catches most breakage early.

If something is off, report it precisely — see how to write a good bug report.

Step 6: Roll back instead of piling on

When a change breaks something and the first fix doesn't work, stop. Each extra "fix" is built on a broken state, and the problems compound.

Instead:

1. Roll back to the last version that worked (a checkpoint or Git commit).
2. Work out what was unclear about the prompt.
3. Try again with a smaller or clearer request.

That change broke saving drafts. I've rolled back. This time: add the autosave indicator only, as text in the header. Don't change how drafts are saved.

Step 7: Know when a rebuild is right

Rebuilding from scratch throws away a lot of working detail. It's worth it only when:

• The product idea has changed completely.
• The underlying structure can't support what you now need — for example, it was built as a static site and now needs accounts and a database.
• The project is still close to empty.

When you do rebuild, list what to keep: name, colours, copy, the parts users liked.

Example prompts

Before we continue, summarise how the app currently works: pages, data it stores, and anything you think is fragile.

I want to add recurring bookings. What's the smallest version that would be useful? Suggest it as three separate changes we can make one at a time.

Review the last three changes for anything that might have broken the checkout flow. Don't edit yet.

Common mistakes

• Ten requests in one prompt. Some get done, some half-done, and you can't tell which.
• Vague feedback. "It's broken" or "make it better" produces guesses.
• Never checking the neighbours. A change to a shared component breaks three other pages.
• Fixing fixes. Four prompts deep into a bug, roll back.
• Repeating context every time instead of keeping standing rules in project notes.
• Rebuilding when stuck. Most "start over" moments are really "roll back two steps".

Checklist

• One goal per prompt.
• I describe what I see and what should happen.
• Big changes get a plan before any code.
• I say what must not change.
• After each change I test it, its neighbours and the critical path.
• I save a checkpoint or commit after each change that works.
• When a fix fails, I roll back rather than stacking fixes.
• Standing rules live in project notes the AI reads every time.

Iterating on Mythex

Mythex is built around this loop:

• Plan, Build and Ask modes. Plan discusses the approach before editing; Ask answers without changing code; Build makes the change. See Chat.
• Checkpoints. After each successful turn, Mythex saves a git checkpoint; Revert to this point rolls back. You can also edit an earlier message and Discard & resend to try a different prompt from that point. See Iterate without rebuilding.
• Knowledge. Project settings → Knowledge holds standing notes the agent follows on every message.
• /test has the agent click through the preview like a user after a big change.

Smaller asks also cost fewer credits. For writing the prompts themselves, see how to write prompts for AI app builders; when something does break, how to debug an AI-built app.