How to review AI generated UI changes before you merge

To review AI generated UI changes, work in two passes. First look at the rendered screens, in every state and at every size the change could affect. Then read the diff for scope: files outside the request, new components that duplicate old ones, hardcoded values instead of tokens. Ask the agent for a short review packet before you start, so you know where to look.

Why a diff is not enough for UI

A diff is the right tool for logic. For interfaces it hides the part that matters most: what the user sees. A two-line change in a shared stylesheet can shift the layout of twenty screens. A new margin on a card fixes the page you asked about and breaks the modal that reuses the card. None of this shows in the diff itself.

Coding agents add a specific risk. They produce plausible code quickly, so a change often arrives larger than the request: a refactor “while I was there”, a new helper component, a tweak to a token. Each piece may be fine alone. Together they are hard to judge from text.

So judge the screens first, then use the diff to understand why they look the way they do.

Ask for a review packet first

Before you open anything, ask the agent what to check. It knows which files it touched, and you should not have to reconstruct that yourself.

Before I review: list the files you changed, the components and
tokens you modified, every screen and state that uses them, and
anything you were unsure about. Then give me the URL or the steps
to reach each of those states locally.

The answer is a map, not a verdict. An agent can miss a screen that reuses a component, and it can describe its own change more kindly than you would. Use the list to plan your review, and check it against the diff later.

Pass one: look at every affected state

Open each screen from the list and walk through its states. A checklist keeps this quick:

• States: empty, loading, filled, error, and any modal or menu the change touches.
• Sizes: your smallest supported width (often 360 or 375 px for phones) and a desktop width.
• Content stress: a very long name, a missing image, a number with many digits.
• Interaction: hover, keyboard focus, disabled buttons.
• Neighbors: the screens that share a component with the one you asked about.
• Themes: dark mode or other themes, if your app has them.

Write down every problem you see before asking for fixes, so that one fix does not hide the next.

Screenshots make this pass repeatable. Playwright can take one per state, and its toHaveScreenshot() assertion compares each run against a reference image. Visual review vs visual regression testing explains when each fits: regression tests catch changes you did not want, but only a person can say whether a new screen is better.

Pass two: read the diff for scope

With the screens in mind, read the diff. Start with git diff --stat to see which files moved, then read the ones that matter.

Look for	Why it matters	What to ask
Files outside the request	Unreviewed changes ride along	“Why did you change api/users.ts? Revert it if it is not needed.”
A new component close to an existing one	Two buttons drift apart over time	“Use the existing Button instead of PrimaryButton.”
Hardcoded colors or sizes	Breaks theming and tokens	“Replace #1E40AF with the color token.”
!important or inline styles	Hides a cascade problem	“Fix the selector instead.”
Removed or weakened tests	Hides regressions	“Why was this test deleted?”
Missing labels or roles	Accessibility regressions	“Give the icon button an accessible name.”
New dependencies	Size, license, maintenance	“Can this be done without the package?”

Ask for fixes one at a time, and look at the screen again after each one.

Compare before and after side by side

Your judgement is better when both versions are in front of you. Put the old and new screenshots next to each other, at the same size, one state at a time. Differences that slip by when you flip between tabs become obvious side by side: a heading that lost weight, a gap that doubled, a button pushed below the fold on mobile.

Take the “before” screenshots before the agent starts. If you only take them afterwards, you compare the new version with your memory of the old one, and memory tends to favor whatever is on screen now.

If the change is a redesign rather than a fix, ask for two or three variants instead of one, and compare them before any of them is coded.

Undo cleanly when a change is wrong

When a change goes in the wrong direction, do not stack corrections on top of it. Go back and ask again with a clearer request.

In Claude Code, run /rewind, or press Esc twice with an empty prompt, and choose to restore the code, the conversation, or both. Checkpoints cover edits made with Claude Code’s file editing tools, not files changed by shell commands, and the checkpointing documentation says plainly that they do not replace version control. Commit before a large UI change, so a git reset to a known state is always available.

Review screens before the code exists

The cheapest review happens before any code changes. agentappbuilder moves the first pass earlier: your agent draws the screens as HTML frames on a canvas, or captures your running app, and you review each state there. Every change is a new version of a frame, older versions stay, and Compare puts any two side by side, including a capture of the app as it is today next to the proposed change. Your agent codes the version you chose only when you say “apply”, then reports which versions it implemented. The canvas describes versions and compare, and Concepts explains active and implemented versions.

The platform does not run or verify your checks, and it never writes to your repository, so the second pass stays with you: read the diff before you merge. A review loop for vibe coding turns both passes into a routine.

A short routine to keep

1. Ask the agent for the review packet.
2. Look at every affected state, at mobile and desktop sizes.
3. Read the diff for scope, reuse and tests.
4. Ask for one fix at a time, and look again.
5. Rewind or reset instead of patching a wrong direction.
6. Merge only when both passes are clean.

The agent writes the change quickly. Your review is what decides whether it ships.