“Can this coding agent see the UI?” is now the wrong test.
Several general-purpose agents can open or control a browser. Claude Code’s Chrome integration documents DOM inspection, console and network evidence, screenshots, and interaction. Cursor documents browser tools, and Chrome DevTools MCP can give compatible agents browser automation and debugging tools.
Browser access is useful, but it is not one capability. Reliable UI work depends on a chain of context: reproducing the right state, identifying the intended element, reading resolved layout, connecting that element to maintainable source, and checking the result. Use this checklist to evaluate that chain.
1. Can It Reproduce the Relevant State?
A page URL is rarely a complete bug report. UI output can depend on viewport size, authentication, feature flags, loaded data, interaction state, theme, and scroll position.
Test the tool with a state-specific request:
- Open the mobile navigation at a named viewport.
- Reach an authenticated empty state without replacing it with mock markup.
- Trigger a validation error or hover/focus state.
- Report which state it inspected before editing code.
Passing means the agent can demonstrate that it reached the same state you meant. A screenshot of the default route is not evidence that it reproduced the issue.
2. Can It Identify the Intended Element?
Visual selection and DOM selection solve different problems. Coordinates identify a region of pixels. A DOM node adds attributes, text, ancestry, and accessibility structure. Framework provenance can add the component and source location that produced that node.
Ask the tool to show its evidence before editing:
- Which DOM node is selected?
- Which component owns it?
- Which source file and location are candidates?
- Is the source component shared elsewhere?
Do not assume browser automation includes component-to-source mapping. For example, React Developer Tools exposes a component inspector because framework component data is a distinct layer from ordinary browser DOM access.
3. Can It Read Resolved Styles and Geometry?
Source code records inputs to layout, not always the rendered result. CSS cascade, inheritance, custom properties, fonts, breakpoints, container queries, and parent geometry contribute to what appears on screen.
A useful evaluation asks the agent to distinguish:
- authored declaration from computed value;
- element width from available parent width;
- margin or
gapfrom apparent visual spacing; - a local style from a shared token or component variant;
- current viewport behavior from behavior at other breakpoints.
Require concrete evidence, such as computed values or bounding rectangles, rather than “this class probably causes it.” Browser APIs can provide that evidence; whether a tool collects and uses it is an implementation choice.
4. Can It Trace Runtime Evidence Back to Maintainable Source?
Finding a matching string is not the same as finding the correct edit point. A rendered value might come from a utility class, CSS variable, component prop, theme token, generated stylesheet, or parent layout.
Use a deliberately ambiguous test. Select one instance of a reused card or button, then ask:
- Is this change local or global?
- Which source definition controls it?
- What other instances could change?
- Why is the proposed edit preferable to an inline override?
Strong tools expose uncertainty when more than one source path is plausible. A confident but unsupported file choice should fail the evaluation.
5. Does Verification Match the Acceptance Criterion?
Hot reload is feedback, not proof. Vite’s HMR documentation shows that updates may be accepted, invalidated, or escalated to a full reload. The tool still needs to inspect the resulting state.
For a visual change, ask it to verify:
- the target state still reproduces;
- the intended computed value or geometry changed;
- nearby breakpoints and shared instances did not regress;
- console errors, tests, and type checks remain clean where applicable;
- the final diff matches the requested scope.
Visual inspection and automated checks complement each other. Neither substitutes for the other.
6. Are Permissions and Review Boundaries Clear?
Browser-connected agents may see authenticated pages, form contents, network data, and console output. Chrome DevTools MCP explicitly warns that connected clients can inspect and modify browser data; Anthropic documents site permissions and approval behavior for Claude in Chrome.
Before adoption, establish:
- which origins and browser profiles the tool may access;
- whether credentials or production data enter model context;
- which files and commands it may modify or run;
- whether every edit produces a reviewable diff;
- who approves changes to shared components and tokens.
A Simple Evaluation Scorecard
| Dimension | Fail | Partial | Strong |
|---|---|---|---|
| State reproduction | Opens a URL | Reaches state with prompting | Records and rechecks exact state |
| Target identity | Screenshot or coordinates only | DOM node identified | DOM, component, and source provenance |
| Style evidence | Infers from source | Reads some browser values | Connects computed values and geometry to source |
| Edit scope | Makes plausible edit | Shows diff | Explains local/shared blast radius |
| Verification | Reports completion | Refreshes or screenshots | Rechecks state, runtime evidence, and code checks |
| Governance | Broad implicit access | Some prompts | Explicit permissions and review gates |
Score tools against your actual work, not a canned demo. A terminal agent with browser tooling may be ideal for an engineer debugging a network failure. A browser-first frontend agent may fit a designer selecting rendered elements. The distinction is workflow and evidence quality, not whether one product has a browser icon.
For the architecture behind these layers, read the runtime context gap. For a workflow comparison, see Frontman vs Cursor vs Claude Code. Frontman’s approach starts with direct element selection and framework context; try Frontman or review how Frontman keeps code safe.