Bolt.new: try changes on the page before sending the batch to AI

Build an app with language, then make small changes on the page

Bolt.new is an AI app builder in the browser. Describe a requirement to get a runnable project, inspect and edit its code, ask for further changes, then publish a website or app. It helps move an idea toward an interactive prototype, beyond a static mockup.

Once the first version exists, requests often become specific: enlarge this heading, use the brand color on that button, replace the subtitle. Rephrasing every small change as a prompt turns a visual decision into a writing task. Visual Edits, introduced on September 3, adds a direct interaction for this stage.

Select a specific object in the first draft

Imagine an introduction page for a community repair event. It already runs, but you want a larger heading, a different button color and a revised subtitle. In Visual Edits, use Select to point to an element, then adjust its properties.

Selection answers where, controls set specific values such as font size and color, and prompts remain available for broader layout requests. The toolbar is not a free-form layout editor. Knowing which changes each entry supports reduces repeated guessing about what a vague instruction targets.

Turn local experiments into a reviewable batch

1. Inspect the preview. After changing the heading or button, check the visual hierarchy. A visible change does not mean code has been saved.
2. Add it to the pending batch. Use Add changes to collect edits and continue with other objects. The guide describes page-based batches, element marks and a count of pending changes.
3. Remove unwanted experiments. The announcement explains that changing the same element updates its existing edit, while removing an item restores the preview. The list should represent the final changes you want, not every intermediate attempt.
4. Save together. Save changes lets Bolt process the batch and update project code. Preview adjustments are free; saving uses model tokens, the processing units counted toward usage. Inspect the scope at this point.

The author can judge the heading, copy and button together before submitting the decision. A batch gives experimentation a place to pause, not simply a way to click Send less often.

Check saved results and understand recovery scope

After saving, inspect content and behavior, then use responsive preview to check narrow layouts and wrapping. Finished model processing does not mean every page state has been verified.

Unsaved changes can be removed individually. A saved item currently cannot be undone on its own; project history restores the whole batch. Mixing unrelated edits into a large batch increases what must be considered during recovery. Organizing the intended changes before saving gives later checks and recovery a clearer scope.

Let selection identify the object and controls specify the value

“That blue button above” may be obvious to a person but refer to several elements for a model. Clicking fixes the target; controls express exact values such as font size and color; a prompt field remains for open-ended requirements. This division reduces the need to describe a target that is already known.

Color choices also use the current page as context. The launch article says presets come from the rendered page, and element names use more familiar language. An event-page author can recognize colors to reuse rather than guess a new value in an empty palette. It offers a recognizable starting point; the designer still judges suitability and contrast.

The lesson is to assign different kinds of expression to suitable inputs: selection answers “where,” a control answers “exactly how much,” and language answers “why and what else.” Clearer objects and intent make later confirmation easier to focus on the same change.

A pending batch separates trying from committing

When someone changes a button color repeatedly, they usually want the final choice rather than every intermediate experiment executed in sequence. Bolt’s launch explanation describes updating an existing change when the same element is edited again, and restoring the preview when an item is removed.

A batch therefore does more than combine several requests. It turns tentative exploration into a set of intentions that can be inspected, reduced and submitted together. The event-page author can view the heading and button together, judge their hierarchy, then save.

That also makes state communication necessary. A change in the preview, an item in the pending list and code produced by the model occupy different stages. If the page already looks changed but pending status is unclear, users may assume they can safely leave. The official guide uses element markers and a batch count to expose unsubmitted work, and organizes batches by page.

The useful boundary is to allow inexpensive experimentation while making scope visible before submission. Larger batches need a way back to individual targets for inspection. The convenience of one submission should not silently include a change its author has forgotten.