Verifying an interface by eye, reading the code, is the experienced developer's temptation: the padding is obviously here, it will break on a narrow screen there. Naively it seems the visual result can be computed in the head from the source. On non-trivial layout this is self-deception: what the browser draws depends on too many layers to hold them all in mind, and the guess diverges from the picture.
Browser Preview closes this gap by tying the picture to the code. It opens your locally running app right in the IDE next to the code or in the system browser. Then the main thing: you can select a specific DOM element and send it to the agent as context, it appears in the prompt as an @-mention, and there can be several elements, while console errors attach to the agent's message automatically. A visual defect stops being words and becomes tied to an element and an error.
The mechanism works as a closed loop, and the order in it matters. First you run the dev server yourself and record the URL - the preview proxies your local server, not an imaginary one. Then you reproduce the error in the preview itself. You send the agent the selected element and the console output. You ask for a minimal diff for the specific defect. And you repeat the scenario, checking along the way the neighboring viewports where the same edit could have broken something else.
The naive move - I will describe the bug in words and ask for a fix - breaks on the ambiguity of description. "The button slides off" does not tell the agent which button, in what state, at what width and with what console error. The agent honestly fixes its guess about your description, not the observable defect. Preview removes this gap: instead of a retelling the agent receives the element itself and the error itself.
Why this is built as sending an element and an error rather than a text dialog. The precision of a fix is no higher than the precision of the defect's description. Words about layout are always poorer than the layout itself: state, context, DOM neighbors and the real console message are lost. By handing the agent the selected node and the console output, you raise the precision of the input to the precision of what you see - and the edit aims at the real defect, not at its verbal shadow.
The tool's boundaries are worth knowing in advance. Preview works with all agent types - Devin Local, cloud and ACP: the agent proxies your local server and receives the sent elements and errors. The listeners and the sending of elements and errors are best tuned in Chrome, Arc and other Chromium-based browsers; in others the behavior may be reduced. The preview itself can be turned off in settings so the agent does not launch this tool.
The cost of working by imagination instead of preview is concrete. A fix based on a made-up description proceeds toward the wrong target: the defect remains while the diff changes something neighboring and adds a regression. A check of "it seems even now" without a run in the browser misses a break at another width. Each such round is a spent iteration and tokens, because the entry into the task was poorer than the task itself.
You must verify the result the same way you set the task - in the preview itself, not in your head. Repeat the original scenario and confirm the defect is gone. Then look at neighboring states and widths: an edit that fixes one viewport often breaks another, and it is this step that separates "looks fixed here" from "fixed". The console should clear of the very error you sent, not merely show a different one.
The engineering sense is simple: preview turns the interface from an object of guessing into an object of observation. While a defect is described in words, both the framing and the check rest on your interpretation; the moment the real element, the real console and the real run are involved, both rest on fact. This is the case where it is cheaper to show once than to explain three times.
It is worth deliberately choosing the form in which the preview opens. It lives either as a tab in the IDE next to the code or launches in the system browser - the first is convenient for quick edit-check rounds, the second is closer to the user's real conditions with their extensions and devtools. And if the preview is not needed or not wanted, it is turned off in settings, and then the agent will not launch this tool: that too is a decision about boundaries, not only about convenience.
The typical failures are the same. The bug described in words - the agent fixed the wrong button. The dev server not started - there is nothing for preview to proxy, and the edit goes blind. Declared done on one viewport - on a narrow screen everything slid again. A non-Chromium browser taken - and you wonder why the element is not sent. The common sign: the interface was verified by imagination, not observation. Show the agent the element and the error, and look at the result by eye in preview at several widths - almost all of these failures are cut off.