Bolt.new: try changes on the page before sending the batch to AI
Bolt.new is a browser-based AI app builder that turns requirements into runnable websites and apps. Visual Edits lets users adjust text and styles in a preview, inspect a batch of changes, then save it to code.
Form your own approach first, then explore the reasoning to check trade-offs and validation you may have missed. There is no single right answer.
How can a pending batch make unsaved work understandable?
Scenario
Design the pending-changes experience for your own AI page editor. An author changes an event-page heading from 24 to 32 and then 28, turns a button from gray to blue, and edits registration instructions below the viewport. Changes appear immediately in the preview, but project code updates only when the whole batch is submitted. You do not need to reproduce Bolt.
Known conditions and constraints
- A page has three distinct objects: preview state, the pending batch and saved code. Only text, font size and color can change; layout dragging is outside scope. Users may restore an original value or remove a change.
- Only submission sends the batch to the model; previewing sends no model request. Processed output still needs inspection. A changed preview or sent request must not be displayed as saved code.
- The author may switch pages with unsubmitted changes. Design the differences between staying, submitting before continuing, and discarding before continuing. Do not merge changes across pages automatically.
- Each list item must locate its original element. Registration instructions outside a narrow viewport may still be pending; the visible page alone does not establish the batch’s scope.
Start with this sequence
The author makes those changes, removes the button-color change, then tries to open another page. Later they return and submit. After processing, the heading wraps poorly at a narrow width. Explain what can be confirmed and recovered before leaving, during processing and after completion. Do not promise individual saved-code rollback that the product does not support.
Deliverables
Sketch four states: previewing, the leave-page prompt, batch processing and results awaiting inspection. Specify batch entries, save feedback and leave-page copy. Compare automatically submitting before leaving with requiring an explicit choice. Propose two observation tasks that test whether users discover offscreen changes and distinguish preview from code. Describe the study without inventing completion rates.
Explore the reasoning
- Connect the three states. Element markers and list entries identify the same object; show original values and current intent. Restoring the baseline should remove the pending difference. A count of historical actions is not a count of changes to submit.
- Make the cost of leaving explicit. Automatic submission reduces interruptions but can consume allowance and commit forgotten work. An explicit choice adds a step while permitting scope inspection. Explain what discarding affects and what submitting means; avoid a vague Confirm label.
- Separate a request from its result. Show the batch scope during processing and offer inspection afterward. Narrow-width wrapping is a result-checking issue. Model completion does not establish page correctness. Explain recovery according to real capabilities: a whole-batch version or another edit.
- Use two tasks that expose confusion. Ask users to find the offscreen registration edit before leaving, then inspect the narrow heading after processing and state whether code is saved. Observe where they look and which state they mistake for completion before revising markers, the list and feedback.