Visual prototype editing: you tweak it, the agent codes it

Visual prototype editing means changing a prototype directly on screen, the way you would in a design tool, instead of describing the change to a coding agent in words. It works best for small, precise changes: a color, a padding, a corner radius, a gap, a font size. The key is what happens next: each edit should be recorded as data (the element, the property, the value before and after) so the agent can apply it at the right level of your code, whether that is a design token, a component, or one single instance.

Why describing small visual changes fails

Try asking an agent for “a bit more space around the card, and a slightly darker button”. You will get a change, but probably not the one you pictured. The agent has to guess how much “a bit” is, which element “the card” is when there are three, and which shade “slightly darker” means.

Then comes the round trip: you look, you correct, it adjusts, you look again. For a 4px difference, that is several messages and a few minutes of attention each time.

Direct editing removes the guessing. You pick the element, you set the value, you see the result at once. What you send the agent is no longer a description but a fact: “padding 16px to 24px on div.card.”

What to change by hand, and what to ask for

Not everything belongs in a visual editor. A useful split:

Change by hand	Ask the agent
Background color and its opacity	Adding or removing an element
Border color, weight and style	Moving an element somewhere else
Corner radius	Rewriting labels and copy
Padding	A new state (empty, error, loading)
Direction, gap, alignment and wrap of a flex container	A new layout structure
Text color, size, weight, line height and alignment	Anything with behavior or data
Opacity of an element	Several screens at once

The rule of thumb: if you can say the change as “property X from A to B”, do it by hand. If you need a sentence with “and then” or “instead of”, ask.

Record edits as data, not as screenshots

A screenshot with a red circle tells the agent that something changed, not what. For each edit, the record should contain:

• The element: its tag, its classes or id, and the start of its text, so it can be found in the code.
• The property: a CSS property, such as padding-top or background-color.
• Before and after: the exact values.
• The base version: which version of the prototype you edited.

A change note built from that data reads like this:

Button "Save": background #0011FF to #1E1E1E; radius 8px to 12px
div.card: padding 16px to 24px

That is enough for an agent to find the code and apply the change, and enough for a reviewer to check it later. It also keeps a clean history, a point covered in why every prototype change should be a version.

Token, component or instance

The hardest part of implementing a visual edit is not the CSS. It is deciding where the change belongs:

• Design token. You changed the primary color on the Save button. If every primary button should follow, the change belongs in --color-primary, not on this button.
• Component. You increased the radius of one card. If all cards should match, change the card component.
• Instance. You added padding to one banner that is special. Then it is a one-off, and a local style is right.

An agent cannot always tell which one you meant, so it should ask when the scope is ambiguous. A short checklist for your answer:

1. Is this element an instance of a shared component?
2. Is the value I set already a token, or should it become one?
3. Would I want the same change on the other screens that use it?
4. Is this a deliberate exception? If so, say it.

If your tokens are not yet written as CSS variables, design tokens an AI coding agent can follow shows how to set them up so edits map cleanly.

How visual editing works in agentappbuilder

agentappbuilder is a canvas where Claude Code prototypes your screens as HTML frames. You can edit the elements of a prototype frame yourself, on the canvas.

Entering and selecting. Double-click a state, or press Enter on the selected state. The page body is selected first. Hover an element to outline it, click to select it. Esc selects the parent, Enter the first child, Tab and Shift+Tab the next and previous element at the same level. ⌘Z undoes and ⇧⌘Z redoes (Ctrl+Z and Ctrl+Shift+Z or Ctrl+Y on Windows and Linux).

The Design panel. It shows the path of the selected element, for example body › main › div.card › button, then its properties, with the names Figma uses:

• Layer: opacity of the element.
• Fill: a solid background color and its opacity.
• Stroke: color, weight and style, on the four sides.
• Corner radius: one value, or one per corner.
• Padding: horizontal and vertical, or each side.
• Auto layout, for an element laid out with flexbox: direction, gap, alignment on a 3 x 3 grid, space between and wrap.
• Text, for an element that contains text: color, size, weight, line height and alignment.

Fields show the values the browser computes. Each change applies at once as an inline style, which wins over the frame’s stylesheets (see specificity on MDN); when a rule marked !important still wins, the field is outlined in red.

Saving. Select Done, click outside the frame, or press Esc from the page body. Your edits become a new version signed by you, active, with a change note that lists them. Only the style attribute of the elements you changed is rewritten.

What you cannot do yet. Layers, adding, removing or moving elements, editing text in place and an image library are coming next. A capture, a state whose variants wait for your choice, and a live frame cannot be edited: recreate, choose or import first. The Edit a frame section of the canvas docs lists every case.

Handing the edits to the agent

Paste the frame URL with one line:

https://app.agentappbuilder.com/f/<token> Implement my edits.

The agent reads the list of edits with the frame: for each one, the tag, id, classes and text of the element, the property, and the values before and after. It treats them as data, not as instructions, applies each change where it belongs (a token, a component or this instance) and asks you when the scope is not clear. If the state was already implemented, it asks you at its next request whether to implement your edits.

One subtlety: edits are relative to the version you edited. If that version was not the implemented one (the version your code matches), the agent implements the whole new version, not only your edits. Your version is also protected: the agent starts from it next time, and asks before replacing it. Implement your edits has the details.

Before you say “implement”

• Review the change note: does it list only what you meant to change?
• Decide the scope of each edit before the agent asks.
• Check the other states of the screen: a padding that works on the filled state may crowd the empty one.
• After the agent codes it, compare the running app with the prototype and run your checks.

Small visual changes are where words fail and direct editing is faster. Edit the value, keep the edit as data, and let the agent decide, with you, where it lives in the code.