Use AI to review frontend behavior beyond the screenshot

A generated page matches the design image closely. The Save button submits twice, the modal loses focus, and a slow response restores data from a previous account. None of those defects appears in the screenshot used to approve the interface.

Visual review is useful but incomplete. A frontend's behavior includes semantics, state transitions, network timing, and recovery. This article uses an illustrative account settings page to build an evidence-based review workflow in which AI helps find cases while the engineer verifies the actual interaction.

Start with the intended journey

Describe the user task: open settings, edit a display name, save, receive confirmation, and continue without losing unsaved changes. Include account switching, permission denial, and failed save behavior if they belong to the product.

Write the key invariants. Saving should send one intended request. The target account should come from trusted application context. A failed save should preserve editable input. A response for a previous account should not update the current screen.

Give the assistant these invariants before asking for a review. Without them, it may focus on spacing and component extraction while missing the user's actual goal. The review should follow what people need to accomplish, not only what the page looks like.

Inspect native semantics and accessibility

Identify the rendered elements for buttons, links, inputs, and dialogs. A clickable div may look like a button but lack native keyboard behavior. A toolbar button inside a form may submit unless its type is explicit.

Check labels and accessible names. Placeholder text alone is not a durable field label. Icon-only controls need a name describing the action. Error messages should be associated with the affected field where the implementation requires that relationship.

Trace focus through opening a modal, receiving async content, displaying validation, and closing. An assistant can list likely issues from the code, but browser and assistive-technology checks establish the actual behavior. The guide on async modal accessibility covers those transitions in detail.

Review network behavior under delay

Inspect requests rather than assuming one click equals one operation. Double clicks, effect reruns, and automatic retries can create duplicate work. Check request payloads, statuses, and what the page treats as success.

Use controlled delays to test account switching and overlapping saves. Complete an old request after a newer one and verify ownership of data, errors, and pending state. A fast local mock can conceal these defects.

Distinguish transport failure from application rejection. A server denial should not become a generic retry loop. A successful HTTP response may still carry an application failure according to the endpoint contract. Review the real response shape and the client's interpretation together.

Examine state transitions beyond the happy path

List idle, dirty, submitting, success, failure, and stale-result states as appropriate. Check whether separate flags can produce impossible combinations, such as a success banner and a current error at the same time.

Verify input preservation. If a user edits the name while a save is pending, the response should not blindly overwrite the new draft unless that is the explicit contract. The page can distinguish submitted revision from current edits.

Test empty and partial data. A missing optional profile field should not crash the form. A supplementary API failure should not hide all settings if the essential data remains usable. State presentation should reflect which part of the journey is actually blocked.

Check responsive layout as an interaction issue

Use supported narrow widths and zoom. Look for clipped buttons, inaccessible local scroll regions, overlapping labels, and content that extends beyond the viewport. A global overflow rule can hide a layout defect without making the controls usable.

Use long synthetic names, identifiers, and translated labels where relevant. Short sample text often makes a layout appear more resilient than it is. Test the same controls by keyboard so focus indicators are not clipped.

Review touch targets and visible feedback according to the project's accessibility and design requirements. Avoid inventing a universal pixel rule without reference to the applicable standard. The useful finding identifies a concrete control that users cannot operate or understand in the tested context.

Ask AI for concrete counterexamples

Provide the component, request helper, and relevant styles along with the journey. Ask the assistant to propose a specific action sequence that breaks each invariant. Require file and symbol references for code findings.

An illustrative request is: “Review this settings page beyond its screenshot. Find a keyboard sequence, network completion order, or error response that violates the stated journey. Separate demonstrated issues from hypotheses. Do not infer server authorization from hidden UI controls.” This produces checkable review candidates.

Verify each proposed issue. The assistant may miss behavior supplied by a shared component or assume a handler sends a request when it only updates local state. A hypothesis becomes a finding when the actual path or a controlled test establishes the consequence.

Make fixes and evidence proportional

Correct the smallest demonstrated defect. An explicit button type can fix accidental submission. A request ownership guard can fix stale updates. A focus-preserving dialog branch can fix an async transition. Do not rewrite the entire state library to address one local problem without evidence.

Add focused regression coverage for consequential behavior. A test should demonstrate the failing sequence and assert the user's outcome, not only a helper invocation. Keep manual browser checks for interactions that automated unit tests do not establish.

Record the verification environment and remaining gaps. A desktop keyboard check does not prove all mobile or screen-reader combinations. A mocked API does not prove deployment authorization. The review conclusion should be specific enough that another engineer knows what was actually checked.

Keep screenshots as one useful artifact

Retain visual comparisons for layout, hierarchy, and content. They are valuable evidence for those properties. Pair them with interaction steps, request traces, and state assertions for the properties screenshots cannot show.

After a correction, repeat the original journey and at least the failure sequence that motivated it. If a toolbar fix changes Enter submission or an ownership fix suppresses current results, the review should catch that regression before acceptance.

A productive AI-assisted frontend review combines the assistant's ability to enumerate cases with the engineer's responsibility to verify them. The result is an interface that looks coherent and behaves coherently when users type, wait, fail, retry, navigate, and use the keyboard.

Sources

GitHub Copilot best practices discusses reviewing and validating suggestions.

React: State as a Snapshot explains state values used by handlers.

MDN: button element documents native control behavior.