Published · Updated in Product systems
How to iterate without breaking the rest of your app
Author: Mythos team
Make one clear change at a time, protect the behavior that already works, and check the nearby paths most likely to be affected.
Quick answer
The safest revision has one clear outcome. Describe what happens now, what should happen instead, what must remain unchanged, and how someone can confirm the result. Then test the changed flow and the nearby areas that share its information, navigation, access rules, or visual pattern.
Mythos keeps the current Preview available while a Build prepares and checks a new version. The new version becomes current only after delivery succeeds. If it does not, the previous version stays in place. Use History to compare earlier versions and Revert when restoring one is safer than adding another fix.
Why a small visual request can spread
A request may mention one button even though the same behavior appears on several pages, affects saved information, changes navigation, or looks different on mobile. Forcing the work into one visible element can hide the real cause. Redesigning the whole feature can create the opposite problem.
Map the nearby behavior before requesting the change:
| Area | Questions |
|---|---|
| User states | What should signed-out, empty, loading, error, and success states show? |
| Repeated patterns | Does the same control or layout appear elsewhere? |
| Navigation | Should refresh, Back, copied links, and bookmarked pages still work? |
| Saved information | Could the change lose, duplicate, or overwrite someone’s work? |
| Access | Do different roles see or use the same action? |
| Mobile | Does the control move, wrap, or disappear on a narrow screen? |
| Versions | Are there unsaved edits or an earlier version currently open? |
This map is not a reason to redesign every connected area. It identifies the few nearby behaviors that deserve a check. The change itself should remain focused on the real problem.
Describe the change, not a redesign
Separate the request into four parts:
- Current: what happens now and where it happens.
- Desired: what the user should observe after the change.
- Keep: what must continue working as it does today.
- Check: steps that prove more than a convincing screenshot.
Use this template:
Change: keep the selected project tab in the page link.
Current:
On /projects/123, switching from Overview to Activity changes the panel, but
refresh returns to Overview.
Desired:
Selecting Activity updates the page link. Refresh, Back, Forward, and a copied
link reopen the same valid tab. An unknown tab returns safely to Overview.
Keep:
- current project information and access rules,
- current tab labels and desktop styling,
- other information already present in the link,
- mobile access to every tab.
Check:
- default, valid, and invalid tab links;
- refresh, Back, and Forward;
- keyboard navigation;
- a narrow mobile screen;
- another page that uses the same tab pattern.
For a bug, include the shortest reliable reproduction. For visual work, name the reference and screen size instead of using subjective words such as “premium.” For copy, provide the exact text and where it belongs.
Use a six-step iteration loop
1. Save or discard direct edits
The Mythos workspace editor saves only when you choose Save or press Ctrl+S; there is no autosave. Save intentional work before switching versions or starting a Build. Saving directly does not start or charge an AI Build.
2. Reproduce from a stable state
Record the page, account role, screen size, input, and current result. If the issue appears in an earlier Preview, note that version. If you cannot repeat the problem, treat the cause as a hypothesis.
3. Define one outcome
Write the current behavior, desired result, and what must remain unchanged. Use Plan if an important product decision is still open. Use Build when the expected result and checks are already clear.
4. Review the new version
Check the user-visible behavior first. Confirm that the change solves the named problem instead of hiding it with sample data, a disabled action, or an unrelated redesign.
5. Check nearby behavior
Repeat the changed path, the closest shared areas, and one error or denied-access case. Test what is connected to the change, not every page by default.
6. Record what happened
Keep the tested version, steps, result, and known limitations. The next revision should begin from evidence rather than memory.
Build a regression ring around the change
A useful checklist stays small enough to repeat after every revision:
| Area | What to test | Example for a tab-link change |
|---|---|---|
| Direct result | The requested behavior | Select Activity; the link and visible panel agree |
| Return visit | Reload or reopen the page | Refresh restores Activity |
| Navigation | Entry and exit behavior | Back, Forward, and copied link work |
| Repeated pattern | One other place using the same pattern | Settings tabs still switch correctly |
| Error or denied state | Invalid input or a role without access | Unknown tab returns safely; a restricted project stays restricted |
| Mobile | The main narrow-screen path | Every tab remains reachable without covering content |
| Accessibility | Keyboard use and clear status | Focus follows selection and the active tab is understandable |
Add multi-user checks when people can edit the same information. For a form, test empty, invalid, failed, and successful submissions without losing valid entries. For a sensitive action, test with an account that lacks permission and use every available path—not only whether the button is hidden.
Do not run every possible test for a label correction. Expand the checklist only when the changed behavior is reused more widely or affects important information and access.
Use History for inspection and recoverable change
Opening an earlier Preview is read-only. It does not change the current app or erase later work. Use it to answer questions such as “when did this stop working?” and to compare a known-good experience with the current one.
Revert is a separate action. It takes the selected earlier version and creates a new current version from it. The versions created after the selected one remain in History, so the team can still inspect what happened.
Before reverting:
- save or discard intentional editor changes;
- confirm the version and behavior you expect to restore;
- inspect the earlier Preview instead of assuming it is correct;
- identify which later improvements will not be present in the restored result;
- test the restored flow and anything important that changed afterward.
Use Revert when returning to a coherent earlier state is safer than diagnosing under pressure. Use a focused Build when the current version contains valuable later work and the defect is understood. Version history documentation explains the behavior.
Choose direct editing for deterministic changes
Not every revision needs an AI request. If you know the exact text or code change and can check the result, the built-in editor is often the shorter path. Save is explicit, there is no autosave, and saving directly does not use a Build charge.
Direct editing is useful for:
- an exact copy or design-token change;
- a small condition whose correct result is already known;
- clear cleanup with an obvious expected result;
- finishing a partly written file when the checks are clear.
Use Build when the change crosses several parts of the app or benefits from Mythos inspecting the project and checking a complete new version. Use Plan when the product decision is still open.
Earlier versions are read-only. Return to the current version or choose Revert before editing. This keeps comparison separate from changing the app. Workspace editor documentation covers saving and earlier versions.
Use GitHub as an ownership and comparison boundary
After a project has completed a Build, Mythos can create a new private GitHub repository under the account or organization you choose. Mythos synchronizes the selected branch in both directions and leaves other branches alone until you select one. If Mythos and GitHub contain incompatible changes, the product shows a conflict instead of silently replacing either version.
GitHub gives developers an independent place to:
- review the delivered files without relying on the original prompt;
- create a separate branch for human changes;
- run the project in a clean checkout;
- compare code, dependencies, and configuration;
- keep the repository if Mythos is later disconnected.
Synchronization can take time. Check the latest commit on both sides instead of assuming the trees match because the interface updated quickly. The GitHub handoff guide provides a complete exit test.
Where this loop needs stronger controls
A focused Build and a nearby-behavior checklist are not enough for high-risk changes. Sign-in, access control, payments, destructive data changes, secrets, actions in outside services, and compliance controls need stronger evidence and often an independent reviewer.
Version history helps recover source changes, but it is not a database backup and cannot undo everything an app already did. Reverting code cannot unsend an email, reverse a captured payment, or restore information deleted from another service.
Avoid combining unrelated cleanup with a user-visible fix. A wider redesign may be justified when the underlying problem is structural, but name that choice and test the wider effect. Otherwise keep the revision focused and leave unrelated working behavior alone.
FAQ
How small should one Build request be?
Small enough to describe one coherent result and a short success checklist. It may still change several files when that is necessary to solve the real problem. Do not split one important data or access change into unsafe half-steps.
Should I say “do not change anything else”?
Name the exact behavior that must remain unchanged. Mythos may need to update a shared part of the app to fix the real cause, so a blanket instruction is difficult to verify. “Preserve current sign-in behavior and unrelated pages” is clearer.
What happens to the current Preview while a Build runs?
It remains available. The new version becomes current only after successful checks and delivery; otherwise the previous version stays current.
Can I edit an old version directly?
No. Earlier versions are read-only. Inspect one or use Revert to make it the basis of a new current version, then edit that version.
Does Revert delete later versions?
No. It creates a new current version from the selected earlier version and keeps the later History available.
When should I use a Git branch instead?
Use a separate branch for independent experiments or developer review. Mythos synchronizes only the branch you select and leaves other branches untouched until you choose one.
Sources
Current Mythos documentation used for this guide:
