Keep AI revisions inside a useful budget

Avoid turning a repair into new scope

A broken save button is a defect against the original brief. Adding a calendar is new scope. Write those on different lists so a repair session does not grow into a redesign. Ask for one coherent change at a time and state what should remain unchanged. This makes an unexpected regression easier to locate and gives you a clearer record of why credits were consumed.

Preserve a known useful version

Before a meaningful revision, keep the current brief, screenshots of relevant behavior and any available export or supported version reference. Confirm what the platform can actually restore. A version label alone may not cover records, external services or settings. Do not treat application-code recovery as a promise to reverse every side effect produced during a test.

Set a revision limit and mitigation plan

Choose a maximum spend and a short list of essential tasks. If repeated changes do not improve the same failing task, pause and narrow the diagnosis. Record the error and the last known working step. Continuing to issue increasingly broad prompts can make the cause less clear. This recommendation does not depend on a particular vendor having a built-in spending cap.

Review the outcome rather than the activity

At the end of a session, compare the current app with the acceptance criteria. Count verified working journeys, not messages, generations or attractive components. Decide whether to deepen the same narrow workflow, ask for technical review or select an existing product instead. A stopped experiment can still be useful if it answers a real suitability question without consuming the entire project budget.

• End each revision with a short note: what changed, what still works, what failed and how much allowance remains. This makes the next decision evidence-based instead of another speculative prompt.