Interface work sets the agent a task that does not exist in pure code: the result has to be seen. The browser can open the application, interact with it and return visual evidence. Canvas assembles an interactive artifact next to the conversation. And design mode inside the browser hands the agent the selected element together with a screenshot and component data. Three different ways to close the loop on observable state rather than on a retelling, and they differ in what the evidence is bound to: the live application, a separate artifact or a specific node of the markup.

The naive request sounds familiar: make the button prettier. It fails not because the model does not understand aesthetics but because there is neither a point of application nor a criterion in it. The agent has to guess which button is meant and what counts as better, and any reading it picks will be someone else's. Then begins a search through variants that costs more and takes longer than one precise formulation. Checking your own request is easy: if it cannot tell you which change counts as done and which does not, there will be nothing to judge the result by either.

Design mode closes exactly that hole. It hands over data rather than words: the path to the element, its attributes, computed styles, the component's props from the tree and the visual surroundings. You can select one element or several, outline an area on a frozen frame and add a spoken description. The difference is fundamental: the agent gets an exact address and the current state instead of a natural-language description where every word can be read two ways. The computed styles matter most here - they show what actually applied to the node after all inheritance and overrides, not what is written in the source file.

It helps to state the visual loop in full once, because a step is easy to skip in it. The development server is up, started by the project's reproducible command. An exact element or area is selected, not the whole page. The request describes a measurable state: spacing, alignment, overflow, contrast. Both a wide and a narrow viewport are checked. After the change a screenshot or a recording is taken. And the diff contains no accidental edits scattered across the whole design.

That last item of the loop is the most underestimated. Design changes spread easily: an edit to one component touches shared variables, and those touch half the interface. The mechanism is the usual one for design systems: a value looks local until it turns out that another dozen places refer to it. That is why a visual task ends not with a screenshot but with a look at the diff: it shows whether the change stayed local or you have just changed spacing across the entire application.