You ask your coding agent to walk a signup flow, and it types back a tidy paragraph: "The email field lacks a visible label, the submit button is low contrast, and the confirmation screen has no clear next step." Useful. Then you close the tab, and the paragraph is gone. Nobody else saw it. There is no screenshot tied to any of those three points, and next week you cannot tell whether the button got fixed.
That is the core difference between a chat review and a durable annotated review. Both can surface real problems. Only one survives the session and travels to the person who has to act on it.
What a chat review is good at
A chat review happens inside the conversation with your agent. You point it at a screen or a preview, it reasons out loud, and you get back prose. It is fast and it is cheap. For a first pass on a rough build, it is often the right tool: you want a quick read on obvious problems before you invest in anything more formal.
Chat is also good at reasoning across a whole flow at once. Ask it whether the checkout has too many steps and it will count them and give an opinion. That is genuine value, and it is exactly the kind of thing running a usability test with your agent does well.
Where chat breaks down is durability and specificity. The output lives in a scrollback that gets truncated, cleared, or lost when the context window fills. It rarely ties a comment to an exact pixel. And it is invisible to everyone who was not in that session, which means your designer, your client, and your QA lead never see it unless you copy and paste it somewhere.
What an annotated review catches that chat misses
A captured review pins each comment to a still frame. You crop the signup screen, drop a numbered pin on the low-contrast button, and type or dictate exactly what is wrong. The comment and the pixel are now one object. Anyone who opens the link sees the same thing you saw.
This catches a whole class of problems chat glosses over. Alignment that is two pixels off. A hover state that only appears on one browser. A label that reads fine in isolation but collides with the field next to it. These are spatial problems, and prose alone describes them badly. "The button is misaligned" is a guess; a pinned screenshot of the button is evidence. If you have ever watched a developer fix the wrong element from a vague sentence, you know the cost. Pinning removes it, which is the whole point of pinning the exact spot a reviewer means.
The review also outlives the moment. On Publish it gets a short public URL, and the same content is available as a PDF, a Word doc, and clean markdown. Nothing evaporates when you close the tab. Come back in a week and the button comment is still there, and you can mark it resolved once it is fixed. That is the case for treating AI usability testing as something that produces a durable artifact rather than a chat you have to remember.
The dimensions that actually decide the choice
| Dimension | Chat review | Annotated review |
|---|---|---|
| Speed of first pass | Fastest | A few extra minutes to capture and pin |
| Ties a comment to an exact spot | Rarely | Numbered pins on the still |
| Survives the session | No, lives in scrollback | Yes, saved at a public URL |
| Other people can see it | Only if you copy it out | Anyone with the link |
| Feeds an agent to fix it | Already in chat | Markdown export the agent reads |
| Track what got fixed | No state | Mark each comment resolved |
Notice chat wins the top row and the annotated review wins the rest. That is not a knock on chat. It is a statement about what each is for. Chat is a fast reasoning pass. An annotated review is a record other people act on.
Use both, in order
The two are not rivals. The clean sequence is chat first, capture second. Let the agent do its fast reasoning pass and surface candidate problems. Then walk the flow yourself, capture the screens the agent flagged, pin the exact spots, and publish. Now you have a checked, durable review instead of a paragraph you hope you remember.
That published review then feeds right back to the agent. The markdown export at /r/<slug>/markdown is the format a coding agent reads cleanly, so you can hand the whole review to Cursor or Claude Code as a task list instead of retyping findings. The loop closes: agent reasons, you capture, agent fixes, you mark resolved.
If your reviewer is a person rather than an agent, the annotated version matters even more. A client or a designer will never read your agent's scrollback, but they will open a link and comment on it. That is why client feedback almost always wants the durable form.
Start with whichever is faster for the question in front of you. When the answer needs to reach anyone but you, or needs to still exist tomorrow, capture it into a review before you close the tab.