Проверять интерфейс на глаз, читая код, - соблазн опытного разработчика: тут очевиден отступ, там сломается на узком экране. Наивно кажется, что визуальный результат можно вычислить в голове по исходнику. На нетривиальной верстке это самообман: то, что рисует браузер, зависит от слишком многих слоёв, чтобы держать их все в уме, и догадка расходится с картинкой.
Browser Preview закрывает этот разрыв, связывая картинку с кодом. Он открывает ваше локально запущенное приложение прямо в IDE рядом с кодом или в системном браузере. Дальше - главное: можно выбрать конкретный DOM-элемент и отправить его агенту как контекст, он появится в промпте как @-упоминание, и элементов может быть несколько, а console errors цепляются к сообщению агента автоматически. Визуальный дефект перестаёт быть словами и становится привязанным к элементу и ошибке.
Механизм работает как замкнутый цикл, и порядок в нём важен. Сначала вы сами запускаете dev server и записываете URL - preview проксирует именно ваш локальный сервер, а не воображаемый. Затем воспроизводите ошибку в самом preview. Передаёте агенту выбранный элемент и console output. Просите минимальный diff под конкретный дефект. И повторяете сценарий, проверяя заодно соседние viewport, где та же правка могла сломать другое.
Наивный ход - опишу баг словами и попрошу починить - ломается на неоднозначности описания. "Кнопка съезжает" не говорит агенту, какая именно кнопка, в каком состоянии, при какой ширине и с какой ошибкой в консоли. Агент честно чинит свою догадку о вашем описании, а не наблюдаемый дефект. Preview убирает этот зазор: вместо пересказа агент получает сам элемент и саму ошибку.
Почему это устроено как передача элемента и ошибки, а не как текстовый диалог. Точность починки не выше точности описания дефекта. Слова о верстке всегда беднее самой верстки: теряются состояние, контекст, соседи в DOM, реальное сообщение консоли. Отдавая агенту выбранный узел и console output, вы поднимаете точность входа до точности того, что видите, - и правка целится в настоящий дефект, а не в его словесную тень.
Границы инструмента стоит знать заранее. Preview работает со всеми типами агентов - Devin Local, облачными и ACP: агент проксирует ваш локальный сервер и получает переданные элементы и ошибки. Слушатели и передача элементов и ошибок лучше всего отлажены в Chrome, Arc и других браузерах на Chromium; в прочих поведение может быть урезано. Сам preview можно и выключить в настройках, чтобы агент не запускал этот инструмент.
Цена работы по воображению вместо preview конкретна. Починка по домысленному описанию проходит по неверной цели: дефект остаётся, а diff меняет что-то соседнее и добавляет регресс. Проверка "кажется, теперь ровно" без прогона в браузере пропускает поломку на другой ширине. Каждый такой круг - потраченная итерация и токены, потому что вход в задачу был беднее, чем сама задача.
Проверять результат нужно тем же способом, каким ставили задачу, - в самом preview, а не в голове. Повторите исходный сценарий и убедитесь, что дефект ушёл. Затем посмотрите соседние состояния и ширины: правка, чинящая один viewport, часто ломает другой, и именно этот шаг отделяет "выглядит починенным здесь" от "починено". Консоль должна очиститься от той ошибки, которую вы передавали, а не просто показать другую.
Инженерный смысл прост: preview превращает интерфейс из предмета догадок в предмет наблюдения. Пока дефект описан словами, и постановка, и проверка держатся на вашей интерпретации; как только к делу подключены реальный элемент, реальная консоль и реальный запуск, обе опираются на факт. Это тот случай, когда дешевле один раз показать, чем трижды объяснить.
Стоит осознанно выбрать и форму, в которой открывается preview. Он живёт либо вкладкой в самой IDE рядом с кодом, либо запускается в системном браузере - первое удобно для быстрых кругов правка-проверка, второе ближе к реальным условиям пользователя с его расширениями и devtools. А если preview не нужен или нежелателен, его отключают в настройках, и тогда агент не станет запускать этот инструмент: это тоже решение о границах, а не только об удобстве.
Типичные провалы одинаковы. Баг описали словами - агент починил не ту кнопку. Не запустили свой dev server - preview проксировать нечего, а правка идёт вслепую. Признали готовым по одному viewport - на узком экране всё поехало снова. Взяли не-Chromium браузер и удивились, что элемент не передаётся. Признак общий: интерфейс проверяли воображением, а не наблюдением. Показать агенту элемент и ошибку, а результат смотреть глазами в preview на нескольких ширинах - почти все эти провалы отсекаются.