Claude Code writes frontend changes fast, and it writes them to satisfy what it can see: the diff compiles, the types check, the test you asked it to update passes. What it can't see is your users. It doesn't know that the button it just moved carries most of your checkout completions, or that returning users reach for the old layout from muscle memory. That gap between "the code is correct" and "the product still works the way people expect" is where agent-authored frontend changes quietly go wrong.
None of this is specific to Claude Code. Any coding agent has the same blind spot, because none of them are looking at session recordings while they work. But Claude Code changes frontend surfaces often enough, and confidently enough, that it's worth a checklist you actually run before every merge rather than a habit you mean to build.
Read the diff for intent, not just correctness
Before you run anything, read what changed and ask what it was supposed to change. Claude Code is good at satisfying the literal instruction and less reliable at flagging what else moved along with it: a class name that also drove a CSS selector elsewhere, a prop default that silently changes behavior for every caller that didn't override it, a component it "cleaned up" that had an event handler doing something non-obvious.
Look specifically for:
- Renamed or removed
data-testid,id, oraria-*attributes. These are load-bearing for both your tests and your users' assistive tech, and an agent will rename them for readability without knowing anything points at them. - Conditional rendering that changed. A loading state, an empty state, or an error state that used to render and now doesn't (or vice versa) is a common agent side effect when it's refactoring for the happy path.
- Anything touching layout, spacing, or ordering near an element you didn't ask it to touch. Agents tend to over-fix the surrounding code once they're in a file.
Run it in a real browser, not just the test suite
A green test suite tells you the behavior you thought to test still works. It says nothing about the behavior you didn't think to test, which is most of what your users actually do. Pull the branch and click through the flow the change sits in, not just the specific element it touched.
- Test the full flow, not just the changed component. If the change is inside checkout, run checkout start to finish.
- Test with the states that are easy to forget: empty state, slow network, a user who's mid-flow and refreshes, a user on the smallest supported viewport.
- Test keyboard-only and with a screen reader on anything interactive. Claude Code doesn't drive a screen reader while it works, and semantic regressions in agent-authored markup are common enough to check for by default.
Diff the visual output, not just the code
Frontend changes can be correct at the code level and wrong at the pixel level: a spacing token that resolved differently than expected, a component that now wraps at a breakpoint it didn't before, an icon that's slightly the wrong size next to text. If you have visual regression tooling (Chromatic, Percy, Playwright's screenshot assertions, or similar), run it on the PR. If you don't, take a screenshot of the affected screen before and after and look at them side by side for longer than you think you need to.
A clean pixel diff isn't proof nothing broke, though — it only rules out one category of regression. See visual regression vs. behavioral regression for the failures that pass a screenshot diff clean.
Check what depends on the thing that moved
Before merging, ask what else in the product points at the element the change touched. A button that got restyled might also be:
- The target of an onboarding tooltip or product tour step that references it by selector.
- The element a support macro or help doc screenshot shows.
- The step a returning user's saved habit is built around, even if nothing in the code formally depends on it.
None of this shows up in a code diff, because none of it lives in the code. It lives in how people actually use the product, which is exactly the layer an agent working from the repo alone can't see.
Treat the PR description as a claim, and check it
Ask Claude Code to describe what it changed and why, then treat that description as a claim to verify rather than documentation to trust. Agents are accurate about the mechanism of a change ("moved the submit button into the sticky footer") and much less reliable about its consequences ("this shouldn't affect anything else"). The second half of that sentence is the part worth checking yourself, every time, especially on a surface you didn't specifically ask it to touch.
If someone else is the one signing off on the PR, reviewing AI-generated frontend PRs covers the same claim-versus-evidence problem from the reviewer's side of the table.
Why this matters more as more of the frontend is agent-written
The failure mode described here has a name: unclaimed surface. It's closely related to what happens when tests, review, and visual diffs all pass and the interface still stops working for someone who already knew how to use it — see what tests don't catch when AI rewrites your interface for that category named precisely.
The agent describes its intent accurately and the side effects don't get mentioned at all, not because it's hiding anything, but because it genuinely doesn't have visibility into which elements your users depend on and how heavily. Your test suite has the same blind spot for the same reason: it checks the behavior someone thought to write a test for, not the behavior your users have actually built habits around.
That's the gap UXSense measures directly. It builds a behavioral load map from your real recorded sessions, so a pull request check can tell you when a change touches an element that carries real user load, whether or not the PR description mentions it, and whether returning users interact with it the way regulars do. It's not a replacement for the checklist above. It's what catches the thing the checklist can miss because a human reviewer, like the agent, is working from the diff and not from what your users actually do.
Your tests check your code. Nothing checks your users, until something does.