How to give a coding agent useful visual feedback
Pointing is only the start. A coding agent needs to know what you saw, what should change, what must stay unchanged, and how you will judge the result.
Visual feedback for a coding agent is a human judgment attached to enough page and implementation context for the agent to find, change, and verify the right part of a running interface. The useful unit is not a screenshot or a selector by itself. It is a review task with intent, evidence, constraints, and a checkable result.
The six-part feedback packet
- Target: the route, state, viewport, and element you are discussing.
- Observation: what is visibly wrong now, without guessing at the cause.
- Intent: why the change matters to the person using the interface.
- Requested change: the specific outcome you want, in plain language.
- Constraints: behavior, copy, design tokens, breakpoints, or flows that must remain intact.
- Acceptance: what the agent should test and what you will inspect visually afterward.
Turn “that button looks wrong” into an implementable task
Vague: “The button on the left looks wrong. Make it better.”
Useful: “On /checkout at 390px wide, the primary ‘Pay now’ button wraps beneath the total and becomes narrower than the form. Keep the label and click behavior. Make the button span the form width below the mobile breakpoint, preserve the desktop layout, and verify keyboard focus remains visible.”
The second version separates visual judgment from implementation choice. It gives the agent a target and a test without pretending the reviewer already knows which CSS rule should change.
Use a human-in-the-loop review cycle
- The coding agent starts the app, implements the feature, and runs the existing tests.
- A person reviews the real UI at the relevant routes, states, and viewport sizes.
- The review tool records the marks, screenshot, element, route, browser context, and nearby errors that are available.
- The agent reads the packet, inspects the repository, makes the smallest supported change, and tests again.
- The person reopens the running UI and decides whether the visual intent has been met.
Shiproom performs the middle transport step. It does not critique the design, choose the change, read the repository, edit code, or decide that the result is correct.
Choose the capture method by who is reviewing
You are sitting with the coding agent
A native agent browser, screenshot, local annotation extension, or direct prompt may be enough. Keep the loop local when nobody else needs access.
A client or teammate needs to review your local app
Use a private browser link that reaches the running app and captures feedback in place. A raw tunnel solves reachability; a review surface also records and returns the evidence.
The site is already deployed and review is ongoing
A broader website-feedback suite may fit better when you need a permanent widget, formal UAT, a client task board, deadlines, approvals, session replay, or many project integrations.
A review rubric worth reusing
- Visual hierarchy: can a person tell what matters first?
- Responsive behavior: does the task work at narrow, medium, and wide viewports?
- Content: is the copy specific, accurate, and complete in every state?
- Interaction: do keyboard, pointer, loading, empty, error, and success states make sense?
- Accessibility: are semantics, labels, focus, contrast, motion, and target sizes preserved?
- Regression risk: what neighboring component or route must not change?